Rethinking legacy code and testing - Challenges and Strategies for Testing Legacy Code in Agile Teams

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Previously, I discussed legacy code and the strategies to test legacy code bases (Marabesi, 2019). In short, the strategy is based on a code base without any automated tests. The suggested approach is to follow a strategy starting from acceptance testing and gradually refactoring the code to get to the unit testing level. Ideally, the code base would have several acceptance tests, and then the refactoring will start, replacing the acceptance test suite with unit tests.

The proposed strategy is based on a single real-world project, which may not fit all projects. Before that, I wrote an introduction to TDD following the red-green-refactor flow (Marabesi, 2015), and I also discussed using TDD as a strategy to improve the structure of legacy code (Marabesi, 2015). However, those are rather technical and focused only on the fact that the messy code was already there. This post is a reflection on my thinking and experience since those posts.

Companies and dead lines

Often, programmers are working against the clock to meet deadlines that usually are not set by them. The deadline is given by management, and there is no negotiation. The pressure to write code and deliver on time plays an important role in not allowing the programmer to think and expand on important areas, such as security, testing, and the maintainability of the code. Everything is for yesterday, everything is late, so we need to hurry and deliver as fast as possible.

The SCRUM era tried to mitigate the time issue with sprints, which to some extent helped teams to self-organize and negotiate what will be delivered in a specific time frame. Of course, this is not a silver bullet, which brings an old known friend: estimation.

Even with the benefits of having a specific time frame and not having management imposing a deadline anymore, programmers face the pressure to deliver due to the lack of “precise” estimation.

Developers that don’t know testing

Often, developers starting their careers are not aware of testing. We can expand the argument by going back to the university, where testing is focused on a single event during the development cycle, usually after the development is done.

The line that is drawn, then, goes from the university to the professional life of new developers. To emphasize this thinking, in the development industry, testing or quality are often traded when it comes to delivery.

This creates confusion in “modern” agile software development: how can it be agile without testing? Extreme programming addresses this issue by pushing towards responsible development. The developer owns the code and the responsibility of testing the code and ensuring its quality.

Management, often an issue

The link between management and development is, in my opinion, difficult. XP (Beck & Andres, 2004) is superior to SCRUM, as it was the base for starting agile development (Fowler, 2013).

References

1. Marabesi, M. (2019). STRATEGIES TO TEST LEGACY CODE - PART 1. https://marabesi.com/javascript/2019/01/14/strategies-to-test-legacy-code.html
2. Marabesi, M. (2015). ARE YOU NOT USING TDD ?! - PART 1. https://marabesi.com/tdd/2015/04/19/not-using-tdd-part-1.html
3. Marabesi, M. (2015). ARE YOU NOT USING TDD?! – PART || (LEGACY CODE). https://marabesi.com/tdd/2015/05/23/are-you-not-using-tdd-part-legacy-code.html
4. Beck, K., & Andres, C. (2004). Extreme Programming Explained: Embrace Change (The XP Series). https://www.goodreads.com/book/show/67833.Extreme_Programming_Explained
5. Fowler, M. (2013). ExtremeProgramming. https://martinfowler.com/bliki/ExtremeProgramming.html