In praise of code coverage
I’ve found measuring code coverage (the coverage of code by automated tests) to be well worth my while, ranking not too far below test-driven development and continuous deployment as a practice that a software project should have in place to make me and my team happy and productive. But that’s not a universal opinion. Many software engineers, even diligent automated testers and continuous deployers, are quick to dismiss coverage, and it’s probably the thing that I’ve had to set up myself most often when I join a project. So let’s go over why it’s a valuable practice.
Read the rest of this entry »Specialist: A pattern for carving up fat ActiveRecord models
All roads to a well-factored Rails application lead from fat controllers through fat models. Where to head next is less well mapped. Many patterns move non-model code into separate layers. When you’ve gone down that path as far as you can, your models can still be weighed down with code that would belong in a model — if there weren’t so much of it. Specialist is a pattern that makes it surprisingly easy to slice up your fat models into lean modules.
Using and testing automatic accessors and virtual attributes of ActiveRecord models
An ordinary ActiveRecord model object has an attribute for each column in its table. Each attribute has a reader method and a writer method. However, ActiveRecord also defines accessors on the fly to hold non-column query results. Also, sometimes it’s useful to define a new attribute, one not corresponding to a column or even to a field in a query result. These different kinds of extra attributes can interfere with one another, making them tricky to use and test. The best defense is to understand all of them well before using any of them. Let’s have a look.
What I did on my working vacation, 2016 edition
Indiegogo’s long-lived Rails application used many gems, causing issues in development and deployment. I wrote a couple of posts on Indiegogo’s engineering blog about solving those issues:
Also, I helped my colleague Mike Luby with How we get coverage on parallelized test builds.
More scattered sightings
For the foreseeable future, Indiegogo’s engineering blog is the place to look for posts on Ruby, Rails and the like by my colleagues and by me.
Controlling database usage in RSpec and factory_girl, part 2: association strategy and unstubbed queries
An important part of testing a Rails application is establishing the correct relationship between the specs of each layer and the database. To correctly test the layer that they test, some types of specs (model and feature specs) should run against the database; other types should not. As well as ensuring correctness, policing database usage optimizes performance: tests that use the database are slower.
This post, part 2 in a two-part series, describes two measures that you can take to minimize incorrect and unnecessary database usage in RSpec specs that use factory_girl.
Controlling database usage in RSpec and factory_girl, part 1: Choosing and allowing appropriate strategies
When testing each layer of a Rails application, it’s important to create test model instances in the right way for that layer. Some specs need model instances that have been saved in the database, or that appear to have been; others need instances that have not. It’s also important to not use the database when you don’t have to, because every use makes your tests take a little bit longer.
This post, part 1 in a two-part series, lays out the appropriate use of factory_girl in specs of each layer of Rails, and gives a way to enforce that usage.
Dark corners of unit-testing lore
The software community’s understanding of developer testing (unit testing, acceptance testing, etc.) has come a long way since “Extreme Programming Explained” and “Refactoring” and JUnit got everyone interested almost fifteen years ago. There was a time when developers argued whether unit testing was valuable (never mind TDD); now it’s taught in code camps as an essential skill.
But some testing techniques have remained out of the mainstream, for whatever reason. A couple of them came up on Stack Overflow recently and I was inspired to give long answers. Whether or not these techniques eventually become part of standard practice, they’re interesting to know about and possibly useful in shaping your thinking about mainstream practices.
How I spent my working vacation
While at Fandor (still the finest independent and international film streaming service) I had almost no time for personal projects, but I did manage to write a few blog posts on Fandor’s late engineering blog, “Behind the Fan Door” (as my Fandor doppelgänger, fandave). These fit the best with my own interests and the rest of this blog:
- Continuous deployment forgives your sins
- Welcome to the red light district: A build beacon with TeamCity, Raspberry Pi, X10 and a traffic light
- Keeping your specs single-minded and your Cucumber on target
- The Constant (and attribute, and method, and class …) Gardener: Agile Development Lessons from Gardening
- TDD, not DDT: Doing TDD in the right direction
- Automated Testing Clinic with Zendesk and Fandor
- Automated Testing Clinic follow-up: capybara-webkit vs. poltergeist/PhantomJS
Also, the idea of data testing is interesting, although its context in that post is less so. And, for completeness, here’s every single one.
[2017 update: “Behind the Fan Door” is gone, so I’ve replaced links to it with links to archived copies on my own site. Links in the copies are, unfortunately, mostly broken.]
Scattered sightings
While waiting for another message in a bottle to drift your way from this blog, you might want to check out Behind the Fan Door, where Fandor‘s engineering team — of which I am one — relates our experiences with Ruby and Rails and other things while bringing you fine independent and international films on line.
Dave Schweisguth in a Bottle 