On Tuesday 19 June 2007, Mike Malony wrote:
> So I'm working my project, and I've got one other more junior coder with
> me.
>
> Has anyone tried writing test files as part of their spec's?
>
> An overview document would also be needed, and some time walking through
> the expected testing. But it sure would be setting clear expectations.
>
> Comments?
>
Well, generally the Test-Driven Development (TDD) methodology encourages
writing individual test assertions, seeing them fail and then fixing the
current source to have them pass. And repeat.
I find that writing too much testing code at once without having a working
code, and then trying to get it to pass incrementally (using TODO or SKIP or
similar functionality), is sub-optimal.
Eventually, when you finish coding an application the TDD way, then your tests
serve as specification for the code. However, writing a large amount of
testing code, before you have any working code, is not such a good idea,
because many of the testing code will have bugs (and may not even compile),
and it would be relatively hard to fix it incrementally.
I prefer the incremental write-test -> get-the-test-to-pass -> repeat cycle.
If you're planning on writing a comprehensive specification at once, then
while demonstration code would be useful to illustrate the point, it should
still probably be expected to contain bugs, etc. and not be runnable as is. I
suggest you write your real tests incrementally in a TDD way.
Regards,
Shlomi Fish
---------------------------------------------------------------------
Shlomi Fish [EMAIL PROTECTED]
Homepage: http://www.shlomifish.org/
If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
-- An Israeli Linuxer
