Let’s use the accordions in Twitter Bootstrap as a simple, contrived example of how ignoring hidden elements leads to better and more realistic tests.

Let’s say we wanted to check for the content of the second accordion. Before, we could have done it like this:

This won’t work in Capybara 2.1, since the second section of the accordion will be closed when the page initially loads. In Capybara 2.1, we need to actually click on the header of the accordion as the user would to make the content visible.

This is a simple example to show how Capybara has changed, but doesn’t really show any of the benefit of this change. For that, let’s try and test something a bit more complex.

Let’s say we had a feature that allowed us to zoom in on a single word in a sentence into focus, for whatever reason. Let’s use the classic: “The quick brown fox jumps over the lazy dog” as an example. In Capybara 2.1, we can easily test this.

First we test that the whole sentence shows up, focus the word we care about, see that it’s still there, and make sure another word in the sentence isn’t showing up. This pretty much exactly describes how the user is going to experience this feature. In previous versions of Capybara, we would have had to test the lack of content either via a visible: false flag to the selector, or through making assertions on the DOM.

There’s definitely some times when you might want to make assertions on invisible elements, and you still can using the :visible option. But, I think for the most part you can get by with this new set of limitations, especially if you start thinking about how your users are actually interacting with the page, and less about how your code is manipulating things under the hood.

The post Less is more in Capybara 2.1 appeared first on Pivotal Labs.

  class FooPresenter
    def description_for(foo)
      Date.today.tuesday? ? "50% off! #{foo.description}" : foo.description
    end
  end

Usually, I’ll instantiate the presenter in a controller and then call it within the view:

  class FoosController
    def index
      @foos = Foo.all
      @foo_presenter = FooPresenter.new
    end
  end

  <% @foos.each do |foo| %>
    <%= foo.name %>
    <%= @foo_presenter.description_for(foo) %>
  <% end %>

Everything is simple and feels where it should be, but we’ve gotten this at the cost of losing view helpers mixed in from Rails. One of the helpers I find particularly helpful is strip_tags. If we want access to strip_tags we can do as Rails does when mixing it into the view scope and include it in our presenter:

  class FooPresenter
    include ActionView::Helpers::SanitizeHelper
    def description_for(foo)
      description = strip_tags(foo.description)
      html = Date.today.tuesday? ? "50% off! #{description}" : description
      html.html_safe
    end
  end

This feels a bit wrong as well. For one, we’ve increased the number of public methods on our presenter by at least 4, and only really needed one of them. Two, we have little control over how we are stripping the tags, and so any unit tests we’ve written for our presenter must integrate and essentially test parts of Rails. What we really want is something that can do what strip_tags is doing. Luckily, and due Rails becoming more modular, we already something to do this for us in the Rails library html-scanner. Under the hood, strip_tag is, unless configured differently, passing your string down to the sanitize method on an instance of an HTML::FullSanitizer object. We can do something similar in our presenter:

  require 'html/sanitizer'
  class FooPresenter
    def initialize(sanitizer=HTML::FullSanitizer.new)
      @sanitizer = sanitizer
    end
    def description_for(foo)
      description = @sanitizer.sanitize(foo.description)
      html = Date.today.tuesday? ? "50% off! #{description}" : description
      html.html_safe
    end
  end

Now we have an object that is easy to test purely as a unit, and also has the ability to be extended with different sanitizers.

While this works well with strip_tags, unfortunately not every helper in Rails is as nicely decoupled. The work being done in the number_to_* methods, for instance, are written completely in modules. It may be nice at some point to pull these into corresponding objects, but a short term solution could be to just have an object that includes the module:

  class NumberCruncher
    include ActionView::Helpers::NumberHelper
  end

  > NumberCruncher.new.number_to_currency(1)
  => "$1.00"

The post Presenter Sanity appeared first on Pivotal Labs.

holepicker

http://psionides.eu/2013/02/18/pick-holes-in-your-gemfiles/

Find gems with vulnerabilities

The post 02/25/13: 7304.84 Days of Ruby appeared first on Pivotal Labs.

• Lightning Talks are next week, but no talks have been submitted yet. Unless talks are submitted, it’s going to be a long hour of staring at the wall.

• jQuery 1.7 has been released http://blog.jquery.com/2011/11/03/jquery-1-7-released/ . If you use Backbone.js you might want to update jQuery for the improved delegated events performance.

The post SF Standup 11/04/11 appeared first on Pivotal Labs.

• The Postgres adapter for ActiveRecord will not use an offset unless you also provide a limit.
• Tomorrow Occupy Oakland Is calling for a General Strike. The Port of Oakland, numerous schools, and many other institutions will be shut down, as all their employees will be marching in the streets. Come out in solidarity before, during, or after work. It’s gonna be really fun.

The post Standup 00110111 – AKA 55 day appeared first on Pivotal Labs.

“Rubymine can’t call git ls-files in gemspec”

This should have been fixed a while ago in the developer image.

“Anyone built ruby 1.9 from source? I’m not sure what options to configure it with.”

Check to see what options RVM is using when it builds 1.9.

Interesting Things

• nil

David Stevenson

• I’m running a blog using ruby 1.8 off a router.

The post Standup 07/20/2011: I Know What Bowling Is appeared first on Pivotal Labs.