[MUSIC] In this lecture, we're going to discuss some database clean up optimizations because we don't want to force many of our tests to use a one size fits all that can cause them to go through many repetitive and expensive population and clean up steps. All right now, the last thing I'd like you to consider is more customized strategies. If we notice, every one of our examples, creates something in the database and does read only. Creates something in the database and read only. And not only that, it's the same thing every single time. So for the purposes of this lecture, what I'd like you to do is not think of this as just one insert. Think of it as hundreds of inserts and may take 5 to 20 seconds in order to get put in place. All, what would we do then? Well one of the things that we prefer to do is that at the beginning of the overall example group, we go back to this strategy where we create a block, create our object and then allow others to access it off of @foo, all right. Well, let's say we like this simplistic syntax, and we didn't want to change things. So what we could do, so we could come up here and just define the let for column foo. So I have a before block that's going to get executed before any test runs. That before block is going to take 5 seconds, 10 seconds, in imaginary seconds. And then whenever any one of my tests need to access their foo, it's going to go dig in to that populated database. Okay, grab this one, grab that one. Okay? And so what I don't want to do is clear the database at all. And so now I can just go through each of these subjects a little different. We can go any which way here. I'll just go ahead and return. Either @foo or [INAUDIBLE]. And we come down here and it's the same. Notice that none of my examples are changing the database. They're just on queries. They're just inspecting things. And that's my before block that sets everything up once and let's everybody query off of it. So if I rerun my test, one of the things I'll notice is that that last test was, it's not, it's really not appropriate for what I'm trying to do right now, so let me get rid of it. It was trying to show something about the eager and the lazy, and we've changed our model significantly since then. All right so foo, no leakage, of course. And then if I look at the output, you notice actually it even looks much more efficient. It goes in, it clears it, it inserts a record once. And then, all of my tests after that just go in there and select. And at the end we clear it out. Pretty neat stuff? As I said, think of this block up here as a chunk of time that you want to manage how often it happens. And then what we got rid of was the deletion of that data between every one of the tests. So if I brought my scope back, that's going to clear things out in between tests and I were to default this to truncation and rerun my tests, it's going to fail. And the reason it's going to fail is my data was inserted once at the very beginning. And the cleanup that occurred, per example, by putting that scope back in, removed them, removed them, removed them. This also brings up another point. Now notice the start and the clean that occurs is not a replacement for transactions. When using the truncation strategy, it's going to remove, not only what you put in since the start, it's going to remove whatever's in the tables. All together, so keep that in mind. Now if you remember back, we have more than just a test that we have been recently working with, we have the request back from module one. And if we include the shared context, we can just remove these and play the game that says, they don't know everything that needs to be cleaned up. So now if we run the request specs. Everything's working the way they should. And the test have to know a little bit less. Now I'm already getting tired of doing two include lines when that might be a significant number of my tests. So why don't we create an each And put that one in play as well, okay? In summary, database population can be time consuming. What we have right now is trivial. But think tens of seconds, maybe minutes. Database cleanup can be simple. Just run a command, it's gone. Well, we don't want to be spending all day waiting for a test to go to the next example, go through many seconds of setup and then nuke it. And go to the next test that could have used the exact same data that was there before. We can restructure our tests. Restructure our clean-up strategies, and that's what we took a look at. What's next? Well lets take a look at FactoryGirl, and how it can help us create prototype objects for our tests.