structuring your RSpec project

it is an established convention to put all your rails tests or spec in the test/spec folder. even jasmine javascript files go in spec/javascripts… seriously, wtf?

cucumber features on the other hand go in the features folder… so?

while i don’t like cucumber (because of the additional complexity that comes with gherkin), i like the idea that they think about features as something different.

when writing acceptance tests i put them in the acceptance folder and have a different spec_helper file (usually called acceptance_spec_helper.rb as RSpec runners get confused with multiple spec_helper-files).

acceptance tests and normal rails tests have orthogonal requirements that should be handled in using different setups!

i like to have use_transactional_fixtures and random test execution turned on for regular Rails tests because it’s super fast and each spec should be independent of other tests.

it’s a different thing when writing acceptance specifications with capybara and a real browser that cover a user-session on a separate rails process and runs arbitrary actions against the server, executing JavaScript code within that context.

those acceptance tests have a basic problem when it comes to database queries. changes in one process/thread might not be seen in another one because of transactional visibility. this is often times hard to debug and mind-boggling. there are some “hacks” to get rid of this problem by sharing the same database connection, but they introduce other problems like race conditions.

long story short, i like to turn use_transactional_fixtures of and use fixtures (or hard-coded factory data) for running acceptance tests, as this fits more into the idea of acceptance tests. if you combine this approach with state-full page-objects, than you can write pretty readable tests like LoginPage.new.login(:bob).

I like to run DatabaseCleaner between each group of specs and recreate the fixtures, so they are fresh for each capybara spec file.
This setup comes pretty close to how cucumber does it, without all the cucumber-world craziness.

Some benefits that come with this approach:

  • faster spec runs for both suites
  • easy to separate out suites for CI
  • great for coverage reports
  • simple spec_helpers
  • separation of concerns via custom test modules

See the example configurations for more details.

monkey-patching Rails

I’ve been working a bit on a rails plugin for debugging html templates that we use at Shopify called partially_useful.

It’s a very simple helper that adds HTML-comments to the rendered source, so that you can inspect it easily in your browser’s developer toolbar. The comment hints look like this:

<-- start rendering 'some_partial' with locals '[:all, :assigned, :locals]'-->
<div class="hello">
    <div class="world">
      [...]
    </div>
</div>
<-- end rendering 'some_partial' with locals '[:all, :assigned, :locals]'-->

There are way more sophisticated plugins out there like xray-rails, but I prefer to have very simple tools that can be used without installing plugins or the like.

I used the plugin in various projects and ported it from Rails 3 to Rails 4, but it has never been more than a GIST on GitHub. Taking the time to actually convert it into a Railtie did not take long and allows everyone to use this plugin in their Rails projects.

All it does is intercepting the ActionView::PartialRenderer#render method, taking the return value of the call and wrapping it in HTML comments.

The tricky bit is how to inject this functionality into the original Rails code…

shoot yourself in the foot way

Just open up the ActionView::PartialRenderer class and overwrite the method!

While this might seem like the obvious way to do it, it makes everyones life worse, because it makes it much harder to find out where the f**** this new behavior is coming from…

Module#prepend

The nicest solution is to use Module#prepend. It allows you to inject a Ruby module in the first position of the inheritance chain. By doing this, your new render-method will get called and you can just pass everything along to super aka the original method.

The big downsides here are that this is not compatible with Ruby 1.9 and JRuby.

Module#alias_method_chain

This is a feature that Rails adds to Module and that allows you put another method in the call-chain by aliasing methods. I’m not a huge fan of it as I find the API rather confusing and it just works with Rails.

bare metal

If you include a Module that has a method with the same name as the method in the target class, the method of the Module will not get called when you invoke it on the class. This is because the methods of the class take precedence in the method-dispatch over those of ancestors in the inheritance chain (hence the Module#prepend). Because of that, you have to make way for the new method so that it can be invoked properly when you include a Module to override a method.

A way to do that is to use the Module#included callback to alter the class and alias the old method and remove the original afterwards

  def self.included(klass)
    klass.send :alias_method, :original_rails_render, :render
    klass.send :remove_method, :render
  end

conclusion

Meta-programming is hard, especially if you want to support multiple Ruby runtimes…