I see a repeated tendency in .NET to create base classes for API client classes, SQL repos, etc. The base class does all sorts of authentication, tokens, maybe retry logic, etc. They have several dependencies of their own, sometimes as many as 10.
That means the inherited classes have large constructors, and in order to test those classes we have to create mocks or pass something for those constructor arguments.
It makes the tests difficult to write and maintain, even though the tests have nothing to do with anything going on in that bloated base class.
Suggestion: Get rid of the inheritance. Take whatever is in that bloated base class, put it a non-abstract class, give it an interface, and inject it into API client classes, repositories, etc., instead of inheriting from it.
Now instead of calling something like
ExecuteRequest<Something>(whatever);
where it calls the base class, you can do
_requestHandler.ExecuteRequest<Something>(whatever);
ExecuteRequest<Something>(whatever);
where it calls the base class, you can do
_requestHandler.ExecuteRequest<Something>(whatever);
Now whatever behavior is in your class is easy to test by mocking that interface. Whatever goes on in that other class - getting auth tokens, retries, etc, is all hidden from the classes that depend on the interface.
You can change that other class - add dependencies, whatever - and you won't have to go back and edit every single class that depends on it along with tons of tests.
In other words, prefer composition over inheritance. Just because multiple classes need some common behavior doesn't mean they should obtain it by inheriting from it.
Class inheritance is like drugs. Use it when there's a valid reason, like polymorphism. The rest of the time just say no, even if all your friends are doing it.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
