{ |one, step, back| }

On my wall ...

(from here)

Color Blind

Presented a talk on Test First Design today at work.

I did a Lunch & Learn presentation today at work on the topic of unit testing and Test First Design, included a discussion of the Red / Green / Refactor technique. Unfortunately the red gun on the video projector was bad, ruining all the careful color coding I put in to my slides. So the technique will now be officially called Black / Yellow / Refactor.

Tuning Performance

Uncle Bob has a couple examples of why performance tuning almost always has surprises in store for you.

Not What You Expect!

Bob Martin (Uncle Bob) relates a couple of stories on performance tuning and why your expectations are nearly always wrong.

The moral of the story … measure, measure, measure whenever you have a performance problem. The root cause is prabably not where you expect it to be.

Dependency Injection Gone Bad

It always bothers me to see mock objects creating and returning other mock objects.

David Chelimsky on Dependencies

David Chelimsky of Object Mentor notes that dependency injection eases the pain of dependencies so much that we sometimes don’t bother to root out the bad dependencies. Read the article and pay close attention to the dependencies in the original and final versions (I drew a couple UML diagrams to keep it clear in my head).

Plus its got a great Princess Bride reference!

Coding Standards -- Keep It Simple

The last several clients I have worked for loved to publish huge coding standards documents. A recent one was only 20 pages long (and that was one of the shorter ones).

While browsing the new Rails 1.0 web site 1, I stumbled upon the Rails coding standard. Here it is in full (link):

Two spaces, no tabs
MyClass.my_method(my_arg)—not my_method( my_arg ) or my_method my_arg
Follow the conventions you see used in the source already

¹ You did know that Rails 1.0 was released today, right?

Thinking of no one in particular ...

Via Elizabeth Keogh ...

If an Agile Evangelist falls in the forest and there’s no one to hear him, does he still go on, and on, and on about it?

(link)

Test VS Behavior

This article was sparked by a some conversations and discussions at RubyConf 2005.

Test VS Behavior

It seems fashionable these days to say that Test Driven Development is not about testing at all, but rather about (fill in the blank), where the blank can be filled with “design”, “behavior” or “specification”. At RubyConf this year, one of the “informal” discussion sessions around the pool area drew a large crowd of people to discuss this very topic.

The RSpec ruby library (from Steven Baker, Dave Astels and Aslak Hellesoy) is a replacement for Test::Unit. Its main focus is to change the terminology surrounding the whole TDD approach to software development. I think this is key … it is not changing anything fundamental about the processes, it is focused upon the words we use in describing the process. But don’t be fooled into thinking this is a matter of semantics only, for the very words we use to describe something shapes our thought processes about the thing we are describing.

BDD, or Behavior Driven Development, is an attempt to improve TDD (Test Drive Development) by emphasizing the behavior specification nature of traditional TDD. By freeing TDD from its test bound terminology, we avoid some of the preconceptions (e.g. “Tests? Yuck!”) that developers bring to the table when discussing TDD.

So What’s Different

So, what’s the real different between RSpec and Test::Unit? Compare these two code snippets. First the “test” version:

  class TestEmptyMovieList < Test::Unit::TestCase
    def setup
      @list = MovieList.new
    end
    def test_size_is_zero
      assert_equal 0, @list.size
    end
  end

And now the specification version:

  class EmptyMovieList < Spec::Context
    def setup
      @list = MovieList.new
    end
    def should_have_size_of_0
      @list.size.should_equal 0
    end
  end

Note: This is from RSpec version 0.2.0 available as a gem from RubyForge. The RSpec guys are currently thinking about using domain specific language for specification. So expect RSpec to change in the future.

We can see that the structure between the tests and the specifications is very similar. Actually, more than similar, they are virtually identical. We just use Context instead of TestCase, use methods with any name rather than those that start with test_, and use object based assertions rather than specific assert methods.

The result is something that reads rather naturally in ruby-accented English. But the functionally is essentially that of Test::Unit, just in different clothing.

Just Semantics!

I hear you saying “But it’s just semantics!” Of course it is. But leave out the word “just”. When conveying meaning, semantics is everything. And one of the important features of Agile developement is to convey the meaning of the code, in the code itself.

