Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Wed, 21 Sep 2005

A tour through a Fit episode

On the agile-testing list, someone asked this question:

Here's my answer, which goes afield into business-facing test-driven design.

My inclination would be to test the business rule directly. Here, I'm using Rick Mugridge's CalculateFixture. With it, the inputs and expected results are separated by a blank column.

(An alternative would be to have a single column named reaction?. Each cell would contain a list of all relevant reactions for a condition. My problem with that is it's too easy to overlook a reaction if you're just going down a reaction column and filling in what comes to mind. Enumerating the possibilities in columns forces you to come up with an exhaustive list of all noteworthy reactions and also think about each reaction for each condition.)

What are we really testing here? Assuming that the reactor is event-driven-ish, it's that the reactor has the right reaction to a particular event. Were the fixture written in Ruby, it would have two methods like this:

  def operator_notified_question_condition(condition)
    # create an event for the condition.
    # Send the event into the system.
    # check whether the operator has been notified.
  end

The name of the method indicates that it's the one called to check operator notified? after the reactor code processes condition. CalculateFixture, unlike ColumnFixture, doesn't stuff values into fields (which isn't something that bothers me, though it does bother some people).

We have to decide what the system under test does and what the fixture does. (A truly hardcore TDD person would put everything in the fixture until there was some reason to move it into the product; I'll skip that.) I'm going to assume the system under test is in the variable @model, and flesh out the above this way:

  def operator_notified_question_condition(condition)
    event = create_event_for(condition)
    @model.accept_event(event)
    was_operator_notified?
  end

  def create_event_for(condition)
    # how to create the event?
  end

  def was_operator_notified?
    # how to check that?
  end
  

The two questions in that code raise questions for the team. Consider the second. It's the product expert we go to when we want to know what form operator notification should take. (Hoping all the while that she knows more about human factors than we do.)

• Her response might be that such and so a light should flash and such and so a message should appear on such and so a screen. In that case, the code could check whether the right messages are sent to the right hardware interfaces (or mocked-out versions of them).

• But I'd be tempted to ask the product owner about the log at this point. A reactor presumably has some sort of logging (perhaps some form of "black box"). Each test column names a significant reaction. Should each be logged? If so, we can just check the log:

  def operator_notified_of?(event)     notification = model.log.most_recent_entry(:type => :operator_notification)     return "yes" if notification.timestamp.later_than?(event.timestamp)     "no"  # returns "no" unless previous line returned "yes".   end

What the second choice lets us do is defer the decision about the details of operator notification until later tests. All I need to know now is that it at least makes a log entry. Never decide today what you can put off til tomorrow.

So I could write accept_event like this:

  def accept_event(event)
    case event.class
    when ReallyHotTemperatureEvent:
       log(...)
    end
  end

So what this test is forcing me (as the programmer) to do is lay down the first bits of event-handling code and possibly the first bits of logging code (which would be a matter of starting to use Log4R or some other logger). Similarly, writing create_event_for is going to mean a little translation of strings and then calls into (as yet nonexistent) event creation code.

So this single high-level test only produces some high-level structural code. Each of the inexact terms - really hot, auto shutdown - will later be examplified (sic) with tests. I find this sort of top-down test-driven approach comfortable to work with. For me, it does seem to result in a lot of backtracking to remake bad decisions about structure. It seems I ought to be able to do better, but that's the way I feel about pretty much everything I do.

## Posted at 12:48 in category /agile [permalink] [top]

Ruby makes the big time

My son is going to a birthday party this weekend. He wanted to get the birthday boy (Jody) two plush toy giant microbes. He chose Ebola and flesh-eating bacteria. (Yes, this was after I made several attempts to get him to choose something less gruesome, like the common cold or ulcer, because I didn't want his mother to think "what kind of bizarre child does my Jody hang around with?" But Paul insisted that Jody really likes that kind of thing. (What kind of bizarre child does my Paul hang around with?)

In any case, he prevailed, and I purchased the two toys at ThinkGeek. Along the way, I took their 46.4 second feedback survey. It asks what your favorite language is. I scanned down to the Rs and was appalled to find that Ruby wasn't listed, though Rebol and Rexx were and Python was just above them. But I later noticed that the list is not entirely alphabetical. Certain languages have been promoted to the front of the list: C, C++, Objective C, Perl, Java, ..., and Ruby. This is the big time, folks.

P.S. If you're from ThinkGeek: sorry about the rant in your Suggestions / Comments / Thoughts / Rants text area. That was before I noticed Ruby at the top.

## Posted at 09:25 in category /ruby [permalink] [top]