Test failure scenarios first

September 21, 2009 - 0 Comments - tdd

Lately in test-driven development, I’ve noticed that I tend to write tests against invalid input before I get to tests against valid input. This is a subtle technique which I think merits some discussion.

One of the big wins with TDD is the way that it forces you to think about the problem in terms of the API; this pushes the engineer to design to an interface, not an implementation, which is one of the major takeaways from the original Gang of Four book on design patterns. And I think the higher-level concern that designing to an interface facilitates is the process of knowing the problem domain, which leads organically into the process of dividing up responsibilities between discrete classes and modules.

In many ways, a problem domain can be defined not only by what it’s supposed to do, but also by its constraints, the cases in which it should fail. Thinking about these cases upfront, testing against invalid or nonsensical inputs, leads to software which is more resilient to misuse and unexpected scenarios.

I find that defining these c…

Read more…

My test-driven Ruby setup

May 12, 2009 - 8 Comments - ruby tdd tools

I am a relatively recent convert to the mantra of TDD:

  1. Write a failing test
  2. Make the test pass
  3. Refactor

It took my involvement in writing an analytics API for the iPhone to help me see the light. This API was receiving millions of requests per day from hundreds of thousands of unique users, so every deployment of new code had to be rock-solid.

Of course, back then I was just using vanilla Test::Unit; we didn’t know any better. Since then, as I urged my colleagues to give TDD a shot, I have researched a number of libraries which take a lot of the pain out of writing tests. Here follows a description of my testing stack, along with brief explanations of why I went with them over the alternatives.

Shoulda

I love Shoulda. Stringified test names + nestable contexts + easy macros makes for well-organized, concise tests. The readable output it generates is also a great feature; consider the test below:

When this is run and it invariably fails, we get the following output:

Failure has never …

Read more…

Wha...?

11611e595f8866809b075a8e718e7600

Chris Vincent is a 20-something drummer, producer, and engineer from the Bay Area. This is where he writes whatever the hell he wants whenever the hell he wants to write it. Check your expectations at the home page.

Obligatory tag cloud

me san francisco bicycling ruby tdd css tools iphone games rails facebooker queue facebooker facebook arduino activerecord sql css tools development process company culture spam akismet bluepill god programming elite command analytics active record

Recent posts

Feed me

Atom is cool.

Get in touch

Questions, comments, ideas?
Let's talk.

Unabashed self-promotion

Recommend Me