Semantics are important!

Is it worth it?

Ok, semantics are important. But is it worth converting all our unit tests into specifications?

Maybe.

I do find the terminology attractive. But I have a large investment in Test::Unit style tests at the moment. And RSpec is still a bit rough around the edges (for example, the error reporting is not quite as mature as Test::Unit’s). And RSpec is going through some major changes at the moment (I mentioned the specification DSL they are playing with).

What would I like to see? One area of specification that current TDD practices tend to be weak in is the specification of preconditions. Preconditions define under what circumstances it is valid to call a method. For example, it may be invalid to call a square root function with a negative argument. Looking at a list of tests (umm … specs), I can’t be sure if negative inputs are not allowed, or if the spec writer just forgot the cover that case.

I’m not ready to switch over to RSpec yet, but it certainly is moving in interesting directions.

What I didn’t talk about

Those of you who were present at the poolside conversation at RubyConf may wonder why I didn’t mention mock objects, since mock objects were a major part of that debate. I see the Behavior VS Test debate to be completely orthogonal to the Mock VS not-Mock discussion. I’ll pick up the mock object debate in another posting, so don’t worry.

When Clocks Go Bad

Message ruby-talk:103140 on the ruby talk mailing list mentioned problems with the sleep command interacting in strange ways with setting the clock. That reminded me of this story.

Way back when, I used to work on a data acquisition system that used an IRIG clock reader to timestamp our data samples. An IRIG clock works by reading a signal that sends the time once every second. Between the second ticks, the clock reader would interpolate the time down to the millisecnod level. This allows you to have several clocks on different systems all synchronized to the same clock signal.

Our system had to take a sample every 20 milliseconds, so every cycle we would calculate the time of the next cycle. When the current data cycle was done, we would just wait until that next scheduled time arrived to start the next cycle.

An IRIG clock reader is an interesting device. Normally it works really well, but occasionally (especially if there is noise on the clock signal line) it will misread the time signal. One particular reader we were using tended to misread a couple of bits in the minutes data with the result that for one second, the clock reader would add 30 minutes to the real time. When the next clock signal arrived a second later, the reader would start reporting the correct time again.

Jumping ahead was no problem. Our software just used the reported time and continued to schedule data cycles. However, when the clock jumped backwards, the next data cycle was suddenly scheduled for 30 minutes in the future. The result was that our system mysteriously stopped dead for 30 minutes and then just as mysteriously restarted as if nothing happened.

Time is a strange concept in computer programs. It is difficult to know what the exact time is while executing. Consider the following lines of code …

   t = Time.now                      # Line 1
   puts "The Current Time is: #{t}"  # Line 2

One would think that line 2 will print the current time. And most of the time we would be correct. But suppose I pressed the suspend button on my laptop between line 1 and line 2. It might be hours (or days) before line 2 prints out its now "out-of-date" time message.

When you are dealing with times in the millisecond range, there are all kinds of things that will pause your program from one line to the next. Interrupts, page faults, and time slicing all interact in interesting ways to make the concept of "time" in a program something of a challenge.

It wasn’t hard to fix our cycle scheduler to be well behaved, even in the face of uncertain time. And I learned a new respect for time in the process.

Miller on Mock Objects

Charles Miller reminds us that there are two reasons for using mock objects.

To create an environment where the object under test can live.
To test that the object under test correctly modifies the environment.

Each use requires a slightly different API (#1 sytle APIs tend to be more flexible than style #2). I’ve used both styles of APIs in the past (and had been frustrated trying to use a style #2 API in a style #1 situation), but I hadn’t connected the differences with the reason for the differences before.

Some Things are Hard to Test ... ?

Perryn Fowler has a few words of wisdom to share on what can and cannot be tested. I especially like his closing remark.

His remarks are short, so I have reproduced them here in full.

: some things you just can’t test
: Rubbish. Think harder.
: Of course some things are very difficult to test, and in some cases the effort is not worth it when compared to the amount of risk it would mitigate - but that is a business decision rather than a purely technical one.
: You can make this decision a lot easier by not putting important behaviour in things that are hard to test