[MUSIC] In this lecture, we'll take a look at factories. What if our objects become very complicated to create, and we want to keep that complexity out of our test cases. And we'll take a look at FactoryGirl as one implementation of a factory. And at some point, we need test data. What do we use to fill in the fields of our objects? And we'll take a look at a fun gem called Faker to play that role. We see instances of foo created all over. It's a very simple object, it's hard to get wrong. But what if it were a bit more complex and our test created it differently, let's say if they created it without a name. And at some point later in the creation block, they set the name, and saved the result. Should end up with the exact same object, correct? So if we run our test, everything's working with the new block approach. But what if foo were more complex? What if the name column became required? And we put a null constraint on that column that made it illegal in order for any foo to be created without a name. We'll put this construct not in the change block, but in an explicit up-down because change column is not a reversible construct, you actually have to tell it what to do, going in either direction of migrate. So if we migrate that and we run our test, it fails, because of a constraint violation going on. Okay? Now, the author of the test said, what's wrong? This test passed, yesterday. Everything was fine. Well the trouble is, the details of the object changed. Now, they really didn't care. Authors of tests many times don't care specifically about the foo object. This particular test does, but most of the time, they just want an example object. Give me a valid object to stand in its place. So how can we extract this from our code? How can we fix this? Where would be a better place to put this? And the answer would be a factory. And in our case we're going to use FactoryGirl. And let's start by updating our gem file. And while we're at it we're going to bring in another gem called faker which we'll use later on in the lecture. So we'll run bundle, then when we finish that we'll run migrate against the development database. The last time we ran migrate it was against the test database. So with FactoryGirl installed, we can go ahead and create our first factory. Which I'm just going to call foobars. It's going to be a file that's going to be a collection of factories that I'll use in this lecture. So if you see at this point, our spec has been expanded to not only have models, requests, and support, but has also added a factories directory. This will be the location we use in order to instantiate all of our FactoryGirl factories. So it created our first factory. It named it after the file that I asked it to create. I'm just going to change this one to be foo_fixed. You'll see in a second why I picked that name and I have to tell it what class it is. It's creating an instance of a foo. The name, property that I give it, is going to be test, because we want to just put it back, the capability it used to have. The capability to create a Foo with a name test. And if I come into my rails console, and if I were to just say, let's say Foo, let me do a couple of things here. I go Foo.new you'll notice that the name is nil. And if I do a Foo.create I should get a failure because there is a constraint violation. But if I say FactoryGirl.create(:foo_fixed), I get a successful create of my object because it is supplying a name when it creates things. Okay, now if you get tired of typing the word FactoryGirl each time, you can eliminate the need for that syntax by including FactoryGirl::Syntax::Methods and then what you have is now optional. I'll go ahead and keep the prefix just so I'm more explicit. All right, before we look at the details of FactoryGirl, I want to put ourselves in a particular state. I want to create a default factory based off of currently, foo_fixed, which is our default implementation, where we were creating it, with fix. Now let me go back to our spec and change this to use whatever the default factory is. I don't care what it is. Well, it does care. And I'm sure you can see lots of problems with this, coming up. But at this point in time, it's fixed. When I go to create a foo, it creates me something that works in my case. All right, so in this state, I want to now look at the details of how we can do other factories and then come back and fix this class for real. Because as we change those factories, tests like this where we're looking for particular values are going to give us a problem. So in summary, during this lecture we talked about the problem of having some complex objects and maintaining those for our tests. And we identified a way to fix it, namely FactoryGirl. Now, we went through the installation details of FactoryGirl and Faker, and basically got a start in our overall solution. So what are we going to do next? Let's go through the details of some of the factories and Faker data that'll help make up our solution. Basically, let's continue what we were talking about in our next lecture. See you then.