Thu, 08 May 2003
Learning tests
Mike Clark writes about
learning tests. They're tests he writes to figure out an
API. He's made me think about one of my habits.
I tend to use the interpreter for learning. Where Mike
describes writing a test to see what the return value of a method is,
I would do this:
irb(main):001:0> load 'timeclock-web-services.rb'
true
irb(main):002:0> session = start_session
#<Timeclock::RichlyCallingWrapper:0x358094
@wrapped=#<Timeclock::RichlyCalledWrapper:0x3580bc
@wrapped=#<Timeclock::Server::Session:0x35aa88
@user="web-services-default-user",
@active_job_manager=<ActiveJobManager: {}>, @records=[],
@jobs={},
@persistent_user=#<Timeclock::Server::PersistentUser:0x35a3f8
@user="web-services-default-user">>>>
irb(main):003:0> puts session.methods
last_change_log
last_command
wrapped
method_missing
last_complete_result
...
What does this gain?
It's faster than going through a testing
cycle. I suspect I ask more questions than I otherwise would, because asking a
question is so easy. I'm more apt to
explore rather than stick to just what I think I need to
know. The interpreter tends to spew out a bunch of info at
once. The several lines above show the contents of an ActiveJobManager within a
Session within a RichlyCalledWrapper within a
RichlyCallingWrapper. So a single question tells me a lot about what's
going on, even though the spew is roughly
as obfuscated as XML.
In contrast, in a test, I get
only the answer to the question I think to ask.
What does it lose? (Leaving aside that you can't do it in Java.)
You lose the tests and the documentation they provide. (I've never
been quite comfortable with tests as documentation - I'd rather go
to the code - so I think I underplay that testing role.) Mike
mentions extracting code for dealing with the API from the
tests. I do some of that, since I will often write a little file of
utilities that I load to help me explore. But they don't tend to
get preserved and reused. Having a file full of tests probably
encourages methodical exploration, whereas an interpreter
transcript makes it easier to overlook things. (This is the flip
side of the last of the advantages.)
I've done roughly what Mike does, but only (I think) when I'm trying to learn a
package preparatory to changing it. That's a different
dynamic. I'm acting mostly as a maintainer who wants a safety net of tests,
not just as a user of the API. So
I think I'll adopt Mike's style next time I want to understand an
API. Since Mike's doing some Ruby, maybe he'll try my style. I bet
there's a blend that's better than either: a way of rapidly cycling between typing at the
interpreter and typing tests in a file.
## Posted at 15:35 in category /testing
[permalink]
[top]
|
|
