Gregory Brown
3/26/2007 7:09:00 PM
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.