 Today we are going to see how we should test Rails 5 apps. My name is Pratamesh, that is my Twitter handle, and I work for BigBinary, I'm a director at BigBinary, and we are a Ruby on Rails consulting company. We also specialize in React and React Native. So if you want to talk with me about Rails, React, React Native, we can discuss it later. I have a few stickers as everyone, but I'm a bit different, like all the speakers that give talks, they always have stickers with them, and they give stickers to the attendees. But I like to collect stickers, so this is my laptop, and in RailsCon I got a few stickers, but if you have some stickers, then contact me later, because I want to collect them. So I also help in maintaining this site, CodeTrials.com, it was started by Richard Newman, who in the morning he got the Ruby Hero Award. And this site helps in getting you started with your open source contributions. So if you subscribe to this site, it will send you an email with some issues on GitHub, and then you can start contributing to open source. So if you are interested in starting contributing to open source, please subscribe to this site. We can also discuss it after my talk, if you want any more details. I'm also part of Rails Issues Team. So as part of the Rails Issues Team, I get to triage issues. So if you have opened any Rails issue, you might find me commenting there, or if that issue is no longer valid, then I might close it also. So everyone is excited about Rails 5, right? There are so many new features, like Action Cable. We just had an awesome talk about Action Cable. But besides that, we have API-only apps, we have Ruby 2.2 support only. So all of these new features means we have to also test those features, right? So we need to know how to test all of these new changes. And there are a lot of changes related to testing also. So basically with Rails 5, there are not just many features, but there are also changes related to how we test our code, how we run our tests. There are a lot of significant changes related to running tests. And also to the way we write tests. So today, we will see all of those changes, and we will see what things have changed and how we should go about writing tests. So we will start with a running test, how we should run Rails 5 tests. And then in the second part of the talk, we will see how we should write tests. Okay, so let's start with running. So before I talk about what is the way to run tests in Rails 5, let's do some recap. So before Rails 5, the only way to run test was RakeTask, RakeTest. And I'm only going to talk about the Rails default test tag that comes with Rails. So I'm not going to talk about RSpec or any other tools. There is a talk after my talk, which is going to be about RSpec and Rails 5. So by default, we can run our test using RakeTest. It just runs all the tests in our application. And if you want to run some specific tests, like controllers, models, then we have specific RakeTasks. Okay, and then if we have some other folders, like if you have test workers or test services, we can extend those RakeTasks. We can write our own RakeTasks and basically run those tests. But if we compare it with other testing tools, it has some limitations. Basically, the limitations are around how we run the test effectively. So if I have a test sheet, which is always passing, there is no need to basically have anything in the test runner. Basically, I just need to do RakeTest and it will pass. So there is no need to do anything. But that is not always the case. So what happens is I write a test, that test fails, then I write some code, then that test passes, and then I write the next test. So that is the normal flow that we follow in our day-to-day work. And this is a typical example of how we run a test before Rails 5. So there is a controller and I'm testing that controller and it prints the output. So if I'm able to use this output to run the test again, obviously that will help me to improve my testing workflow. So this prints some output here about which test failed. And I can see that, okay, from users controller, the test from line number nine has failed. But if I try to reuse this information to rerun the failed test, it doesn't work because Rails is not able to understand exactly how to rerun this test again. And this was before Rails 5, obviously. So to sort out these kind of problems and limitations, Rails 5 has introduced a test runner. So this test runner will help us in rerunning the test, it will help us in having a proper workflow for running our tests. And this test runner can be used by bin Rails test command. So this is a new change in Rails 5. If we do Rails and minus, minus help, then we will see a command for Rails test. And obviously this is different from the rake task. So it is not actually a rake task. Basically there is a proper executable which has proper support for getting arguments. It also has documentation as we will see later. So this is a output of bin Rails test on Rails 5 apps. We can see that it has finished the test and there is nothing significant here. But we will see later how it improves things. So let's see how we can rerun the snippets. So the same example that we ran earlier, a rake test and a controller test. But here in the output we can see that it has printed which test has failed with the line number, but it also has a command ahead of it. So I can just copy that bin Rails test and whatever the test that has failed. And if I run only that particular line, then it will run only that test. So I'm able to basically copy, paste things and run only those tests which have failed. It also has good documentation. So before Rails 5, when we only had rake task, there was no way to document things like which arguments this rake test method is, rake test command is going to accept. There was no better way to do it. There was also no better way to parse those arguments because rake had some, like you have to get things around if you want to pass arguments to rake properly. So that was also one of the goal while designing the test runner that it should have proper documentation and it should accept proper arguments. So if you do Rails T minus H, we will see the documentation of this command and we can see that it does a lot of things. Like I can rerun the snippets, I can have failed fast, I can see the back trace, I can defer the output till the end. So a lot of things are there. And earlier we saw about how to run a single test but we can also run multiple tests. So if you want to run a test from one model, user model and post model, that is also possible. So you just pass which arguments like the test and their line number and it will properly run tests from line number 27 from user a test and 32 from a post test. It will also be able to figure out, okay, I want to run tests from particular folders. So you can pass test controllers, test integration, it will just run all the tests from these two folders. So there is no need to basically augment rake with new rake tasks if you want to run tests from specific folders. You just have one command with you which can run all the tests in the way that you want to run the tests. Another cool thing is you can also run two tests at a time. So you can pass the line numbers of tests by separating them with colon and now it will run two tests at the same time. Another new feature that is added is related to backtrace. So before Rails 5, we had to pass the environment variable for seeing the backtrace. So basically what Rails does is it doesn't show you the exact complete backtrace of your failed test. What it does is it uses its own backtrace cleaner and it will only show you the relevant lines. But sometimes we want to see the actual output. What was the full stack trace? Because if there is any failure related to some gem that we are using, we need to see the exact line that code was failed. So now we can see that with just passing minus b. So it will show the backtrace if there is any. We can also do fail fast. So we can just pass minus f and it will stop at the first failure. So it will not run the whole test suite. It will just stop at the first failure and it will print the result on the console. So here it just prints interrupted and exiting and we can see that it has only run five assertions. So it has not run all the tests. Colored output, most wanted thing, right? We want our test output to be colored. So that is also present here and that is sort of activated by default. So when you run test in Rails 5 using this new test runner, you will always get the colored output. You don't have to like pass a flag or write some configuration in any file. It will just work out of the box. And we know that Rails test recipe is actually powered by Minitest. So underlying library that is used for the test framework that comes with Rails is Minitest. And Minitest 5 has this plugin architecture which allows you to create plugins which actually hook into the Minitest code and they can customize the output that comes out of Minitest. So Rails 5 actually uses this capability of Minitest to provide a custom reporter which will have this colored output and all the other features. And it also has a plugin for providing options for all of these things like fail fast, defer output, back trace and everything. So using this Minitest 5 plugin architecture, Rails 5 has added this test runner. And you must be wondering, right? All of these tools are already existing in other tools. Like if I use RSpec, everything that I showed already works, there is nothing new in this. So obviously, yeah, there are inspirations and this is inspired from RSpec, Minitest, MaxiTest and other tools. But the point here is that Rails always says that, okay, if something is good, then it is always part of Rails. You get things as part of Rails as the default Omacasa stack and you don't have to configure things which are good, which already work. So basically following that pattern, now starting from Rails 5, you get the test runner as part of the default Rails stack. So if you are starting a new Rails 5 app, you don't need to configure 10 different testing libraries or 10 different things to have all of these features in your app. Basically, you will get it out of the box from Rails 5. So this was all about running the test. Now we will move on to the second part where we will see what things have changed about writing the test. And one of the significant change that has happened is related to the controller test, how we write the controller tests. So this is a typical controller test from Rails 4. We just test that, okay, my article is getting created or not. I post to create action, then I pass some arguments, I pass the article params, and then I check whether I'm getting redirected to the new article page or not. In Rails 5, if we scaffold generate this test, then it will look like this. So there are many changes and we will go one by one. Instead of creating action, we have articles URL, okay? So we are no longer hitting a particular action. We are hitting a route, okay? This is the route helper that we have in other parts of code. In our application code, we are using that in the test also. Then instead of passing the params by themselves, we are passing them as a keyword argument. So if you see the previous example, here the params were passed as it is. There was no keyword argument that was used to pass those params. But now we have a keyword argument for passing the params. And the third and most significant changes, the superclass of the test is now changed. It is no longer action controller test case as in Rails 4 apps. It is now action dispatch integration test, okay? So this is how a typical controller test will look if we generate it in Rails 5. Now why this change? Was it required? So let's see why this change was made. So if we compare the test case from Rails 4 and Rails 5, they almost look same. Basically what we are testing is, we are just testing that article gets created and we get redirected to the new article page. So these tests are almost same. There is not much difference in what they are trying to achieve, what they are trying to test. The only difference is how we are testing. What is the mechanism that we are using to test it? But there is a sort of significant difference and that is integration tests are slow. We already know that, right? We want our test to be fast and integration tests are already very slow. So we write functional controller test. And that's what we were doing till Rails 5. That's what we were doing when we were using Rails 4. But integration tests are no longer slow. They are now comparatively as fast as your functional controller test. And that is due to the work of Eileen. So she worked a lot on integration tests in last one year and now the integration tests are almost as fast as the functional controller test. So if you consider by speed, there is no significant difference in the output that you get from running a functional controller test and integration test. So Rails team decided to just deprecate the controller test in favor of integration test. And it is obviously close to real world. So because when we test the controller using functional test, we are not actually running like what happens in real world. So basically functional controller test don't have the full middleware stack. So if we don't go into too much details, what it does is it just does some magic and directly goes to the controller. But that's not what happens in real world. In real world what happens is the request comes, then it goes through the rack middlewares one by one and then it hits the controller. But that's not what was happening in case of functional controller test before Rails 5. So now we are close to the real world. We are actually mimicking what happens in a typical request response cycle. So Rails 5 generates integration controller test by default. Whenever we do Rails G scaffold something, it will have integration controller test generated instead of functional test. But we also have old apps, right? In our old apps, we might have action controller test case, those functional controller test cases. So what will happen to those old test cases? So they're backward compatible. Basically the change is only for new Rails apps. So if you are upgrading existing Rails app to Rails 5, you don't have to worry. Your test will continue to run as it is. So they will not, so basically if you generate a new resource in your Rails 4 app, which is upgraded to Rails 5, that test will be integration. So all the new test, those will be integration. But your existing controller test, they will continue to work as it is. So this change is backward compatible. And in Rails 5.1, this action controller test case might be moved into a new gem. So it might be moved from, like removed from the core Rails and it will be moved to a separate gem. And then we can use that gem to continue using this old behavior. So we don't have to actually change our existing test. We can use them as it is. But all the new test, those will be now integration test. Though this change looks a bit simple and I said that okay, functional test and integration tests are almost same. We are doing the same thing. It's not actually doing the same thing. Like I lied a bit. So there are some implications of this change which are important to understand while writing our test. So let's see what are the implications. Now in Rails 4, this is the typical controller setup that we do. Like we fetch a user and then we sign in that user. Generally if you're using device, then you have sign in and then you pass the user, whatever user that you want to sign in. But internally it does this. Internally that test sign in helper actually sets a variable in session. Session of user ID is equal to something. And then when you run the test, your test has access to that session and then your test interprets that user as logged in user. But now that we have moved to the integration test, we no longer have access to that session. So we cannot access the session directly. We have to actually log in the user. So before trying to create our article, I have to actually send a post request, log in a user and then send another post request to create the article, okay? So this is how, like if you use Capabera or any other tools, you might know this. You always have a like before filter, like not filter, but before block where you actually sign in the user and then you do whatever you want to test. So similarly now we will have to add this setup block. We cannot use this session directly. It is not accessible in the integration test. So this is one change that we have to remember while writing the new tests. Then we were able to access the headers directly. We were able to access and assign and change headers by just accessing them as a request dot headers. And that is also not possible now because integration tests don't have direct access to those headers. So we have to pass those headers explicitly as keyword arguments, okay? So with Params, we can also pass whatever the headers that we want to have on our request. This was about like all the implications that were there while writing the integration test. Now let's take a step back and see what we are actually testing when we are testing a controller action or controller URL. So again, let's see a typical example of Rails 4 test. We are again trying to create an article and see if it gets created properly or not. So here we are testing these things. We are testing which action gets used to create the article. So we are testing to create action. We are also testing the instance variables. So in our controllers, we create, like we use the instance variable like at article is equal to article dot new and we pass the params. So we are testing that instance variable gets assigned or not. We can also test what was the status code like assert redirected to. So we are verifying that, okay, we got redirected to the new article page. So we can test a status code in old tests. We can also test a template. We can check that, okay, my index template got rendered. So we can use assert template and use it to test which template got rendered. And obviously we can also test what was the actual HTML result of this request. So I can actually use assert select and other helpers to verify that, okay, my DOM content was what was I was expecting. It had this particular div. It had this particular span or whatever. So I can also test the actual generated HTML. But in Rails 5, there are some changes. We cannot test all the things that we were testing in Rails 4. So this is the example of Rails 5 test. Here also, we are testing the request because we are sending the request. That's why ultimately we are testing that request. We can also test the status code. We can check where we are redirected to or was the response successful or was it failure. And also we can test the generated HTML. So we can write assertions about what DOM content was generated. But we cannot test the instance variables. So earlier, we were able to test what instance variables were assigned in that particular controller action. But that is no longer recommended in Rails 5. We cannot also test which template got rendered using that assert template helper. So that is also not recommended by Rails 5. So basically, these two helpers are now deprecated. If you are using assigns assert template in your existing test, then you will get a deprecation warning when you upgrade to Rails 5. When we are using these assigns and assert template helpers, we were actually testing the controller internals. Like what the controller was doing internally when we hid that controller action. So we were assigning some instance variables. We are rendering some template based on some condition. And these are all controller internals. It is not like the result of controller is not dependent. It is actually dependent, but they are not the result of the controller. They are just internal parts of the controller. So this is no longer recommended for testing in Rails 5. And you will get a deprecation warning. So the recommended way to test controllers in Rails 5 is to test the end result. What was the end result of that request? Something like some HTML got rendered. Or what was the status code of that request? What was the response status code? So those are the things that are now recommended for testing. And we can test them using assert select and Rails DOM testing gems. So these two gems, these gemman helpers are used for asserting what content your DOM has. So we are no longer just testing a controller action. Like in Rails 4, we are able to test the controller action and we are also able to test the internals of controller. But now we are testing the result of your controller and view combined. So the way your controller works is it passes the instance variables to your views and then view gets compiled and you get the HTML. So in Rails 5, this operation of like passing the views, passing the instance variable and data to view and generating the final HTML, it's considered as a black box. So you are not allowed to, like you are not recommended to go inside that black box and do something. You are only recommended to test what comes out of it. So we test what comes out of it, the actual output, which is the compiled HTML or the response code. So there is a space, basically there is a space between how your controller passes your data to views. And before Rails 5, we were allowed to test and go inside that space and see what instance variables or what data I'm passing from my controller to my view, what template I'm rendering. But that is no longer recommended. So Rails 5 tells you that don't go inside that controller and space between your controllers and views, don't go there. So controller view interface is no longer recommended to test in Rails 5. That's what I was trying to say. Consider it just as an implementation detail. Like Rails is a framework which has a way of implementation for passing your instance variables to your views from your controller. There is no need to test that your instance variable gets passed to your views using those assigns and other helpers. Assume that they're just passed by Rails. So consider it just as an implementation detail and test what is the actual output that comes out, that comes at the end. But you might be thinking that, okay, you're saying so many things about how to test Rails 5, but I actually need to test my instance variables. And there are some valid reasons why I want to test my instance variables. So let's see why we were actually testing those controller internals or why we might have to test those controller internals. So why do we test controller internals? Why do we test the assign helper or why do we use that assert template helper? We use it to just verify that, okay, correct template gets rendered. If I have some conditionals, like let's say my subdomain, based on my subdomain, I'm deciding which template to render. If my subdomain is this, then I want to render index template. If my subdomain is this, then I want to render some other template. So valid use case. I also want to verify that correct data gets passed from my controller to view. So I'm verifying that, okay, I'm assigning proper instance variables and those data, that data is getting passed to views. So I might use, might test controller internals to just verify this fact. So that's why we test the instance variables because that is the only way to send data from controller to view. And that is the most recommended way to send the data, right? It is everywhere in Rails Guides, it is present everywhere in all the documentation. So we know that that's the way to send data from controller to view. It's the sort of law, like it's contract, like nobody has concretely written it, but it's there, we know it. And that's why we test it. We actually test the interface between controller and view, okay? So before Rails 5, we were testing two things when we were writing the controller test. We were also testing what was coming out of that controller, like the generated HTML response code and other stuff. And we were also testing this interface between controllers and views. We were testing what was happening in that middle space also. So testing controllers in this old way, which is isolated from your views, like you are testing this middle part, isolated from your views, is now no longer recommended. But sometimes we need it. Consider a case where you're writing a Rails engine and which is used in your Rails app, and you're creating a controller in that engine, okay? Now you have your Rails app, which has the views, which will consume that controller. Basically those views will get rendered from your controller. And you have some conditional logic based on which your particular view will get rendered. Let's say you have two templates, and you have a conditional logic based on which that controller will render a particular view. And then that logic can depend on what data gets passed from controller to view, okay? So you depend on that middle part. You depend on that interface of passing data from controller to view. So this is sort of a valid use case. Consider an example of device gem, which provides a device, like we use device, right? We subclass from the device controller, and then all the behavior gets added to our controller. And our views also get rendered. So views are present in our application. But controller is present in device gem. So if we want to test device, we want to have some mechanism to verify that correct data is getting passed from device controller to our views, okay? We just cannot test it in isolation. So sometimes it is needed to verify, to test that middle interface. Yeah, and as I said, the example was controller, providing a controller via an engine. Obviously, there are ways to go around this also without using the Assign, Assign, Assert template. If you want to have a controller, which is outside of your Rails app, and if you want to still test it, you can provide some default view. Let's say I'm dependent on act user instance variable to be passed from my controller to view. Then I can add a default view in my engine, which will render something based on that act user instance variable. And then I can test it using AssertSelect or Rails DOM testing gem. But if you don't want to do that and continue to test it using the old way, you have this gem. So the Assign and Assert template helpers are removed from Rails core and put it into this Rails controller testing gem. So if you include this gem in your test, you will no longer see the deprecation warnings, and you will continue to run your test and write your test in the same way as before. But it is not recommended, okay? So this was about all the changes related to controller tests. Now we will see how to test API apps. So Rails 5 has introduced API apps, and we can create them using minus minus API, Rails new minus minus API, and it will create API-only app. And now we will see how to test those apps. So typically in an API-only app, we only deal with JSON and XML. We don't deal with actually what HTML get rendered, because we no longer generate HTML. We only generate JSON and XML data. So our unit tests, whatever model test that we have, they will remain the same. There is no change in the way we will test those for API apps. But there is a change for testing our controllers. So in a typical API app, we will have something like this. We are creating again an article, but this time we want to send the JSON data. So this example is for actually sending the HTML data, because if we see the example for JSON, we have to do a lot of things. We have to pass the headers for content type. We have to also convert the data to JSON before passing. So we cannot pass hash. We have to actually convert that data to JSON. We have to also set the format of this particular URL to JSON, so that Rails will understand that it is JSON, incoming request is JSON request. So all of these things we have to do in Rails 4. But in Rails 5, we have a way of encoding that request. So if we want to send the JSON request, we can just tell Rails to encode this request as in JSON format. And it will take care of all of these things, like converting your params to JSON, then setting a proper header, setting the format to JSON. It will take care of all of these things. So we just have to specify the encoder as argument. So if you see here, I'm just passing the encoder that I want to use as JSON. And it will do all of the magic behind the scenes to consider this request as a JSON request, do the request encoding, set the proper headers and everything. And it will send that JSON request properly. Currently, we only have the JSON encoder. There is no other encoder that is present in the code base right now. But if we want to have our own encoder, let's say XML, then we can use this hook to register it. And then we can just pass it as XML. So this register encoder method expects two things. The way you want to parse the parameters and the way you want to parse the result, the body of the response. So if we pass these two things, then it will register that encoder with Rails code and then we can use it in our tests. The other thing that we want in our API test is parsing the incoming response. So we send the request, something happened, and response came. And we check that valid JSON was returned to us. Now, if you use Rails before Rails 5 for API apps, most of you will have this kind of helper, parse JSON in your test helper or spec helper file, which just parses the, like it just does JSON.pars response body. So you might have seen these kind of helpers in your test code. What it does is it just parses it as JSON. So to avoid this parsing in every test, Rails will have now a helper called as parse body, which can be called on the response, okay? Now, this helper, what it will do is it will figure out that I was sent a JSON request. So I should pass the response as JSON, okay? So if we call this in an API test, then it will properly figure out that I want to pass, I'm expecting the response to be passed as JSON body. So it will just parse it and it can compare it properly with the expected hash, okay? Obviously, this requires that as JSON to be passed. So these kind of things help in writing API test effectively, because they sort of try to reduce the boilerplate code and which were required before Rails 5. Now let's look at some of the other changes. So yesterday, how many of you attended the talk about active job? Okay, so Jerry, he talked about the async adapter that he added in Rails 5. And now, that is the default adapter for your development and test environments. Now what is the advantage of it? So before Rails 5, you might be using Sidekick for your production environment, but your development and test environment was not using any async kind of adapter. You might be using development, like whatever the inline adapter that comes with Rails, that was the default for a test environment. And if your code is dependent on some synchronous or asynchronous code, then your test might fail. Basically, they might give you false positives and your code might behave differently in production than in test. But now that we have a async adapter in Rails 5, that is the default adapter for your test environment. So you don't even have to specify that in any configuration file. It will just have the async adapter as the default adapter. So we are reducing a difference between your test environment and production environment for ActiveJob. We also have a random test ordering enabled by default. So in last Rails Conf, Aaron Patterson, tenderlo, he talked about having a fast test. And one of the ways he mentioned was having parallel test. If there is any way we can have tests running in parallel, we can obviously speed up the overall time. We will have a test getting finished in less time. Now, if you want to run test, if you might have tried running tests in parallel using some gem, there are already gems which do this. And if you might have tried it, and if your tests were dependent on the order in which those tests are run, you might have faced issues while running those tests. Because if tests depend on the order in which they are run, they are not good tests. Basically, if you run them in some other order, they will fail, so they are not good tests. And before Rails 5, the order that Rails uses internally to running tests was not set. Like you are allowed to configure it to set to something else. But now, it is set to random by default. So now, like we are a step closer to having parallel test. Actually not, but a small step closer to having parallel test. How many of you like fixtures? Only two people. Okay, so whenever we talk about testing in Rails, that talk is not complete without talking about something about fixtures. So in Rails 5, there are some nice additions to fixtures also. And first one is file fixture. So how many of you actually have some JSON files in your test support folder? Okay, so for you, there is a good news. Now you don't even have to write those small helpers in your test helpers for accessing those files because you get a helper from Rails. So you can store those fixture files in test fixtures files folder, and then just use this helper and pass the name of the file, and it will just have that file object. And then you can read the contents. You can, whatever you want to do with that object, you can do it. So again, it will reduce one more small helper that you used to add in your test helper file. And you can configure this part. So by default it goes inside the test fixtures files folder, but if you want to set to something else, you can set it. Another change is related to using custom active record classes. So if you're using a legacy Rails app, you might have your model name as, model name different from your table name. So let's say I have a post model, but my table name is something different, records. And I have another model, comment. So if I want to use fixtures with this kind of setup, I have to use a table name which is records.yaml, and for another model I will use comments.yaml. So this setup works fine, but I have to tell active record that, okay, I'm using post model for my records table. So the way to do that earlier was to set this using the set fixture class method. And we could set it in our test helper. So this was possible before, but there was one limitation. If you run this using some of the rake task that we have for loading the schema, it didn't used to work properly because it was not going through that test helper. So test helper gets involved only when you run the test, not when you run this rake task. So you have to do some hacking to get around and to specify what table you actually want to use for that particular model. Now you can add a table specific or model specific metadata in your fixture files directly. So this is a typical example. You can just specify that my model class will be post for this particular fixture. And it will use that class for loading the data properly. And it will ignore this key. So underscore fixture will be ignored by default. So it will not cause any issues with your actual data. There is also a change related to how we test requests, but I think I'm almost out of time, so I'll skip it. So yeah, so testing Rails 5 apps is actually a better experience. We can run test effectively. We can write integration tests more effectively. Focus is on integration tests, end-to-end testing rather than testing things in isolation. Controller plus view is considered as a black box. So you are not recommended to go inside that just as what comes out of it. And obviously there are gems which you can use if you still want to test in that way. So happy testing, write good tests. And how many Star Wars fans we have here? Okay, so today's not the May 4th, but May the Force be with you for writing good tests. And may you use the default Rails stack that comes with Rails. But I'm fine with you as long as you write tests. So sit for the next talk which is given by Justin and he will tell you about how to use RSpec with Rails 5. Okay, and if you want to know more about Rails 5, we have a blog series. So we have around 32 blogs right now present on this URL for specific things that are coming up in Rails 5. So if you are interested in knowing about things in Rails 5, check out our blog. There is also a newsletter, so if you want to know what happens in Rails in a particular week, you can subscribe to this newsletter and you will get a weekly email. And yeah, Rails Confedition of this newsletter is coming soon, tomorrow. So if you subscribe today, you will get to know what happened in this week. That's it, thank you.