Legacy Coderetreat: Episode 4 – Add Feature on Legacy Code – Code Cast

Add feature on legacy code – code cast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a code cast in Java. We have a new feature request and we need to add it to a legacy code base.

We start by understanding what we need to change. After that we run the existing system tests, that we wrote during the session From Nothing to System Tests. We use a test coverage tool to understand how much of the code is covered with tests. After this step we start writing new system tests until all the code
that will be changed is covered by tests.

When all of the system is covered with tests, we refactor the code to make room for a new feature. We extract a method, then a class and then an interface. The interface is implemented in a new way so that we add the new functionality. Adding the new functionality is done with tests written up-front.

At the end we write one system test to verify that the whole system can work well with the new feature. This is a kind of partial acceptance test that helps us understand if all the system works well together. And of course, manual testing and refactoring is essential before we can say we are done.

See more about the technique in the blog post Add Features on Legacy Code.

 

 

Acknowledgements

Many thanks to Thomas Sundberg for proofreading this post.

Legacy Coderetreat: Part 14 – Document possible Defects with tests

Document possible Defects with Tests

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

When writing unit tests on legacy code, we often discover behaviours of the system that seem wrong. The main rule is: DO NOT change the production code without being absolutely sure that the change does not introduce defects. Instead we need to mark all the tests that characterize a possible defective behaviour. Let’s look at some ways to document possible defects with tests.

Document Possible Defects with Tests

Document Possible Defects with Tests

Read More →

Legacy Coderetreat: Part 13 – Unit Testing on Legacy Code

Unit Testing on Legacy Code

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

In the previous episode post we extracted a class. The code we just extracted is tested at this moment only with System Tests. Now it’s the time to start writing unit tests, considering that we already have some system tests in place.

Unit Testing on Legacy Code

Unit Testing on Legacy Code

Read More →

Legacy Coderetreat: Part 12 – Extract class

Extract Class

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

When working with existing code we need to look at the responsibilities of existing classes. If one class is too big, we need to extract new classes from that initial class. A class too big means that it’s not respecting the Single Responsibility Principle.

Extract Class

Extract Class

Read More →

Legacy Coderetreat: Part 11 – Refactoring Rule of Three

Rule of Three

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

The rule of three says:

Extract duplication only when you see it the third time.

This concept is extremely useful when you want to improve legacy code, refactor in the TDD cycle or just improve existing code that is covered by tests.

The Rule of Three brings higher coherence and more clarity to the system, because the duplicated code starts to be moved into specialized areas. In this way we optimize the code base for changeability.

The Rule of Three prevents from prematurely extracting possible duplication and defers the duplication minimization until we have enough proof.

minimize-duplication

Read More →

Legacy Coderetreat: Part 10 – Extract pure functions

Extract Pure Functions

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

We have some class that is very big. We want to divide the existing code into more methods and classes so that we have in the end some code that is easier to understand. If the methods are small, they are easy to change. In the same time the code would respect the Single Responsibility Principle. We optimize our software for changeability. In the following we will see how we can extract pure functions to achieve that.

Pure functions

Pure functions

Read More →

Legacy Coderetreat: Part 9 – Use Mocking Framework

Use Mocking Framework

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

By using mocking frameworks we are writing short and easy to read tests. The duplication of test doubles written by hand is minimized by the use mocking framework.

mocking-framework

Read More →

Legacy Coderetreat: Part 8 – Extract and Override

Extract and Override

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

Almost always when needing to test existing code we bump against dependencies that make the system untestable. This technique is useful to extract the static dependencies. After that we can use dependency inversion in order to be able to really test the systems.

With this technique we can transform untestable systems into testable systems, step by step. The steps are small because we want to enable safety while changing the code.

Extract and Override

Extract and Override

Read More →

Legacy Coderetreat: Part 7 – Dependency inversion

Dependency Inversion

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

As you found out from the previous post, it would be a good idea to refactor in a safe way. This session is about another concept that will prepare for the tough refactorings ahead.

Dependency inversion is one way of transforming a tightly coupled system into a system that has a core and many small external dependencies. These external dependencies can be called also plugins.

Sierpinski_Racket_example Read More →

Legacy Coderetreat: Part 6 – Basic rules of refactoring

Basic Rules of Refactoring

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

This technique is useful to minimize the mistakes one does while changing existing code. When refactoring existing code, one can introduce defects because of rushing through the changes.

During the next sections you will find some rules (guidelines) and some explanations about why these rules are useful.

 

Basic Rules of Refactoring

Basic Rules of Refactoring

Read More →