[TIP] Column questions.
dalke at dalkescientific.com
Thu Jul 24 08:26:09 PDT 2008
> Not for me, instead it makes it a lot easier for me to modify
> my API. But then I am a 'design your API last, or at least
> fairly close to the end of the process' sort of person.
I'm more of an API first, although I can also be algorithm first,
in order to figure out where good entry points are.
I remember one time working on a project and I didn't get
a good handle on how to decompose things until I sketched
out the top-level code. Mind you though, the code only
took a couple of days to write, all told, so it's not a
big design up front sort of thing.
> Only some agile approaches advocate the 'throw the spike away'
I see. Checking now, http://www.extremeprogramming.org/rules/spike.html
"Most spikes are not good enough to keep, so expect to throw it
> So this is interesting to me, because the times when I find
> myself rewriting the tests so fequently that it is annoying
> pretty much always mean that I've screwed up by prematurely
> creating a too rigid API in the first place.
Part of iterative software development is to get something
working and refine it. I know that I'm writing a first draft
of the system and there will be problems. My goal is to
fill in the details and iterate until things are smooth.
So yes, I know it's a too rigid API, but I wouldn't call it
prematurely so. It's too rigid by intent, so I know where
I .. need more padding? Can take the edges off?
Besides, being too flexible is often a YAGNI thing. ;)
> It sounds to me
> as if your frustration may be of the same sort -- it's not the
> updating of your tests which are bothering you, but the updating
> of them to something which is only doing to be thrown away in
> another half hour or 45 minutes or 3 days that is annoying you.
That's absolutely it. I know that I'm writing code that will
change, and if I'm doing test-first development, meaning I'm
not writing code until I have a test to indicate the need for
the code, then I'm annoyed because I'm writing support code
that does me little good.
BTW, I'm assuming that these quotes from
Test-driven development requires the programmer to
first fail the test cases.
Another advantage is that test-driven development,
when used properly, ensures that all written code is
covered by a test.
You can ask how I test if my new code works without
having tests for it. I do have tests, but they are
just enough for me to know I'm on the right path while
I get the pieces to hang together and I don't use them
the TDD way. Often they are in the __main__ at the end
of the module, which makes it easy to jump between
implementation and test code.
I could use unittest for them, but at this stage the
extra import/class/function/unittest.main can feel like
too much overhead, compared to a simple 'assert a==b, (a,b)'
I of course do make unit tests once things have firmed
up a bit, and they've proved helpful. But not early
on when I'm still trying to figure out what the functions
and classes do and what to name things.
dalke at dalkescientific.com
More information about the testing-in-python