Screencast of Test Driven Development with Ruby: Part 2 – Exceptions

My previous screencast [1] was a simple introduction to TDD with Ruby. The intention was to demonstrate TDD and not much else. Having done that there are a number of other topics that I feel need to be addressed including exceptions, database interaction and mocks. In this screencast I’ve focused on TDD with exceptions and error handling.

Exceptions and error handling
The approach to testing exceptions and error handling is really no different that standard TDD approach, which is outlined below:

  1. Write the test.
  2. Run the test and watch it fail.
  3. Write the code.
  4. Run the automated tests, get the code to pass the test.
  5. Refactor.

The only real differences are the unit testing asserts that are used. Thankfully the unit testing framework in Ruby includes a number of asserts that are specifically designed to easly check for exception and error conditions. In particular the Ruby unit testing framework defines the following asserts;

assert_raise(*args) {|| …} Passes if block raises one of the given exceptions. assert_nothing_raised(*args) {|| …} Passes if block does not raise an exception.

There is also assert_throws and assert_nothing_thrown. The way that Ruby handles thrown exceptions is a rather interesting. You associate a symbol with the thrown exception and the stack is unwound to that point. It’s a bit like a cross between an exception and a goto.

I don’t have any really experience using throw, so all my exceptions tend to be very Java-ish and I only ever raise exceptions. I’m sure this will change in time as I become more experienced with Ruby.

Implications of TDD
As you watch the screencasts, you will probably notice that TDD influences the way that I write code. I typically work in very small, fine grained sections of code. And, because I’m working with small sections of code, I’m frequently saving my work. I’m not working with a source repository (CVS, SVN etc) but if I were, I would be frequently checking-in my code.

Using TDD means that I need to be able to quickly execute the test casts. In a compiled language such as Java or C#, I would need to be able to quickly compile and execute the test cases. If my environment is structure such that it takes 20 minutes to compile and test 10 lines of code, then clearly TDD is impractical.

Half the challenge of TDD is promoting a componentized compilation and test framework where unit tests can be quickly run.

What’s not included
This screencast is intended to demonstrate a more realistic example of TDD (i.e. more complex than the simple case presented last time) with exceptions. I have not tried to address the following:

  • databases and database related issues
  • mocks

The Screencasts
When I last did the screencast, I recorded the session in several different parts and combined them all with Windows Movie Maker. As you would expect, the quality of the resulting file was pretty poor. This time I haven’t tried to combine them, so the you can experience them in their naked avi glory! The files are available here [4]: Part 1, Part 2, Part 3 and Part 4.
Note: My older articles can be found both here and at Http://

[1] Screencast of Test Driven Development with Ruby: Part 1 – A Simple Example
[2] Test Driven Development, by Kent Beck
[3] Test Driven Development in Microsoft .Net, by James W. Newkirk and Alexei A. Vorontsov
[4] Part 1, Part 2, Part 3 and Part 4.

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *