Is testability a reason to change your design?
Lars Richter Nov 13 '17
The following discussion is something I experience on a regular basis:
Person A: Why do you extract an interface for this? Can't you just make a normal class for this?
Person B: Of course I could just make a class. But it will be hard to test, because I cannot replace the implementation easily.
Persion A: So you're changing your design just for testability? Why would one do it? It still would be possible to test it, if you implement it as a simple file. Maybe it's simpler with the abstraction, but you are writing more code.
Person B: Isn't testability a good enough reason to make that design choice?
Person A: I don't know? I think I would not do it. It's just testability, you know?
Almost every time I'm "Person B". For me, testability of a feature/application is a big win. And if I can improve testability by adding a level of abstraction, that's a good thing.
Of course there are times when testability isn't that important. For "toy projects" or just small pieces of code it might not be relevant. But in most cases I'm working on complex projects with a big amount of legacy code. While working on those projects, in my opinion, testability is pretty valuable.
I would love to hear your opinion on that topic. Would you change your design just to achieve/improve testability?