From: Gregory Brown <gregory.t.brown@...>
Date: 2007-03-27T04:09:10+09:00
Subject: Re: A sketch for a summer of code application.

On 3/26/07, James Edward Gray II <james@grayproductions.net> wrote:
> On Mar 26, 2007, at 12:48 PM, SonOfLilit wrote:
>
> > Really? This is interesting. Very much so.
> >
> >
> > Could you show a few of these tests that are really problem solving by
> > themselves?
>
> I think Greg just meant that with TDD, you tend to do more of your
> thinking on the test writing side.  Once you have the test framed
> well enough, implementation is just a detail.

Right.  For example, I've got this ostruct based class in Ruport that
I wanted to make act like HashWithIndifferentAccess.

So i went ahead and wrote this:

  def test_options_act_like_indifferent_hash
     opts = Ruport::Renderer::Options.new
     opts.foo = "bar"
     assert_equal "bar", opts[:foo]
     assert_equal "bar", opts["foo"]

     opts["f"] = "bar"
     assert_equal "bar", opts[:f]
     assert_equal "bar", opts.f
     assert_equal "bar", opts["f"]

     opts[:apple] = "banana"
     assert_equal "banana", opts.apple
     assert_equal "banana", opts["apple"]
     assert_equal "banana", opts[:apple]
  end

Just like a good math problem, once you get the details well defined
and sorted out, the implementation is just route manual labor. :)

module Ruport
  class Renderer::Options < OpenStruct
    def [](key)
      send(key)
    end
    def []=(key,value)
      send("#{key}=",value)
    end
  end
end

I initially forgot about the []=, and my tests told me right away! :)

So if you look at most of my math, it's like my code.  I set
everything up the way I want it to work, which if you take that
approach, is almost all the effort.  Then i just fill in the missing
pieces.