You made a tiny contribution to your Rails application, or added someone else’s code to your codebase, and now you got to make sure that it works the way it was working before. What would you do for it? One thing: you would manually go through each part of your application, and make sure that it is working expectedly. No problem if it happens for once, but what if you are going to keep adding more & more code, this way – checking your application each time you or somebody else adds code would be tedious work, but the good news is that there is an efficient work out for it, something known as Test Driven Development.
The things that you would have to check manually, you are going to write a piece of code to test that thing called tests, and you have to do this even before you write the actual code, and hence, it is known as Test Driven Development, the development that is driven by tests. You write tests, and then you write code. But there is more than this.
When you write your tests for the first time, there is going to be no code to run your tests against, so if your run your tests for the first time, they are always going to fail, because there is no code written yet. So the first step is always failure, we call it Red.
After the Red step, we write the minimum code to get pass through tests. Now the code in the second step by no means has to be the perfect code. You are just supposed to write the minimum code to turn the tests form red to green. So the second step, we call it Green.
After the tests are passing successfully, it is finally the time to refactor our code that we wrote in the second step, to make it efficient and re-factored. And we call this step as Refactoring.
So this cycle continues to take place: we write tests first; we watch them failing; we write the minimum code to pass them, and at the end we refactor the code. Well, enough theory, let’s get practical.
Rails is a mature framework, and like all the other good things it provides, it also encourages us to write tests. Each time we generate a model or a controller, Rails also generates test files for us.
rails generate model User email username age:integer
It’s going to generate the following files for us:
invoke active_record create create invoke create create db/migrate/20151109175206_create_users.rb app/models/user.rb test_unit test/models/user_test.rb test/fixtures/users.yml
Among other files, the file user_test.rb that is exclusively used for writing tests for the user model. Let’s have a look what a fresh model test file contains:
require 'test_helper' class UserTest < ActiveSupport::TestCase # test "the truth" do # assert true # end end
By taking a closer look at it, you can anticipate that it provides us a function call test for writing tests. The first argument to this function is a string that tells what the intent of the function is, and next argument is a block that specifies what to test.
In practice, every test is going to contain a function called assert that actually tests a thing. If the assert function receives true, it makes the test pass, or in other words, it turns the test Green. Receiving false in assert test makes it go Red.
What exactly the assert function is, and how does it operate – well, that’s exactly we’d be covering in the next adjacent article. Keep following and happy coding!
