0

I work on a software that has a lot of tests. However, instead of helping us develop faster, these tests actually bog us down, because even tiny changes in the application break many tests. Clearly, the tests are too tightly coupled to the application.

A big problem is that our application is not designed with testability in mind. We have big classes with lots of dependencies to other classes, we use singletons and we have lots of mutable state, we don't use DI, we don't use PImpl. Our modules are also coupled fairly tightly to each other.

I wonder whether there are any general techniques we could use to reduce this coupling. Preferably without rewriting large parts of our application to make it easier to test.

adrianN
  • 101

1 Answers1

0

Tests are supposed to be tightly coupled to the application.

The fact that many tests fail when changes are made is a good thing. Far better than throwing it over the wall and have your customer/user find the errors.

However, code base aside, this rather assumes that you have good tests in place.

Some questions to ask when tests fail:

Is the test valid?

Does the logic under test still apply? If not, remove it.

Are the same tests failing?

If the same sorts of tests are failing, this highlights where your code is particularly brittle. A flippant remark you might think, but check through your source control and you may find the same tests have been repaired again and again and again.

Is the test in a reasonable area?

How close to the action is the failing test? If tests are failing in areas where you wouldn't expect, again, you have an issue you need to address.

Do you have to massage a test thru?

Do you have test that require a number of changes just to get them thru? If so, re-engineer the test so it is testing a smaller area of functionality.

Do the same fixes have to be applied to different tests?

If you're applying the same fix to multiple tests, this indicates a code smell. Either the test is too large or there is common code can be refactored out.

Do the tests following FIRST principles?

Ensure the tests are following the basic rules.

As for how you can improve the code without making wholesale changes, that is difficult to advise on without knowing the code base. As a starting point, I'd be inclined to target your changes on areas where tests are consistently failing.

Robbie Dee
  • 9,815
  • 2
  • 24
  • 53
  • I agree that some tests are supposed to fail when you change the code. But we usually have lots of tests failing that are not supposed to check the changed part. They just have to use it to get to the parts that they need. That can't be good. Say you notice a redundant call to another module in the constructor of the important classes and remove it. All tests need to be changed because that class is used everywhere in the module and the external call is now expected by our mocking framework. One line changed in the application. Hours to adapt the tests. – adrianN Oct 08 '15 at 09:11
  • Not sure what language you're using but presumably you're talking about reference type properties which aren't set in the constructor or explicitly otherwise? – Robbie Dee Oct 08 '15 at 09:41