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