Safety nets

I’d like to outline some of the steps I think we’ll need during development to start improving code quality. One of my main concerns is making sure that refactoring does not introduce more defects. We need some kind of safety net, something in addition to regression testing by the system testing team. Speaking to several coaches at XP day, they mentioned acceptance tests. I’m getting quite keen on this now, and have been reading into FIT and FitNesse. But again, this is something new in our development process that needs to be given a management “Green Light”. But for now, I’m using FitNesse to “evaluate” it!

Below are some steps devs could follow, initially with supervision, for working on a fix/enhancement where code can/should be cleaned.

1. Document existing behaviour of the particular area for acceptance criteria (if we agree we can work with FitNesse, then this would just be documented in FitNesse wiki form).
2. Clean the code around the area of the fix/enhancement, implementing unit tests.
3. Verify that the refactoring hasn’t broken existing functionality using acceptance criteria (run FitNesse tests).
4. Update acceptance criteria with new requirements for the piece of work (not necessary if the piece of work is not changing functional behaviour).
5. Update/create unit tests for the code changes.
6. Implement the fix/enhancement.
7. Validate unit tests pass.
8. Validate against acceptance criteria (run FitNesse tests)

This is a bit of a “test first” approach, however we still don’t want to enforce TDD at the unit test level, so I guess it can be left to the developer to decide how to implement the fix as long as there are unit tests with good coverage at the end of development, and they all pass.

With acceptance criteria, I think it is best to establish how the system currently works and how the system should work before making changes. If we can’t use FitNesse, then the “validate against acceptance criteria” parts will have to be manual, where the dev runs through the working system.

All of these code changes will still need to be validated by system testers, until some point where we have collaboration between dev and test perhaps around acceptance tests.

How will we deal with this increase in both dev time and test time? I hope that management can still see the value in this investment.