How 10 lines of Unit Test Could Have Saved Me From Hours Of Production ReDeployments
“Unit tests are tests written by a developer.” This was a statement that I learned in the days of my college. Learning this statement for a probable MCQ of 0.5 marks in the test was as easy as it could get, but I didn’t really know what that meant or what really a unit test is. Few years after successfully scoring that 0.5, I was into my professional life, and writing code was my full-time job. I had always thought, a developer just writes the pieces of code, which creates something, and writing the test of any kind is handled by a QA professional.
Forget about writing a spec, I didn’t even know why a freakish-looking file with a spooky name that ends with spec ever exists. So, my intro with specs started with a frown.
“Are specs something to be written by a developer?” was the question, I asked once, and with a raised eyebrow from the other side, I got “Yes…”, though I didn’t speak out, there was a big “Why…” within me.
Writing any kind of unit test was the last thing I would want to do, and wouldn’t exceed even a single line of it, unless, it was extremely important and triggered the rude Butler — Tool to automate tests.
A question always existed within me: Why would we even write unit tests as the whole purpose of writing it is to test the proper functionality of the function, but as a developer, I have already tested it, so according to me it was just the burden of “The Best Practice”, we have to carry.
Yeah, you know that thing that stops all the questions, the showstopper in the world of software development, “The Best Practice”.
Recently I was building a feature that would require the URL of the current page the user is in, and there was a function that would act as a utility that returned a certain attached value in the URL. No big deal simple-looking fleet function. However, there was a very important decision to be made based on the value that function returned, as there were 3 different values that could be returned based on the input(URL) provided. So, this function was somewhat like Morgan Freeman’s role, it could be small but makes an important decision.
To my audacity, I avoided writing tests for this function coz, for me this function was not a big deal, it was simple, small, and did a very limited defined job.
Deploying in production is “the job”, which requires other jobs to be done first. Saying this, I mean we think, design, team-up, develop, shout, scrum-up (…..a lot of stuff) for a feature to be finally deployed to the production and released. So, when you build up so much for that climax moment of deployment, it’s for sure, you want everything to go as planned.
Staging, UAT, and production, three stages of deployments, this could be a standard to be followed, and I think staging and UAT should try to imitate the production environment to the highest level possible.
But no non-production system would be able to simulate production, and you don’t deploy in production whether to check it runs or not, you deploy expecting that it should run. And here turned up the moment of realization for me.
The function I had written worked seamlessly in both the staging and the UAT environments, but it failed in the production.
As mentioned above when you show the green signal from staging and UAT you expect the things to run in production but again no non-production system would be able to simulate production, as it was in this case even though the UAT system was a blueprint of production there was one thing that was different between the UAT & the production environment, and that was their URL, and the difference in the URL caused the function to break.
No one is to blame here but me, nevertheless what I learned was something that changed my outlook towards writing tests. Even if you test completely in the testing environments whether it is staging or UAT, the assurance of software is not completed until it gets to the production, and testing is not something we expect to do in production, rather we expect things to run in production.
So, unit testing is that one antidote that can help the replication of production environments at the functional level which means, every function unit that builds up the software can be tested individually and collectively with the production level parameters with the help of unit-testing, as in my case if I had written a unit test, I would have got the power to send the URL of the production environment to the function which then would have thrown the error, and help avoid the Hours Of Production ReDeployments.
In short, unit testing became cardinal for me. It’s somewhat like proactively diagnosing faults in every functional unit you’ve written which then prevents you from the reactive fiasco post deployments.
What do you think are Unit tests just another brick in the wall of best practices, or is it something that’s unavoidable for best quality software?
