For us to be able to drive our development through tests, there are certain things that are required on the technical side to make this workable. For example, if our tests take 2 hours to run, then running them before making every small change is not practically viable.
Software that is test driven has high test assurance, meaning we’re fairly happy with how much of the code is covered by tests, so that we can happily refactor. Therefore, to maintain that, we must be able to run our tests at any given moment in order for us to have the confidence that they are always happy. This is true for unit tests, integration tests and regression tests. Our tests MUST be:
– quick to run
– cheap to run
– easy to run
Our code must also be quick, easy and reliable to build and deploy at any given moment. For this to be true, it must ALL be fully automated. This in itself is a huge investment, and is a big reason why delivery managers are reluctant to allow for it – spending a large amount of time on improving the code is time and resources spent with no “noticeable” deliverables. However, the code improvements generally pay for themselves very quickly – and you end up with a happy code base that is durable and sustainable, and can start implementing new practices such as TDD and you get all the benefits mentioned in the previous post.
Eliminating Legacy Code
The definition of legacy code is code which is not suitably covered by tests, so making changes/refactoring cannot be done with confidence that existing functionality is not broken. Hence, any changes may lead to a bug which could hide in the code for a long time, and by the time it manifests itself the bug is exponentially bigger than it would have been, had the code just been tested properly. Woe is me!
The first thing to do, therefore, is try to eliminate legacy code. Don’t try and do it all at once or you’ll never go home! But remember the boycout rule:
Always leave every campsite a little bit cleaner than how you found it.
Therefore, when attempting to change legacy code:
– identify the part of the code we want to change
– identify inflection points (the bits that would break if the code is changed) and write automated tests there.
– to begin with, these will be slow, complicated, expensive integration tests
– if automated testing is not possible, we may have to resort to testing manually and retest after each refactoring *yawn*
The most unacceptable, ridiculous, diabolical approach, is to simply not test. If you even consider that, young sire/madam, then YOU are part of the problem. Consider yourself chastised.
That is all.