Sad or not, in the past one and half years, the company I am working for wasn’t keen on writing unit tests. Although our manager insisted on writing as many tests as possible, he couldn’t push back the business to give us some time to make testing a reality. The board members kept sending new feature requests with short deadlines, leaving us no time to write quality code. We had to finish off the tickets ASAP.
That is until something changed. The team started receiving more and more bug tickets. The stories were coming in without slowing down in the meantime. People on the project started burning out. Having unpaid overtime, more meetings, and more questions about how to finish off all the tickets we have. The team began to get irritated, and we attacked each other due to a lack of energy—many quit.
I am not sure if that had anything to do with it, but as the last feature rush was over just before Christmas, we started to get back our time. Although we, developers, were blamed for low code quality, they wanted us to feel ashamed for that. We also started getting tickets for improving code quality instead of new real features.
Suddenly the expectation changed drastically. From nowhere, our pull requests got rejected unless we had 100% code and branch coverage. That is how we realized; we have to write code differently. No one warned us; we just found out through PRs. Not a great experience, but still a relief.
Now we are at present when I am writing this article for you. I am writing unit tests for a week now, and it seems serious. We are not just allowed; we are required to write those tests. Since I am writing unit tests for a production code, it is quite challenging without the full power of the testing library of our choice: xUnit. I can write tests, but in the meantime, I have to refactor all the code, and I have to make sure not to break a feature. As a result, the QA (Quality Assurance) guys have to spend days retesting the application’s affected area. I know I cannot prevent that from happening just by learning a testing framework, but I will minimize the problems in the future.
I am sure and convinced of previous experiences, knowing your tools as profoundly as possible can enhance your productivity while saving a lot of time in the long run. Of course, you need a lot of work with the tools to worth learning deeply; otherwise, you wasted your time and energy for not using your new knowledge enough. That is why it is worth reconsidering how well you should know your tool. I waited for a week, learned through working experiences and some random how-to posts. But as it seems I have to spend a lot of time working with XUnit, it is worth knowing this tool deeply.
