3 ms·
Yes, we should avoid mocks of mocks. But building small pieces of code that have little knowledge of their surroundings, and testing them independently, is no p
by hibikir 12y ago
Yes, we should avoid mocks of mocks. But building small pieces of code that have little knowledge of their surroundings, and testing them independently, is no panacea.
You can see this problem in any Java Enterprise shop that has code coverage as a religion: To make it possible to cover all that code (including all the boilerplate caused by the technologies selected), then we end up with a billion little classes that are managed by some kind of dependency injection system. Hundreds of thousands of lines of Spring XML configuration files, or their equivalent in annotations. Every piece is tested, but are all the pieces tested together, automatically? We quickly get into extremely large and expensive automation suites, or a whole lot of things that aren't really tested regularly, making all those unit tests a lot less valuable.
We can't wish complexity away: Make every unit too small, and the management of the units is now your new problem. You head in the same direction with the whole Microservices context.
A maintainable system is one built of components that are just simple and cohesive enough to be understandable by a human, but not any simpler. The right modularization is the hardest thing we do in software. The right size is hard to gauge, modules like that might be hard to name, and they are often hard to test. Sometimes one of those aspects must suffer for the others to do well.
- jrochkind1 12y agoThere is no panacea to writing good code. Whatever principle you come up with, you can still write bad code that outwardly seems to be motivated by that principle. I firmly believe that writing good code is a craft. I agree with you that 'the right size', and the right level of abstraction, is a hard thing. But common patterns and principles can help us figure out how to do it better, as long as we don't think simply following them slavishly and cargo-cult-y is going to do it for us. After all, we're programmers, looking for common patterns and principles is what we DO. O actually liked this article a lot, I think it provides more actual guidance and help in how to do things right than most articles in this genre, which are just rants without enough exmaples, or with examples that don't seem helpful to me. This one is helpful to me in improving my craft.
- smrtinsert 12y agoYou can't be serious. I've worked many "Java Enterprise shop" and not only are they not burdered by >100k lines of spring xml lines but they are very sensible with what they test. the smartest ones mock nothing, the ones with younger developers tend to mock more. Please HN, stop with the obviously inexperience and occasionally laughable (due to ridiculousness) "Java" claims.
- duaneb 12y ago> the smartest ones mock nothing Could you expand on this point? I can't imagine testing without some sort of mocks.
- Crito 12y agoHow do you define "Java Enterprise shop"? Because I've worked in some that produced quality code, but I have certainly worked in some that did not. 100k may be an exaggeration, but not much more than by an order of magnitude. Are you perhaps defining "enterprise" in such a way that necessarily excludes the possibility of poor code?
- zmmmmm 12y agoYou omitted the qualification "that has code coverage as a religion" ... obviously those that "are sensible about what they test" do not have "code coverage as a religion".