On Wed, Jan 7, 2009 at 3:25 PM, David Hamill <[email protected]> wrote: [...] > Maybe some much more organised people than me can specify > exactly what they want upfront, then write the tests to > reflect the specification, then write the code to pass the > tests.
If you're employed to write software, then this is exactly what you're supposed to have before your hands touch the keyboard. > But an acknowledged problem with software development > is that you don't really know what you want when you start > out (you just think you do), IME, the problem is not having enough time to constuct the tests (because, of course, software engineers are the one's that do it, not the people who wrote the specs or a separate department.) > it's difficult to write a watertight spec, QFT. > and ideas evolve as the project progresses > and in response to user feedback. Or because the spec has holes in it. > My personal solution is to write the tests and the code in > parallel, a few lines at a time. The way I exercise the code > is by running the tests. That sounds like white-box testing (testing what you know to be in there;) you need black-box testing in there as well (testing without any assumptions about what's in there.) -- PJH http://shabbleland.myminicity.com
