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

Previously I discussed about legacy code and the strategies to test legacy code bases [1]. In short the strategy is based on a code base without any automated tests, the suggested approach is to follow a strategy starting from an acceptance testing and gradually refactor the code and 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 in a single real world project, which may not fit all projects. Previously to that, I wrote an introduction to TDD following the red-blue-green flow [2] and I also discussed about using TDD as a strategy to improve the structure of legacy code [3]. Though, 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 against the clock to meet dead lines that usually are not set by them, the dead line is given by management and there is no negotiation. The pressure to write code and delivery on time plays a 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 delivery as fast as possible.

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

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

Developers that don’t know testing

Often developers starting their careers are not aware of testing. We can expand the argument going back to the university, where the testing is focused on a single event during the development cycle, and 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 the thinking, in the development industry, testing or quality are often treaded when it comes to delivery.

Which in the “modern” agile software development is a confusion, how can it be agile without testing? The extreme programming somehow address this issue pushing towards a responsible development. The developer owns the code and the responsibility of testing the code and ensure its quality.

Management, often an issue

The link between management and development is in my opinion, difficult. XP [4] is superior to SCRUM as it was the base for starting the agile development [5].

References

  1. [1]M. Marabesi, “STRATEGIES TO TEST LEGACY CODE - PART 1,” 2019 [Online]. Available at: https://marabesi.com/javascript/2019/01/14/strategies-to-test-legacy-code.html. [Accessed: 14-Jan-2019]
  2. [2]M. Marabesi, “ARE YOU NOT USING TDD ?! - PART 1,” 2015 [Online]. Available at: https://marabesi.com/tdd/2015/04/19/not-using-tdd-part-1.html. [Accessed: 19-Apr-2015]
  3. [3]M. Marabesi, “ARE YOU NOT USING TDD?! – PART || (LEGACY CODE),” 2015 [Online]. Available at: https://marabesi.com/tdd/2015/05/23/are-you-not-using-tdd-part-legacy-code.html. [Accessed: 23-May-2015]
  4. [4]K. Beck and C. Andres, “Extreme Programming Explained: Embrace Change (The XP Series),” 2004 [Online]. Available at: https://www.goodreads.com/book/show/67833.Extreme_Programming_Explained. [Accessed: 15-Feb-2021]
  5. [5]M. Fowler, “ExtremeProgramming,” 2013 [Online]. Available at: https://martinfowler.com/bliki/ExtremeProgramming.html. [Accessed: 11-Jul-2013]
Made with 💖 by @MatheusMarabesi