Rails Recipes (for Roman Fäckl) by Chad Fowler

Author:Chad Fowler
Language: eng
Format: epub
Tags: Pragmatic Bookshelf
ISBN: 978-1-93435-677-7
Publisher: The Pragmatic Bookshelf, LLC (351417)

Solution

The way to automate your business logic tests is to implement them as Rails unit tests, making use of the unit test and test fixture files that Rails generates, as well as its test and assert methods. The test files are automatically generated whenever you create a new model and are stored in the test/units/ directory of your application.

If you haven’t started down the path of automated testing yet, you should have at least noticed that every time you generate a model (or really anything) in Rails, a set of tests is generated along with it. Let’s look at an example:

​​$ rails g model Song title:string album_id:integer duration_in_seconds:integer​​

​​invoke active_record​​

​​create db/migrate/20101101225558_create_songs.rb​​

​​create app/models/song.rb​​

​​invoke test_unit​​

​​create test/unit/song_test.rb create test/fixtures/songs.yml​​

In the preceding snippet, we generated a simple Song model, and with it, without us asking for it, Rails generated two extra files: a unit test and a test fixture file. For now let’s focus on the unit test in test/unit/song_test.rb. Here’s what we get by default:

rr2/testing_your_models/test/unit/song_test.rb

​​require 'test_helper'​​

​​​​

​​class SongTest < ActiveSupport::TestCase​​

​​ # Replace this with your real tests.​​

​​ test "the truth" do​​

​​ assert true​​

​​ end​​

​​end​​

There isn’t much there yet, but it’s a great start. With this code in place, after applying the migration Rails generated, we can already execute the test for a satisfying result. Let’s give it a go.

​​rake test:units​​

​​(in /testing_your_models) Loaded suite​​

​​rake-0.8.7/lib/rake/rake_test_loader​​

​​Started .​​

​​Finished in 0.028537 seconds.​​

​​1 tests, 1 assertions, 0 failures, 0 errors, 0 skips​​

​​Test run options: --seed 244​​

Success! The important line is the one that shows how many tests, assertions, failures, errors, and skips were encountered during the test run. I’m working in a fresh application here, so this SongTest is the only test in the system. And as you can see, that test passed. What did we test?

Let’s look at the code in test/unit/song_test.rb again. The first line loads the Rails testing framework. This is a superset of Ruby’s built-in Test::Unit framework, adding Rails-specific features and some syntax sugar. Then we define a class, SongTest, which is a subclass of ActiveSupport::TestCase. That’s where all of the magic comes from. Think of a TestCase as a group of related tests. In this case, this is where we’ll put all tests for our new Song model.

This brings us to the real heart of the matter: the actual test. In Rails test cases, tests are defined by calling the test method, passing in a name for the test and then a block of code that implements the test. The essence of each test is its assertions. An assertion is defined as a statement of refutable truth. For example, I can assert that my name is Chad. This is true, so the assertion passes. I could assert that I weigh forty pounds. This is not true, so that assertion would fail.

The most basic assertion available in the Test::Unit framework is assert, which we see in this autogenerated test. You pass a boolean value to assert along with an optional message to be displayed if the assertion fails. Any boolean false value will cause the assertion to fail.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.