Legacy Code and Smell by Tests
Working with unit tests can help in many ways to improve the code-base.
One of the aspects, which I mostly like, is that tests can point us to code smell in the production code.
For example, if a test needs large setup or assert many outputs, it can point that the unit under test doesn’t follow good design, such as SRP and other OOD.
But sometimes the tests themselves are poorly structured or designed.
In this post I will give two examples for such cases, and show how I solved it.
Test Types
(or layers)
There are several types, or layers, of tests.
- Unit Tests
Unit test should be simple to describe and to understand.
Those tests should run fast. They should test one thing. One unit (method?) of work.
- Integration Tests
Integration tests are more vague in definition.
What kind of modules do they check?
Integration of several modules together? Dependency-Injector wiring?
Test using real DB?
- Behavioral Tests
Those tests will verify the features.
They may be the interface between the PM / PO to the dev team.
- End2End / Acceptance / Staging / Functional
High level tests. May run on production or production-like environment.
Complexity of Tests
Basically, the “higher level” the test, the more complex it is.
Also, the ratio between possible number of tests and production code increase dramatically per test level.
Unit tests will grow linearly as the code grows.
But starting with integration tests and higher level ones, the options start to grow in exponential rate.
Simple calculation:
If two classes interact with each other, and each has 2 methods, how many option should we check if we want to cover all options? And imagine that those methods have some control flow like if.
Sporadically Failing Tests
There are many reasons for a test to be “problematic”.
One of the worst is a test that sometimes fails and usually passes.
The team ignores the CI’s mails. It creates noise in the system.
You can never be sure if there’s a bug or something was broken or it’s a false alarm.
Eventually we’ll disable the CI because “it doesn’t work and it’s not worth the time”.
Integration Test and False Alarm
Any type of test is subject for false alarms if we don’t follow basic rules.
The higher test level, there’s more chance for false alarms.
In integration tests, there’s higher chance for false alarms due to external resources issues:
No internet connection, no DB connection, random miss and many more.
Our Test Environment
Our system is “quasi legacy”.
It’s not exactly legacy because it has tests. Those test even have good coverage.
It is legacy because of the way it is (un)structured and the way the tests are built.
It used to be covered only by integration tests.
In the past few months we started implementing unit tests. Especially on new code and new features.
All of our integration tests inherit from BaseTest, which inherits Spring’s AbstractJUnit4SpringContextTests.
The test’s context wires everything. About 95% of the production code.
It takes time, but even worse, it connects to real external resources, such as MongoDB and services that connect to the internet.
In order to improve tests speed, a few weeks ago I change MongoDB to embedded. It improved the running time of tests by order of magnitude.
This type of setup makes testing much harder.
It’s very difficult to mock services. The environment is not isolated from the internet and DB and much more.
After this long introduction, I want to describe two problematic tests and the way I fixed them.
Their common failing attribute was that they sometimes failed and usually passed.
However, each failed for different reason.
Case Study 1 – Creating Internet Connection in the Constructor
The first example shows a test, which sometimes failed because of connection issues.
The tricky part was, that a service was created in the constructor.
That service got HttpClient, which was also created in the constructor.
Another issue, was, that I couldn’t modify the test to use mocks instead of Spring wiring.
Here’s the original constructor (modified for the example):
private HttpClient httpClient;
private MyServiceOne myServiceOne;
private MyServiceTwo myServiceTwo;
public ClassUnderTest(PoolingClientConnectionManager httpConnenctionManager, int connectionTimeout, int soTimeout) {
HttpParams httpParams = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(httpParams, connectionTimeout);
HttpConnectionParams.setSoTimeout(httpParams, soTimeout);
HttpConnectionParams.setTcpNoDelay(httpParams, true);
httpClient = new DefaultHttpClient(httpConnenctionManager, httpParams);
myServiceOne = new MyServiceOne(httpClient);
myServiceTwo = new MyServiceTwo();
}
The tested method used myServiceOne.
And the test sometimes failed because of connection problems in that service.
Another problem was that it wasn’t always deterministic (the result from the web) and therefore failed.
The way the code is written does not enable us to mock the services.
In the test code, the class under test was injected using @Autowired annotation.
The Solution – Extract and Override Call
Idea was taken from Working Effectively with Legacy Code.
- Identifying what I need to fix.
In order to make the test deterministic and without real connection to the internet, I need access for the services creation.
- I will introduce a protected methods that create those services.
Instead of creating the services in the constructor, I will call those methods.
- In the test environment, I will create a class that extends the class under test.
This class will override those methods and will return fake (mocked) services.
Solution’s Code
public ClassUnderTest(PoolingClientConnectionManager httpConnenctionManager, int connectionTimeout, int soTimeout) {
HttpParams httpParams = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(httpParams, connectionTimeout);
HttpConnectionParams.setSoTimeout(httpParams, soTimeout);
HttpConnectionParams.setTcpNoDelay(httpParams, true);
this.httpClient = createHttpClient(httpConnenctionManager, httpParams);
this.myserviceOne = createMyServiceOne(httpClient);
this.myserviceTwo = createMyServiceTwo();
}
protected HttpClient createHttpClient(PoolingClientConnectionManager httpConnenctionManager, HttpParams httpParams) {
return new DefaultHttpClient(httpConnenctionManager, httpParams);
}
protected MyServiceOne createMyServiceOne(HttpClient httpClient) {
return new MyServiceOne(httpClient);
}
protected MyServiceTwo createMyServiceTwo() {
return new MyServiceTwo();
}
private MyServiceOne mockMyServiceOne = mock(MyServiceOne.class);
private MyServiceTwo mockMyServiceTwo = mock(MyServiceTwo.class);
private HttpClient mockHttpClient = mock(HttpClient.class);
private class ClassUnderTestForTesting extends ClassUnderTest {
private ClassUnderTestForTesting(int connectionTimeout, int soTimeout) {
super(null, connectionTimeout, soTimeout);
}
@Override
protected HttpClient createHttpClient(PoolingClientConnectionManager httpConnenctionManager, HttpParams httpParams) {
return mockHttpClient;
}
@Override
protected MyServiceOne createMyServiceOne(HttpClient httpClient) {
return mockMyServiceOne;
}
@Override
protected MyServiceTwo createMyServiceTwo() {
return mockMyServiceTwo;
}
}
Now instead of wiring the class under test, I created it in the @Before method.
It accepts other services (not described here). I got those services using @Autowire.
Another note: before creating the special class-for-test, I ran all integration tests of this class in order to verify that the refactoring didn’t break anything.
I also restarted the server locally and verified everything works.
It’s important to do those verification when working with legacy code.
Case Study 2 – Statistical Tests for Random Input
The second example describes a test that failed due to random results and statistical assertion.
The code did a randomize selection between objects with similar attributes (I am simplifying here the scenario).
The Random object was created in the class’s constructor.
Simplified Example:
private Random random;
public ClassUnderTest() {
random = new Random();
// more stuff
}
//The method is package protected so we can test it
MyPojo select(List<MyPojo> pojos) {
// do something
int randomSelection = random.nextInt(pojos.size());
// do something
return pojos.get(randomSelection);
}
The original test did a statistical analysis.
I’ll just explain it, as it is too complicated and verbose to write it.
It had a loop of 10K iterations. Each iteration called the method under test.
It had a Map that counted the number of occurrences (returned result) per MyPojo.
Then it checked whether each MyPojo was selected at (10K / Number-Of-MyPojo) with some kind of deviation, 0.1.
Example:
Say we have 4 MyPojo instances in the list.
Then the assertion verified that each instance was selected between 2400 and 2600 times (10K / 4) with deviation of 10%.
You can expect of course that sometimes the test failed. Increasing the deviation will only reduce the number of false fail tests.
The Solution – Overload a Method
- Overload the method under test.
In the overloaded method, add a parameter, which is the same as the global field.
- Move the code from the original method to the new one.
Make sure you use the parameter of the method and not the class’s field. Different names can help here.
- Tests the newly created method with mock.
Solution Code
private Random random;
// Nothing changed in the constructor
public ClassUnderTest() {
random = new Random();
// more stuff
}
// Overloaded method
private select(List<MyPojo> pojos) {
return select(pojos, this.random);
}
//The method is package protected so we can test it
MyPojo select(List<MyPojo> pojos, Random inRandom) {
// do something
int randomSelection = inRandom.nextInt(pojos.size());
// do something
return pojos.get(randomSelection);
}
Conclusion
Working with legacy code can be challenging and fun.
Working with legacy test code can be fun as well.
It feels really good to stop receiving annoying mails of failing tests.
It also increase the trust of the team on the CI process.
Learning and Improving as a Craftsman Developer 