TDD

Yesterday, I wrote about legacy code and how it really was not possible to initially do test driven development, aka TDD. In this post, I will detail a strategy which I feel is good at explaining how to go about testing. I make no guarantees that this is the best way to go about it (please feel free to suggest other tricks you might use), but it works. But these are useful for me in porting Medusa V2 code to Medusa V4 (long story about why not V3, but there are reasons).

I am sure many of us have faced the task of trying to do test driven development (TDD) on a legacy codebase. I myself am facing such a challenge, with several tens of thousands of lines of code in a Laravel project which I am helping maintain and is around a decade old. And being severely behind in the packages it uses, the time has come to give the code some TLC, and update it to use the most recent versions of those package (for example, we are moving from Laravel 5 to 12).

When it comes to computer programmers and even computer aficionados, there are a number of things which are subject to debate, and at times, these can almost approach a religious holy war given the right individuals. Examples of some of these include "PC" vs. "Mac", "Windows" vs. "*NIX", "vi" vs. "emacs" and more. So it is of no surprise that even within testing, and specifically unit testing, there are some areas were competing  ideas can cause similar reactions.