Ariejan de Vroom – 7 October 2011
1702 words in about 7 minutes

Hi guys, We’re posting this one right at ya from Arrrrcamp 2011 in Ghent. Arrrrcamp is one of the best known RoR events in Belgium. An event Kabisa is a proud sponsor of. Our crew is sitting in the sessions and we’ll report in this post after each event.

John W Long - Design workflow for Rails

We started the day with John W Long’s session about “Design workflows for Rails”. He states that within companies there needs to be knowledge about business, design and development and that the ideal situation is having knowledge of all three aspects. The more these aspects are in synergy with eachother the better. He talked about the things that designing will improve (easier programming, better customer understanding, etc)

Similar to positive aspects that iterative development brings along, the designing of application’s would need to be iterative, too. An agile workflow that would look as following was presented:

Conclusion: Integrating designing / prototyping in the iterative daily process will make things easier and will take communication with your customers to a higher level.

Elise Huard - Data Driven Development

Elise talked about DDD (Date Driven Development).

What we take home from her presentation:

Jonas Nicklass - Practical testing for assorted languages

For Ruby it isn’t acceptable to write code and NOT test it. Jonas asking the croud who works using RoR and who tests their code: all hands go up.

Asking this for Javascript only few hands are raised.Javascript is something that has always been neglected regarding to testing.

Jonas talked about some design setups for testing Javascript; about unittesting javascript.You have to ask yourself what the goal for writing tests is. Jonas indicates he tests because it makes refactoring easier (remember the red-green-refectoring loop from TDD?). Because unittests are based on testing UNITS (it’s in the name) Jonas states that we need more units in JS; we don’t have the classes and modules that are present in Ruby.JQuery is often seen as a „way of building apps”, but it really is NOT.It doesn’t provided the structure needed for creating the units.

Jonas showed some possible solutions for providing structure to JS, giving some pros and cons along with all the options (think Mootools, CoffeeScript, Backbone, etc).

Unittesting JS

Jonas recommends using Jasmine („the best JS testing framework out there”) for unittesting in JS. It is the only stable solution out there at the moment.It is small but full featured.

When it comes to building JS using a packaged Jasmine solution Jonas build a rails gem (Evergreen) that makes integrating a breeze.This can be used for testing JS. It has nice syntax and can use CoffeeScript if you’d like. Add evergreen to your Gemfile, run the server and you’re good to go!

Running tests can be done in multiple ways:

Jonas gave a demo using both execution methods. Evergreen showed all the tests present for JS. Clicking on one of them (or the „all” option) runs the test(s) and shows the outcome. Terminal execution was demoed as well and integrated nicely with Selenium.

Suggestions for writing JS unittests

Structure your JS code into functions and classesMostly test event bindingsWrite custom matchers like in RspecIsolate AJAX into seperate components (don’t test or use mocks) to avoid shaky testsTreate templates as fixtures (update them manually) by isolating JS as much as possible from the Ruby code. This depends on JS being setup Simplify your DOM & Templates

Integration testing JS code

Jonas talked about Capybare to simulate JS interaction performed by the user and demoed it using Cucumber.

At Kabisa we already use this. Check it out at the web for more info: https://github.com/jnicklas/capybara

Finally, Jonas gave some tips for a better JS integrations test setup:

Roy Tomeij - Stop Swashbucklin’ and Shipshape yer Front-end

Roy talked about Frontend meta languages and The Rails 3.1 asset pipeline.The target audience were people with little Haml experience.

Roy’s statement: compilers don’t create bad code, coders do (regarding Haml output HTML)

A few motivations for using front-end meta language:

The front-end meta languages Roy talked about were Haml, Sass(&Compass) & CoffeeScript. He showed examples alongside the output that these language generate (it being HTML, CSS or Javascript).

Roy finalized his talk about Rails 3.1 asset pipelines and where to put all the various assets. In conclusion: frontend meta languages keep your code clean and maintainable so it won’t hurt to take them into serious consideration!

Andrew Nesbitt - A/B Testing everything with Split

Andrew talked about the question: are you making the best out of your pages? A/B testing is the process of sharing two designs with your users and learning what works best.

Andrew also showed an example of a salespitch text that - by simply showing another title - made +30% sales.

Some existing  A/B testing frameworks out there:

Because these frameworks didn’t go all the way, Andrew wrote the Split library.

Some approaches that could be used for A/B testing:

Split depends on two classes: Split::Experiment and Split::Alternative. These two, accompanied with a CRUD interface make up Split.

Andrew showed an example using an ab_test statement that showed one of two button images (50% chance you see either option a or b).

In the controller’s signup function a „finished” statement was added, after which you can check in the CRUD interface what option is most chosen / successful.The example showed how simple but powerfull this works.

A new feature of Split is weighted averages; you can now define ratio’s in which to serve option A or B.

Another nice feature of Split is the option to ignore certain IP adresses. This helps preventing your stats being mangled by colleagues who develop or test around.

Some tips regarding to A/B Testing

Conclusion: having trouble discussing the best solution to put out there? Use A/B testing to give all the options a try and let the stats choose a winner.

Cory Haines - Fast Rails Tests

Cory started right on with showing the not-so-speedy process of running Rspec tests.Right after that Cory kicks off some tests that show all greens  „near-instantly”… Cory talked about the fact that it’s crazy to see such a key element taking up so much time.Thinking back on where we were years ago, thinks aren’t all that bad (referring to the time were an optionally filled /test map resided in projects).Rails changed all that by introducing ways to implement unittesting and integration testing. He described the evolution of coding; moving business related code to the models. Good for the code, not so good for the speed of tests.

The difference between the Test First and TDD approach is that with TDD,  after you feel the pain, the whole design of the code is corrected instead of the test itself. After that, Cory talked about what „good design” is. His definition of a good design is: a design that is easy to change. He referred to businesses and their need to adapt themselves to their surroundings.

The core pain with Rails testsuites is not „the databases”, even though FactoryGirl or in-memory db’s are trying to create faster experiences. The actual pain of slow tests is Rails itself. Rails is the biggest 3th party dependency in our apps.

Cory demonstrated a way to run rspec on a new directory (fast_spec/speedy_shop/calculates_total_price.rb) in which a ruby file, with only the business logic from the shopping cart model in it,  requires the original codefile followed by the Rspec tests. Using this implementation, spec_helper (that starts rails, and generates all this stuff for you) is not used so you don’t have to wait for the time that would normally take.

He states that one shouldn’t be testing Rails itself and one certainly should not test database interaction by using mocks, because the best test for functionality that interacts with the db IS interacting with the DB (2 db records, one for failing and one for success scenario).

Testing the regular Rspec stuff mostly includes testing the rails configuration that you have put up for your app. This needs to be tested, but not in your main developing circle: build speedy tests to test the business logic in a fast way, and make that process a lot faster (without the accompanying sough).

Conclusion: extracting your business functionality and getting them on track with speedy rspec tests will improve your day-to-day developing cycle and make it less intensive to change simple things and having to run heavy tests.

Ariejan de Vroom

Software Engineer • CodeRetreat Facilitator • Ruby, Go and C Programmer • Electronics Apprentice