Test, Test and Test

... and consider one or more test, just in case.

Currently I'm working in a project where , as usual, changes in requirements are very common, and that's ok, we live in a world of agile projects were things like these are welcome. That is why we have a group of techniques to accomplish these changes (refactoring, version control, powerful IDEs, design patterns, etc.). The project was started by other development team some time ago, now a new team (I'm on it) is maintaining and changing it according to the new requirements.

When we have a new change to include in the system, basically we do things like:

• Limit the change with the business owners to understand why it is needed and what we must do.
• With the team, we design an initial model that include all the changes to support the new functionality.
• Measure the impact that these changes will have in the previous code.
• Here comes the funny part, refactor all the code to make it work with the new structure.
• Test the functionality to verify it works as before plus the new changes.

When the structure of the code makes difficult to find exactly how far the impact of a change will propagate (my case and of course we are trying to correct that), it is necessary to write, think or define some way to provide an infrastructure to test the system in order to make it work correctly and with that keep your good image with the customers.

This is where the post goes, remark the importance of having a way to test the functionality of a system that has already been deployed. We have had a bad experience about this, we didn't have a clear way to test all the code that used to work before we implement a new change, as a consequence of this when the system is redeployed the users of it will face some awful problems and, of course, they will not be happy and you, as a developer, will have to work under pressure and believe me that is not good for anyone because it easily will lead to alter other functionality in order to get the previous one to work as desired.

To sum up consider these points due to bad testing:

• Work under pressure
• Create more problems instead of solving them
• Make a user unhappy
• Forget about the nice work you were doing before the error came up
• Redeploy the system in order to correct the error
• As a consequence of all the above, your schedule will be late

and now consider these points of good testing:

• Work on what you want to do
• Make a user (and you) happier
• Have some free time to spend in making the system and the user experience better
• Enjoy a productive day
• Sleep nice and peacefully at home

So what is better to do, in order to have a nice work environment? Yeah you are right, develop a way to test after a big refactor has been done.