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:
- Create userstories
- Design / Prototyping
- Back to the 1st step, building new features
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:
- Your first hunch about how your web application is going to work out (target wise) is wrong most of the time; you need to measure interaction and your assumptions and react to that.
- It’s good to build interactive elements (ie:buttons on key locations) that will give you user feedback and that verify if your assumption is correct.
- Check if there is interest in your product(idea) by creating a minimal viable product that you present to the world. Create an update subscription along with that and if there IS interest, you’ll have data (subscriptions) that prove it.
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.
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).
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:
- In browsers (/evergreen)
- Terminal (using a capybara driver); you can use Selenium, Webkit or ENVJS.
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:
- avoid asserting on urls, cookies, session, application state
- Asserting to what you can see (interfacing) makes the test more stable. It avoids one for having to update the integration tests constantly.
- Be as lenient as possible (avoid specific selectors)
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:
- Quick results
- DRY (!)
- Unforgiving compilers, so less errors
- Better performance „out of the box”
- Maintainable code
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:
- Swap css stylesheets
- Render different templates / partials
- Set different variables at the controller level
- Hack the page with JS
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
- If you would want to get definitive favored choices from your users, test BIG changes. The bigger the change the more you’ll see the preffered version.
- A typical A/B test would be ~2 weeks. Mind that this has to be longer if you have a low volume website.
- Don’t run 2 tests that cross eachother’s stream. This will make the results inconclusive.
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.