Sunday, April 8, 2018

Unit Tests and SOLID Code

One of the realizations that we had at our office over the past few years is that SOLID code is easier to unit test. If code is easier to unit test, we will have a higher level of unit test coverage. So a high unit test coverage number is decent indicator that our code follows the SOLID principles. Not foolproof, but decent.


Tests taking too long to write because you need to mock too many dependencies? You're code is probably doing too much and you're not following the Single Responsibility principle.

Tests taking too long to write because you have to factor in too many cases from base classes? You're code is doing too much because you're not following the Open Closed principle.

Tests taking too long to write because you need to test too many exceptional states? You might be adding too many exceptions to sub-classes by possibly ignoring the Liskov Substitution principle.

Too many tests needed to cover a class effectively? Follow the Interface Segregation principle and have more classes that do fewer things.

Can't inject mocks into your tests easily? You really messed up that Dependency Inversion part of SOLID.


Not sure how universal this is, but it seems to hold for quite a few architectural styles. As always, this is my 2¢. You're mileage may vary.

No comments:

Post a Comment