A prime example of why automated testing works…

Today I got to a change request that read something to the order of ‘move all this code from place X, the new namespace Y. By the way, it is referenced all over the place.’. This could easily have been a dawning and over whelming task. Moving massive piece of logic that is core the operation of the application…AND cause no errors into production? Ugg..

I started out my moving the classes and find/replace (f/r) the namespace declarations. Ran test, failed; check error log. Log states class not found.  F/R use statements, run test: fail; check error log. Log states class reference not found. F/R inline usage statements, run test: fail; check error log. Log, weird error about not being able to instantiate something something. Fixed that, ran test: pass. Ran entire test suite: passed.

Imagine, if you will, that this change was request on a massive system. The more complex a system gets the more effort is required to execute a change. More effort = more time, more headache, more hating your career choice.

  • Total time to execute the requested changes in this example: < 4 hours.
  • Confidence nothing broke: > 95%.
  • Happiness tests saved some sanity and made the morning pleasant: > 100%.

Tl;DR: Testing works. It’s an level of assurance that your changes did not introduce breaks in a system that is know to operate correctly.

Leave a Reply

Your email address will not be published. Required fields are marked *