I am an old analyst/programmer now converted to a web designer/developer. I came from and still adhere to the sequence of analyse, test plan, design, code and test. This is not a rule in concrete as programming is now modular within a an individual program and each module can be selectively tested, much like program testing before system testing of old, but in a more code precise fashion. It is dangerous to develop a test plan after coding as often the plan will by then be driven by what has been coded rather than what should have been coded. By defnition if a requirement creates the code then the test plan has to come from the requirement. Yes, it would be expected that some tests would fail, but many failures indicate bad programming; ah! for the days of coding sheets,when you had to wait up to a week for the punch cards be submitted for compiling (another few days wait).

regards
George

For instance, while writing your unit tests, declaring a non existing object, will give an on the fly error, where the developer can test-fail and then correct immediately by allowing eclipse to auto generate the object. this applies to other properties of the object as well.

1) Code is really a one-man project,
2) It is really redundant, see tips for writing good unit tests, you don’t have to test everthing, you have to test cleverly.

There is a very good tutorial on Micoroft site, named Unit Testing Tips.

1. Discover a bug
2. Write a test, make sure it fails (and actually catches the bug)
3. Fix, watch things turn green.
4. Rejoice.

Making sure the test fails is crucial here, otherwise you could be testing the wrong thing.

For new code, I try to write tests and code simultaneously rather than before or after. My typical setup has 3 terminal sessions side by side: one for code, one for the tests for that code, and one for running tests and keeping test output visible while I tinker. Writing the test as immediately as possible means I can run it immediately and know that I’ve left myself in good shape before moving on to writing the next piece of code.

For changes to code that’s already well-covered, I focus on always updating the test (or adding new tests) first, as test failures make a nice to-do list. Once the tests are passing again, I’m confident that I’m done and can move on.

And of course Titus Brown’s (in)famous remark about TDD comes to mind — “I don’t do test-driven development. I do stupidity-driven development. I wait until I do something stupid, and then write tests to avoid doing it again.”