In this time of TDD, the obvious question is, “why?”
(Or possibly “what the hell is wrong with you?”)
But I think I can explain…
Why are there no tests to begin with? It is sort of obvious if you have been at this for a while: legacy apps. All the Cool Kids have the privilege of working on the Latest Thing all the time, but reality is that a lot of the world runs on legacy code, from the dark times before modern testing tools and dev methodologies were common. Why do this now? Again, it’s about legacy code. It’s live, mission-critical, and we need to upgrade underlying dependencies. Since the app provides services to live client websites, it’s unwise to either keep running on old iron, or to roll out anything new without testing.
Writing tests after the fact is definitely backward, and there are some pitfalls, like tests that (erroneously) will never fail, so this takes a bit more care. Since the legacy code is eventually going away, there’s no sense in writing unit tests for something that already works, so the focus is on feature/acceptance tests.
Tests will run both virtually (locally using simulations of client resources,) and live, where we really hit our clients’ web sites to verify the app’s working right.
This is not the best scenario but there are few options since it’s impossible to replicate all our clients’ environments in the lab, and the very slight traffic won’t matter to anyone. When the test suite’s complete, the plan is:
- Test in the virtual environment tests to uncover and fix any issues
- Roll out the updates, then immediately run the tests against our clients’ live sites to make
Automating the live tests means we can get full coverage, and can quickly revert in case of problems. This will still be a php app (big sigh,) but the platform and code base will be up to date and we’ll be prepared for the time when we need to replace it.