Testing is the safety harness for your code. They are not magical, and they will not prevent you from missing bugs you did not anticipate. They do however automate the boring chore of making sure various edge cases and special conditions do not blow up your code. As such they help to catch bugs you could have totally anticipated, but did not bother checking for because of reasons.
Manually testing web apps is a nightmare because it forces you to pull up a web browser, refresh pages, make sure you clear your cache between tests, etc.. No one wants to fiddle with the browser all day, so automating basic testing tasks will not only save time, but also greatly improve your workflow.
Unfortunately testing web apps can be a bit tricky sometimes. They are designed to be accessed over the network, and to render in a web browser, and so they require your test framework to do network-like and browser-like things to emulate those conditions. While unit tests for classes can be easily mocked, pretending to be a web browser is definitely non trivial. When I work with PHP I usually use the excellent Codeception tool-set to do acceptance testing. When I work in Node or just build front end stuff, I typically use Grunt with Phantom.js.
When working with the Sinatra framework, most unit/acceptance style testing can be easily done by using the minitest and rack-test gems. Let me show you how.
Let’s set up a simple Sinatra app. Our folder structure ought to be something like this:
myapp/ ├── app.rb ├── Gemfile ├── public/ │ └── style.css ├── Rakefile ├── tests/ │ └── app_test.rb └── views/ ├── layout.erb └── main.erb
When setting up your dependencies in your Gemfile it is a good idea to isolate the test related gems from the actual run time dependencies. You can do this by using the group keyword:
1 2 3 4 5 6 7
source 'https://rubygems.org' gem 'sinatra' group :test do gem 'minitest' gem 'rack-test' end
When deploying to production you can exclude any group using the –without argument:
bundle install --without test
If you are deploying to Heroku, they exclude test and development groups by default, so you don’t even have to worry yourself about it.
Here is a simple Sinatra app:
1 2 3 4 5 6 7
require 'bundler' require 'bundler/setup' require 'sinatra' get '/' do erb :main end
You know how this works right? The above will render the contents of main.erb and envelop them in layout.erb which is the auto-magical default template. For the time being lets assume that the contents of the former are simply the words “Hello World” and that the later provides a basic html structure.
To test this application we need to create a test file somewhere (I put them in the test/ directory) and inside create a class derived from Minitest::Test and include the Rack::Test::Methods mixin.
Mixins are a wonderful Ruby feature that let you declare a module and then use the include keyword to inject it’s methods into a class. These methods become “mixed in” and act as if they were regular instance methods. It’s a little bit like multiple inheritance, but not really.
In the example below, this gives us access to standard Rack/Sinatra mock request methods such as get, post and etc…
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
ENV['RACK_ENV'] = 'test' require 'minitest/autorun' require 'rack/test' require_relative '../app' class MainAppTest < Minitest::Test include Rack::Test::Methods def app Sinatra::Application end def test_displays_main_page get '/' assert last_response.ok? assert last_response.body.include?('Hello World') end end
Once you invoke the mock request method (see line 15 above) the last_request and last_response objects become available for making assertions. The last_response object is an instance of Rack::MockResponse which inherits from Rack::Response and contains all the members and methods you could expect. For example, to check whether or not my app actually displayed “Hello World” I simply had to test if that string was somewhere inside last_response.body (see line 17).
To run this test you simply do:
The minitest gem takes care of all the boring details. We just run the test and see the results.
Let me give you another example. Here is a bunch of tests I written when working on the Minion Academy web service. My goal here was to make sure my routing rules worked correctly, that the requested pages returned valid JSON objects, with the right number of nodes, and that no JSON would be generated if the URL was formatted wrong:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
def test_json_with_1 get '/json/1' assert last_response.ok? response = JSON.parse(last_response.body) assert_equal 1, response.count end def test_json_with_1_trailing_slash get '/json/1/' assert last_response.ok? response = JSON.parse(last_response.body) assert_equal 1, response.count end def test_json_with_0 get '/json/0' assert last_response.ok? response = JSON.parse(last_response.body) assert_equal 0, response.count end def test_json_with_100 get '/json/100' assert last_response.ok? response = JSON.parse(last_response.body) assert_equal 50, response.count end def test_json_with_alphanumeric get '/json/abcd' assert_equal 404, last_response.status end
Note that those are not all of the tests I have written for this particular bit, but merely a representative sample.
The neat thing is that these tests will seamlessly integrate with other unit tests you write against regular, non-Sinatra, non-Rack related classes. You can simply dump all the test files in the tests/ directory and then add the following to your Rakefile:
1 2 3 4 5
require 'rake/testtask' Rake::TestTask.new do |t| t.pattern = 'tests/*_test.rb' end
This will add a test task you can run at any time that will iterate through all the files matching t.pattern and run them in a sequence.
If you’re like me and you don’t feel content unless successful tests are rendered in green, and errors in bright red, I recommend using the purdytest gem which colorizes the minitest output. There are many test report filters out there that make the output prettier, but Purdytest probably the simplest and least obtrusive. You simply require it at the top of your test files and then forget all about it.