Skip to content

Introducing unit tests to a monolithic application, a case study

#case-study #unit-test #testing #PHP #code
Not all stories have a happy ending, but I am a firm believer that we can also learn from our failures. This was one of those occasions, so let's look at the time when I tried to get my unwilling team to adopt unit testing.

The year is 2019. I have just joined a new team and a new project that summer, and I was exploring the stack and the projects when I noticed that unit tests were missing entirely. Coming straight from another project which not only had the test automation integrated into the pipeline but we also worked with a test-first approach on the backend (you can read more about it here), this was immediately alarming to me.

It was my first week on the job, and since I had no other assignments yet, I decided to go on a quest to fix this problem.

The problem

It is never an easy task to introduce tests to an already established system. Sure, there are good first steps, such as writing tests for every newly created code, but how do you test existing functionality?

This particular application was not only a very large and already established application, it was also a product that was migrated from a legacy framework in a haste, and as a result, there were a lot of duplications, things were copied and pasted without much refactoring, even if some things no longer made sense in the new framework or could have been done in a simpler way.

At this point, I still didn't consider myself an experienced unit tester but I knew enough not to want to test badly written code - you're only asking for trouble if you do that, because writing unit tests for spaghetti can make it even harder to change in the future. Oh, the nightmare!

Moving forward

There is no great magic to it, I simply installed the Codeception package to our project, or rather the Yii2 module for it. The benefit of this testing tool is that it allows for functional testing, which can be a slightly better idea than unit testing old code, since functional test (or integration tests) are "more black box", they are less concerned with the underlying implementation and more concerned with outcomes and component interactions.

I had time, so I immediately tried my hand at writing some simple tests for the login action and some other basic things.

My changes got accepted in the main branch, so Codeception was a part of our applcation moving forward.

Where it all went wrong

I was determined to test every new code I wrote. However, since I wasn't an experienced tester and the framework was all new to me - not to mention that I just returned to PHP development after more than a year of working with Ruby and Javascript exclusively -, so I felt that testing was slowing me down more than I liked.

As a result, I gradually slipped up and stopped writing tests entirely.

The tests were never included in the pipeline as a quality gate, and my team never got behind the idea of writing their own tests. In the beginning, I also had plans of organizing workshops for our team to explore and learn testing together.

I could have done better

In hindsight, I was obviously not ready to push this initiative. It's a very difficult thing to do, especially because nobody likes when a newcomer joins the teams and starts introducing new and foreign changes.

I think I gave up too soon and I should have allowed more time to pass until I get to know my teammates better so we could start a conversation about introducing better testing practices, and come to a common agreement on how to approach the problem.

The workshop I had planned also never came to fruition, I mentioned it a few times but it was hard to organize as we were a fully remote team.

This try was unsuccessful, but I didn't give up on my conviction that testing is ultimately beneficial and I tried to introduce changes on a much smaller scale instead: educating myself to have a better understanding of testing, what makes a test good or bad, and reviewing this failure to learn from it and change my approach so I can be successful next time.

End of article