1. Skip to navigation
  2. Skip to content

The ELC Community Blog

A knowledge exchange on Ruby on Rails and Agile Development


Can I Take a Test Drive?

by josh on November 13, 2007

Why don't you just take this lemon right now for 500 bucks?!

Most developers who don't employ Test Driven Development either don't know how to write tests, don't believe TDD is worth their time or haven't trained themselves to do so. Yes - it's like sucking your thumb or carrying your blanky around. You have to be trained to stop.

If you're of the group that believes driving your application's development through testing isn't worth your time, then you haven't taken the time to consider how much time you spend debugging - not only as you develop, but as your maintain and deploy.

If you're of the group that hasn't trained yourself yet, you're probably also of the group that doesn't know how to test (to some degree).

Here's some help:

When you find yourself writing:

def some_method

STOP RIGHT THERE! You've gone far enough thank you.

Open or create a corresponding test file and write:

def test_some_method_should_do_this_when_something

Now define some_method's functionality in the test before you write the function. Then go write the functionality.

The key is: Don't write the functionality until you know how to test it. If you don't know how to test it. You don't know what your functionality is yet.

This may be easy for all the public methods, but what about the protected and private ones? How am I supposed to test those?

Use .send(:some_private_method)

def test_some_method_should_do_this_when_something
  my_object.send(:some_private_method)
end

Comments

Jamal at 10:08 PM on November 13 2007

I think it is hard to get used to write tests before functionality, I end doing the opposite (functionality then tests)

josh at 5:04 AM on November 16 2007

It takes a little discipline but the pay off is huge. If you test each method in a library directly and independently while your developing, it drastically decreases the total time spent debugging a method call that depends on many other methods.

Add a comment


home | services | Ruby on Rails Development | code | blog | company