There has been some discussion of the application of agile principles including test driven development in the office recently. Having been working on a highly concurrent, scalable SIP application server my feet are firmly in the test first, test often camp.
Our testing strategy includes:
* unit testing, usually using mocks and dependency injection
* acceptance testing, using FitNesse
* robustness testing, using custom scenario handlers
* performance testing
These practices are dependent on the type of project, but we've found that although unit testing is done before the functional code is written, the other tests are usually written afterwards. I like to think that acceptance tests demonstrate completed user stories and robustness tests exercise common scenarios, concurrently.
A robust application comes with time, but through concurrent testing, issues can be drawn out earlier and the confidence you have in your application grows.
1 comment:
We started trying to write acceptance tests first...well more like concurrently. Utilized suite filters found (but only documented in the release, not on fitnesse.org). That way we can have our customer (myself) write failing fitnesse tests and mark them as fail, but not fail the build. Then slowly over the iteration, move them to pass and if that fails, then the build fails. Check out ChitFitnesse...
Worked really well for us
Post a Comment