Entropy Happens
If you have a car, truck, motorcycle, bicycle, or some other form of transportation made of metal, you know that rust is your enemy. You know that either you keep a vigilant eye out for the smallest speck of rust and eradicate posthaste each one you find, or before long you'll have nothing but a junk heap. You know that the environment in which you use said vehicle has a major impact on the level of vigilance you must maintain. Road salt, for example, will eat through your undercarriage in no time, but if you live in a temperate clime you can keep even vintage cars running well with little trouble. (I remember being amazed when I visited Uruguay some years back at the large numbers of classic cars in mint condition being used for everyday transportation. Then I realized they didn't have to deal with snow and all the nasties that come with it.)
The same holds true for code and test cases. If you truly care about the code and test cases you write, you work and mold and craft them into exactly the perfect shape for what they need to do and test. The second you check them in to version control, however, they start to deteriorate. The application changes and so other code gets written around them and other tests are created that partially overlap them. Everything starts to rust.
To combat this you must stay vigilant. Watch for changes that aren't quite in keeping with the original design's vision. Watch for changes that really should drive changes in that vision. Watch for changes that necessitate modifying existing test cases - or deleting them. Watch for changes that might require adjusting your testing strategy.
As is the case with automobiles, the environment in which your code and tests live has a huge effect on how easy or hard it is to keep the rust out. If you practice YAGNI (You Aren't Going To Need It) and so write only that code that is absolutely required, if you continuously refactor your code, if you write your test cases in terms of user actions rather than UI details, if you only automate those tests that are worth automating, if you pair program and pair test everything, rust will have a hard time getting a foothold.
If (as tends to be the case) your environment is rather more messy than this ideal, then you have to balance scouring the rust from your code and test cases against writing and testing new features. I find that the time required to keep my code and tests clean is more than paid back by the speed with which I can change, enhance, and add to them, so I will always advocate for clearing out rust over any other priority. Sometimes I'm overruled. Such is life.
My code and test cases are rustier than I would like but not as rusty as they could be. How about yours?
*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.