To view parent comment, click here.
To read all comments associated with this story, please click here.
Unit tests are as important as anything else. There are a series of tests that need to go into making quality software. If any step of the process is skipped, your standard of quality goes down. The more complex the system you are creating is, the more important this is.
It starts with unit tests, which each test a small atomic unit of work and run very fast. These should be all pass in a module the developer is working on at the least before every check in. This is a safety net for regressions due to bug fixes, and also increases confidence for refactorings. If you need to change the way something works, through unit tests you have immediate feedback on how those change impact the rest of the system.
Check ins should trigger automatic builds, and those builds should trigger integration tests. Integration tests are more end to end, and will interact with outside infrastructure (like databases, web services, etc).
There should be nightlies that go out to QA. QA runs scenario tests where they methodically hammer at the software through the interface. The scenarios they use should be written against the specs.
There should also be performance tests at the end of an iteration, (2-4 weeks) so that you are able to track the performance impact recent changes have had on the system.
Keep in mind I am an enterprise guy passionate about agile in general, and SCRUM in particular, so if I talk strongly about testing that is why. But I strongly believe there is no way to create quality software without the right kinds, and the right amount of testing.






Member since:
2006-01-02
I agree... nothing is more useful (for lower layer software,to be sure) than a set of great assertions so that the debug builds of the code test themselves to the greatest extent possible. And of course a set of unit tests to drive the system through at least the mainstream cases.