3.7 Acceptance Tests With Capybara and Factory Girl

Hi. In this episode, we'll create an acceptance test which will test all the functionality that we created so far. So let's get started. First of all, we'll use Factory Girl for creating a lot of test data in our database. So let's go to Gemfile, and in our development test, let's add factory_girl_rails, save it, and run bundle. Let's create in our spec folder, factories folder, and inside of it, edge.rb file. And we need to create this folder. Okay, so, so let's define factory girl. Define. And here in this block, we'll define our factories. So the first factory, of course, gonna be edge. So this edge consists from name, description, category, and requirements. And for name and description, we will use sequence. For name. And it just takes number. And it will return edge and number. [BLANK_AUDIO] And for, and for description, we'll do the same thing. [BLANK_AUDIO] So for description, we'll have desc, and number. Then we need to have category, and there's gonna be an association. And after we create edge, we want to populate requirements, so for that we will use callback after. So after we create record. And it takes two parameters, the first one is edge, and the second one is evaluator. And inside of it, we will create list of requirements, and we will create just by default two requirements to the edge edge. Okay, so now we need to create another factory. And factory for our category is very easy. Just a name and we call it, by default, it's going to be category. And the last one is factory for requirement. And it has name as requirement. It has value as val. And it has mode as mode. And it depends on edge. Okay, and that's all. So now we have factories. We have edge factory, category factory, and requirement factory. Also, to not specify factory girl in our tests, let's go to spec_helper, and inside of it, let's add configuration for it. So we do config.include. And we include FactoryGirl::Syntax::Methods module, like this. Okay, so now we have our factories and we're ready to create our scenario. So let's go to spec/features. And inside of it, let's create edges-page_spec.rb. So, we require spec_helper, as usual. So, our feature is, edges page. And let's create our first scenario. And there's gonna be, see the list of all edges there on the page. So what we do. First, we need to create list of edges. So, for that, we use Factory Girl and we create list of edge. Let's say we want to have three edges. Then we visit edges. And after that, we expect that page to have CSS unordered list with ID edges and list items in it to be count of three. So we really expect that there are going to be three list items. Of course we do not have these edges in our front end application. So we could come up with another test. If we are unable to add this ID, we could, for example, make expect page to have content edge three, because we know that we have our edges with numbers. But as we develop both of these applications, let's go to edges.html file. And here where we have edges, let's add id edges. Okay. So now let's go to terminal. And run rails server. And here let's run our spec. So we have an error, undefined error method edge. And that happens because if we go to requirement model, we'll see that we do not have belongs_to. So we need to add belongs_to edge right here. So now, let's run spec again. And now we do not have edges route, but also what we forgot to do is to actually specify that our feature is JavaScript. So now, let's run it. And it will start Firefox, and it cannot get to that URL. So if we add pound sign here, and let's try it again. Now it can. But it doesn't see any edges that we've generated with the help of factory. And we can make sure that we actually generated them if we go right here and just put Edges.all. So let's save it and run test again. And you'll see that we have edges in the database. But somehow Selenium doesn't see them. This happens because tests are wrapped in database transaction. But Selenium is outside of this transaction. And it doesn't see any changes. Avdi Grimm wrote an excellent blog post about this problem, and how to fix it. So basically, we need to go to spec_helper, and right here, find this line with config.use_transactional_fixtures, and change it to false, and then we can use database cleaner and set it up right here. So I will post the link to the Avdi Grimm's article so you can read more about these particular configurations. So let's save them, and let's run our test again. So we do not have database clear, okay Let's go to Gemfile and add here database_cleaner gem. Bundle. Okay, so now let's try it again. And still we do not see anything. And that happens because we are running our server in development environment. But database clean and all our tasks work in a test environment. So let's run rails server in environment test. And now let's run our test. [BLANK_AUDIO] And now we're green, excellent. So, this could really give you a hard headache when you encounter this problem. So, as we're working with two different applications, you should know that, first, you need to run rails server in testing environment if you want to run acceptance tests. And second, you need to really configure your RSpec and database cleaner so Selenium can see your test database. Okay. So let's write another spec. So in this spec we go into for clicking. So clicking on edge toggles description. So basically we do all the tests that we've done before by hand, now we want Capybara to do that. So what we do here, we create edge with description desc, desc1. And now we visit the edges, and after that, we expect that page not to have content desc1. Okay, next. We find the first element in our unordered list with ID edges and list items, so we find the first one and we click on it. And then we expect that page actually will have content desc1. Then we click on it again, and we again expect that there is no content desc1. So, pretty simple, as we do it by hand, we can do it in a script. So let's go to terminal and run our spec and see how it examines our page. Great, we're green. So let's remove this puts from here. Okay, so the next scenario is only one description is active. And again, we create edge with description of desc1, and the second edge with description of desc2. And then, again, we visit the page. So, basically, this part of the test is the same. So we just copy and paste it here. So we expect page not to have desc, then we click on it and we expect it to have it. And then we want to click on the second list item. So, for that, we are looking for all list items, and take only the second one and click on it. So, and then we expect two things. First of all, we do not see desc1. But we see desc2. Save it. Go to terminal. Run spec. And here we are. We're green. So I think you've got the idea. So I'm going to paste another several scenarios here and walk you through them. Okay, so here we are. We have the scenario for search for edge, so we create two edges with different names, and then we find the input with the type of search. I use an XPath here. And I set its content to fi for the first, and now, and then I expect that there will be only one list item. Very similar thing for filtering by category, so I create two categories with different names here. And then I create three edges with category one and two edges with category two, and then with the help of XPath right here, again I find option which has the background in it and select it. And then make sure that there are three of them. And then I select Combat and make sure there are two of them. And filtering by rank is exactly the same. So I create two edges, one edge with the requirement rank of Novice. And then I select this Novice and expect that there are only one edge present. So let's save it and run our spec. [BLANK_AUDIO] And we're all green. Okay. Now we have full stack functionality tested both on front end and on back end. In the next chapter, we'll see into authentication and working with form and validations. Now I think you've got the idea how testing works, and to save us time, we won't be writing tests in future episodes. So thank you very much for your time, and see you in the next episode.