[MUSIC] In this lecture, we will start our look at the anatomy of Rspec by first turning on debug so we can look at database interactions. We will also look to refactor our example blocks so that we can extract Common Logic into what could be before and after blocks as well as let blocks. I want to start out by adjusting the spec that we have in place. Nothing wrong with it, it's just my example is a little different. So I'm going to create an example, and I'm going to create a Foo in this example, and I'm going to expect it be persisted, that it have a particular name and that we're able to find it. And I'm going to express all those facts in the metadata for the example. Created Foo will be persisted with have a name and found. A little bit of a long winded thing. Now, what I'm also going to do is go into the Rails console in the test environment, and poke around. And see that I don't currently have any foos. And if I were to run this test, I see that I'm successful. However, the things were very much in the background. So one of the things that you may want to do is actually see the interaction with the database. Now I mentioned that one of the places we can configure the spec is in the spec helper. And what we could do is configure rails. But if you remember what I said, the spec helper was generic. It knows nothing of Rails. Which means we could move this over to the Rails helper, okay. That's a possibility. And we also have a chance to put it in the config as well. Now when we run our test, we get not only the status of the test, we get the actual database interactions that are going on behind the scenes in the test. And this is mostly what we're focusing on. At the model level. So the next thing you notice is our example is a little busy. So let's go fix that by adding an example group using context And place our example inside. So no longer do we need created foo, because the example group has taken care of the that portion of the requirement, however, we're still creating foo inside of here. Well we can fix that by taking the create and putting it in a before block. We can either do before each or we can do it before the entire thing starts. I don't know where that semicolon came from. All right, so before all I'll create my tests and now [SOUND] I'm running. So now if I rerun the tests, you notice that my block can't access what was done in the before block. All right? Well that makes sense. You can't see that. So I can declare it as an attribute, that's one way to fix it. Okay now if I rerun the test, everything looks good or it appears to look good. If we do a count we'll notice that we've got an extra object that may have had some junk in there. And that every time we rerun the test, we get another one. Well, that's because the before block is running before the transaction started that's running the test. Okay, one way we can fix this is we can create an after block, And basically just undo what we did. So we say foo, we want you gone. So now if we rerun the test, you notice the delete happens after the roll back and everything's done and if we check our count we're down to zero. Okay, well that's a way to solve it. We can also solve it by running the before with each run. Okay, if we rerun now, now the insert is happening as a part of the transaction. And is obviously part of the rollback. And if I do a count, we have no object, okay. No side effects now we're gotten rid of things, but we have polluted the global space with this at sign foo. We'd like to get rid of that, okay, let's do that. Let's not use an at sign foo, but let's use this construct called let, which will define a function that will only be called once and when it's called, it'll return whatever is returned from this block. All right? So now if we rerun our test, it'll act very similar to before. And that the insert is happening within the transaction and as part of the rollback. And now our count is also at zero and with this approach we have not polluted the global naming space of the test and we have rolled back our database to our starting point. Okay that's not half bad, so in summary we started our discussion of the anatomy of R spec by showing you how to enable and disable console debug of database interactions. Note that while this is disabled, it is being written to the test log, so you can find it even though it's not coming to the console. We looked at DRYing examples, leveraging before and after blocks, and leveraging attributes for sharing access between the blocks. We looked at the impact of applying :all and :each to our before and after blocks. Whereas :all causes it to run only before and after all of the examples are run. Whereas :each will run within each example, making it part of the transaction of that example. We also looked at the power of the let block. Basically replacing the need to do a before each kind of block. And offer it a lazy instantiation way to do that. So what's next? Well, we'll take a look at Thinning Examples.