3 ms·
You successfully described why I think unit testing can be harmful to good code - forcing exposure of too many internal details. This has further implications,
by barrkel 9y ago
You successfully described why I think unit testing can be harmful to good code - forcing exposure of too many internal details.
This has further implications, like over-abstraction (all those dependencies need to be parameterized, all those classes need to be interfaces, everything must be indirected so it can be probed), namespace pollution (instead of a cohesive external API, you get a big bag of Lego pieces and have to pick and choose the right combination), brittle design (every unit boundary gets tested on both sides, tripling the cost of modification), etc.
- mikekchar 9y agoI think you are imagining something very different than what I am describing. Exposure of state simply allows you to decompose your structures -- which allows you to compose them again. This is exactly what you do in FP. Testing at branch points means that you write 2 tests. If you have n branch points it means 2n tests. If you test n branch points down, you need n^2 tests. You don't test functionality at every level -- because these are probes not tests. Your external API is irrelevant to its construction, which is the point of encapsulation. I can write internals that can be probed, or I can decide not to. But how you use it from the outside is not related. You can build as many layers of this as you want -- in the normal way. I'm trying to imagine what you are thinking of, but I'm having trouble so it's hard to rebut your points.
- barrkel 9y agoI'm thinking of the dominant paradigm in Java OO from about 2005 to 2015 or so. Choose almost any moderately popular jar you like from Maven and I could point out the pathologies. Strong smells when you have lots of interfaces with a single implementation, lots of construction indirected through factories (or factory factories), etc.