One of the beauties in the Open Source world is the possibility of reading other people source code and learn new things. However, lately I found out that not only the library code, but the test suite of several open source projects are full lessons for us.<\/p>\n
In this post, I want to tell you which are the three test suites that I admire the most and why.<\/p>\n
Rails 3<\/a> has several improvements and not all of them may be visible to the application developer. One of the hidden unicorns is Railties test suite. As Yehuda stated in a blog post<\/a> during the refactoring of version 2.3 to 3.0:<\/p>\n “Although the Rails initializer tests covered a fair amount of area, successfully getting the tests to pass did not guarantee that Rails booted.”<\/p><\/blockquote>\n This happened because, in order to have fast tests, Rails 2.3 suite stubbed and mocked a significant part of the booting process. The new test suite is able to create a new application using the application generator, change configuration options, add plugins and engines, boot it and even make HTTP requests using Rack::Test.<\/p>\n For instance, take a look at this test which ensures that app\/metals inside plugins are successfully added to the application middleware stack:<\/p>\n The most important lesson here is: whenever mocking or stubbing in our tests, we still need to add tests without the mocks and stubs to ensure all API contracts are respected.<\/p>\n Capybara<\/a> is a tool to aid writing acceptance tests for web applications. Capybara<\/a> can use several drivers to interact with a web application, as Selenium, Celerity or even Rack::Test. Each driver needs a different setup and has different features. For instance, both Selenium and Celerity can handle javascript, but not Rack::Test.<\/p>\n As you may imagine, all these different drivers can make a test suite become a real spaghetti. However, Jonas Nicklas<\/a> was able to transform a potential problem into a very elegant and readable test suite with Rspec help. Here is, for instance, the tests for selenium:<\/p>\n Each behavior group above (“driver” and “driver with javascript support”) is inside Capybara<\/a> library allowing everyone to develop its own extensions using a shared suite. For instance, if a driver has javascript support, it means the following tests should pass:<\/p>\n Capybara<\/a> test suite is one of the best examples of using tests as documentation. By skimming the test suite you can easily know which features are supported by each driver! Sweet, isn’t it?<\/p>\n When you are a big Open Source project, your test suite needs to be easy to run in order to new developers can create patches without hassle. The I18n<\/a> library for Ruby definitely meets the big Open Source project requirement since it’s widely used and provides several extensions.<\/p>\n However, some of these extensions depends on ActiveRecord<\/strong>, some in ruby2ruby<\/strong>, others in ruby-cldr<\/strong>… and soon it will even support a few Key-Value stores<\/a>, as Tokyo and Redis. Due to all these dependencies, you would probably imagine that running I18n test suite would require several trials and a lot of configuration before it finally works, right?<\/p>\n WRONG! If you don’t have ActiveRecord, I18n<\/a> will say: “hey, you don’t have ActiveRecord” but still run the part of test suite that does not depend on it. So if a developer wants to fix or add something trivial, he doesn’t need to worry with installing all sorts of dependencies.<\/p>\n Besides, as mentioned a couple months ago, the I18n library allows you to create several combinations of backends<\/a>. In other words, the I18n test suite needs to ensure that all these different combinations work as expected.<\/p>\n This problem is quite similar to the one in Capybara<\/a> which needs to test different drivers. However, I18n<\/a> uses Test::Unit thus it cannot use shared examples groups as in Rspec. So how were I18n developers able to solve this issue? Using Ruby modules!<\/p>\n Here are the tests for the upcoming KeyValue backend:<\/p>\n Each included module above adds a series of tests to the backend. Since key-value backends cannot store procs, we don't include any test related to procs.<\/p>\n These three are my favorite test suites and also part of my favorite open source projects!<\/p>\n We've adopted Capybara<\/a> as the official testing tool at PlataformaTec for some time already and I18n is one of the subjects of my upcoming book about Rails 3. In one specific chapter, we will build a tool that stores I18n<\/a> translations into TokyoCabinet, which allows us to create and update translations through a web interface, similarly to ActiveRecord. The only difference is that TokyoCabinet is waaaay faster<\/a>.<\/p>\n Finally, the fact you can mimic several of Rspec features using simple Ruby (like Capybara<\/a> using shared example groups and I18n<\/a> simply using modules) will be part of my talk in Euruko 2010<\/a> entitled DSL or NoDSL: The power is in the middle<\/strong>. The talk will show cases where DSLs mimics much of the behavior provided by Ruby and discuss what we are winning and\/or losing in such cases.<\/p>\n Keep following us and, until the next blog post is out, we would love to hear in the comments which are your favorite test suites!<\/p>\n","protected":false},"excerpt":{"rendered":" One of the beauties in the Open Source world is the possibility of reading other people source code and learn new things. However, lately I found out that not only the library code, but the test suite of several open source projects are full lessons for us. In this post, I want to tell you … \u00bb<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[94,95,58,92,115,93,60,96],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/974"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=974"}],"version-history":[{"count":17,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/974\/revisions"}],"predecessor-version":[{"id":6238,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/974\/revisions\/6238"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=974"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=974"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=974"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}def test_plugin_metals_added_to_middleware_stack\r\n @plugin.write 'app\/metal\/foo_metal.rb', <<-RUBY\r\n class FooMetal\r\n def self.call(env)\r\n [200, { \"Content-Type\" => \"text\/html\"}, [\"FooMetal\"]]\r\n end\r\n end\r\n RUBY\r\n\r\n boot_rails\r\n require 'rack\/test'\r\n extend Rack::Test::Methods\r\n\r\n get \"\/not\/slash\"\r\n assert_equal 200, last_response.status\r\n assert_equal \"FooMetal\", last_response.body\r\nend<\/pre>\nReadability award: Capybara<\/h3>\n
describe Capybara::Driver::Selenium do\r\n before do\r\n @driver = Capybara::Driver::Selenium.new(TestApp)\r\n end\r\n\r\n it_should_behave_like \"driver\"\r\n it_should_behave_like \"driver with javascript support\"\r\nend\r\n<\/pre>\n
shared_examples_for \"driver with javascript support\" do\r\n before { @driver.visit('\/with_js') }\r\n\r\n describe '#find' do\r\n it \"should find dynamically changed nodes\" do\r\n @driver.find('\/\/p').first.text.should == 'I changed it'\r\n end\r\n end\r\n\r\n describe '#drag_to' do\r\n it \"should drag and drop an object\" do\r\n draggable = @driver.find('\/\/div[@id=\"drag\"]').first\r\n droppable = @driver.find('\/\/div[@id=\"drop\"]').first\r\n draggable.drag_to(droppable)\r\n @driver.find('\/\/div[contains(., \"Dropped!\")]').should_not be_nil\r\n end\r\n end\r\n\r\n describe \"#evaluate_script\" do\r\n it \"should return the value of the executed script\" do\r\n @driver.evaluate_script('1+1').should == 2\r\n end\r\n end\r\nend<\/pre>\nFriendliness award: I18n<\/h3>\n
require 'test_helper'\r\nrequire 'api'\r\n\r\nclass I18nKeyValueApiTest < Test::Unit::TestCase\r\n include Tests::Api::Basics\r\n include Tests::Api::Defaults\r\n include Tests::Api::Interpolation\r\n include Tests::Api::Link\r\n include Tests::Api::Lookup\r\n include Tests::Api::Pluralization\r\n # include Tests::Api::Procs\r\n include Tests::Api::Localization::Date\r\n include Tests::Api::Localization::DateTime\r\n include Tests::Api::Localization::Time\r\n # include Tests::Api::Localization::Procs\r\n\r\n STORE = Rufus::Tokyo::Cabinet.new('*')\r\n\r\n def setup\r\n I18n.backend = I18n::Backend::KeyValue.new(STORE)\r\n super\r\n end\r\n\r\n test \"make sure we use the KeyValue backend\" do\r\n assert_equal I18n::Backend::KeyValue, I18n.backend.class\r\n end\r\nend<\/pre>\nWrapping up<\/h3>\n