[TIP] Column questions.

[Andrew Dalke]

Laura wrote:
>     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'
> approach.

I see.  Checking now, http://www.extremeprogramming.org/rules/spike.html
   "Most spikes are not good enough to keep, so expect to throw it  
away."

> 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
   http://en.wikipedia.org/wiki/Test-driven_development
are correct:

      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.

				Andrew
				dalke at dalkescientific.com