7 ms·

Test Isolation Is About Avoiding Mocks

78 points by gary_bernhardt 12y ago

henrik_w 12y ago
Reducing the knowledge of internal structures is what the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter http://en.wikipedia.org/wiki/Law_of_Demeter) is about. Usually good practice.
- steveklabnik 12y ago
  DHH has repeatedly asserted that he thinks the Law of Demeter is bad, so that wouldn't work as a justification, at least in response to him.
  - protomyth 12y ago
    What is his reasoning on it being bad?
    - pacala 12y ago
      There is (immutable) data and there are modules. Encapsulation / Demeter make it hard to work with data. OTOH, Encapsulation / Demeter are good for modules.
    - steveklabnik 12y ago
      I don't want to misrepresent him, so I'll just point you to these links: - http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui#comment_72496 http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-... - http://rubyrogues.com/056-rr-david-heinemeier-hansson/ http://rubyrogues.com/056-rr-david-heinemeier-hansson/ - https://www.youtube.com/watch?v=9LfmrkyP81M https://www.youtube.com/watch?v=9LfmrkyP81M
    - fxn 12y ago
      He does not say it is bad per se. What he criticizes is using any of these "laws" and "principles" as if they were truths, as if the argument was based on an axiom or had the strength of science. They are "inferred" from experience statistically speaking, but in each individual case you need to gauge and check yourself whether those three dots make or not make sense. It is your judgement in particular code that matters, not the a priori invocation of any "law" or "principle".
      - gary_bernhardt 12y ago
        DHH quote: "I think the Law of Demeter is shit and never follow it." (from http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui#comment_72496 http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...)
        fxn 12y ago
        Because he judges a series of dots by themselves, not because any law mandantes anything. He gives a shit about these grandiose names, show me the code and let's discus on that.
        gary_bernhardt 12y ago
        I was responding to your claim that "He does not say it is bad per se." Calling it "shit" seems like "[saying] it is bad".
        fxn 12y ago
        If you present a code with ten dots, he will probably say it is bad code. But he won't invoke law of demeter. That's the point I think. Is like invoking SRP. Fuck that. When you are experienced, you develop a sense on delineating responsabilities in a way that fits your application. I am not David of course, but I have participated in some discussions with him, and we think very much alike on these topics, I think what I say above is right. Going to switch to myself now: When people invoke SRP a priori they sometimes end up with one class == one method in a theoretical a priori way. I don't think that works. It goes in the reverse direction. SRP is inferred, it emerges, it is not applied as if it was a logical proposition.
  - jrochkind1 12y ago
    Ah, but I think OP is a pretty good explanation of _why_ the Law of Demeter is actually good, although it doesn't use that phrase. I've been somewhat suspicious of the law of demeter (not firmly on one side or the other), but this article actually helped me see the value of it. It's not that "you can't do this because it violates the law of demeter." That's a ridiculous cargo cult way to use software design principles (which, yeah, is quite common). Rather, it's, the law of demeter is good because it prevents THIS stuff, which you don't want. Like, okay, DHH thinks the law of demeter is useless, but he hates things that... the law of demeter is meant to and helps prevent.
    - steveklabnik 12y ago
      I agree with you that the post is a great explanation of why Demeter is good. All I mean to say is "this is just Demeter" is not a refutation of "I think the Law of Demeter is shit and never follow it." (See my links in your sibling, that's a quote.)
  - jimbokun 12y ago
    Citing dhh's opinion is not a justification for ignoring the law of Demeter, either, so what's your point?
adamors 12y ago
Well, one thing I learned from all this recent TDD related discussion is that almost nobody is aware of this book [1] and the entire school of TDD it spawned. [1] http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 http://www.amazon.com/Growing-Object-Oriented-Software-Guide...
- henrik_w 12y ago
  An alternative way of using unit tests is this: Selective Unit Testing – Costs and Benefits http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/ http://blog.stevensanderson.com/2009/11/04/selective-unit-te... The main idea there is to unit test logic, but not unit test "coordination-code".
  - gary_bernhardt 12y ago
    That sounds vaguely similar to "Functional Core, Imperative Shell". I merge state management and coordination (together, the shell) so that the logic (the core) can be composed of pure functions without coordination overhead. So far I've done very little testing of the imperative shell.
- platz 12y ago
  This is a great book. Although I must admit it kind of "washed over me" a bit too much. Perhaps it was just the java.. I think I need to re-read it to be able to synthesize the ideas in it, and connect the high-level ideas to the examples later in the book enough to be able to get the same results in my own work.
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 ago
  There 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 ago
  You 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.
vinceguidry 12y ago
I'm just happy Gary's gracing us with his wisdom semi-regularly again.

Reducing the knowledge of internal structures is what the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter http://en.wikipedia.org/wiki/Law_of_Demeter) is about. Usually good practice.

steveklabnik 12y ago
DHH has repeatedly asserted that he thinks the Law of Demeter is bad, so that wouldn't work as a justification, at least in response to him.
- protomyth 12y ago
  What is his reasoning on it being bad?
  - pacala 12y ago
    There is (immutable) data and there are modules. Encapsulation / Demeter make it hard to work with data. OTOH, Encapsulation / Demeter are good for modules.
  - steveklabnik 12y ago
    I don't want to misrepresent him, so I'll just point you to these links: - http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui#comment_72496 http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-... - http://rubyrogues.com/056-rr-david-heinemeier-hansson/ http://rubyrogues.com/056-rr-david-heinemeier-hansson/ - https://www.youtube.com/watch?v=9LfmrkyP81M https://www.youtube.com/watch?v=9LfmrkyP81M
  - fxn 12y ago
    He does not say it is bad per se. What he criticizes is using any of these "laws" and "principles" as if they were truths, as if the argument was based on an axiom or had the strength of science. They are "inferred" from experience statistically speaking, but in each individual case you need to gauge and check yourself whether those three dots make or not make sense. It is your judgement in particular code that matters, not the a priori invocation of any "law" or "principle".
    - gary_bernhardt 12y ago
      DHH quote: "I think the Law of Demeter is shit and never follow it." (from http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui#comment_72496 http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...)
      - fxn 12y ago
        Because he judges a series of dots by themselves, not because any law mandantes anything. He gives a shit about these grandiose names, show me the code and let's discus on that.
        gary_bernhardt 12y ago
        I was responding to your claim that "He does not say it is bad per se." Calling it "shit" seems like "[saying] it is bad".
        fxn 12y ago
        If you present a code with ten dots, he will probably say it is bad code. But he won't invoke law of demeter. That's the point I think. Is like invoking SRP. Fuck that. When you are experienced, you develop a sense on delineating responsabilities in a way that fits your application. I am not David of course, but I have participated in some discussions with him, and we think very much alike on these topics, I think what I say above is right. Going to switch to myself now: When people invoke SRP a priori they sometimes end up with one class == one method in a theoretical a priori way. I don't think that works. It goes in the reverse direction. SRP is inferred, it emerges, it is not applied as if it was a logical proposition.
- jrochkind1 12y ago
  Ah, but I think OP is a pretty good explanation of _why_ the Law of Demeter is actually good, although it doesn't use that phrase. I've been somewhat suspicious of the law of demeter (not firmly on one side or the other), but this article actually helped me see the value of it. It's not that "you can't do this because it violates the law of demeter." That's a ridiculous cargo cult way to use software design principles (which, yeah, is quite common). Rather, it's, the law of demeter is good because it prevents THIS stuff, which you don't want. Like, okay, DHH thinks the law of demeter is useless, but he hates things that... the law of demeter is meant to and helps prevent.
  - steveklabnik 12y ago
    I agree with you that the post is a great explanation of why Demeter is good. All I mean to say is "this is just Demeter" is not a refutation of "I think the Law of Demeter is shit and never follow it." (See my links in your sibling, that's a quote.)
- jimbokun 12y ago
  Citing dhh's opinion is not a justification for ignoring the law of Demeter, either, so what's your point?

adamors 12y ago

Well, one thing I learned from all this recent TDD related discussion is that almost nobody is aware of this book [1] and the entire school of TDD it spawned. [1] http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

henrik_w 12y ago
An alternative way of using unit tests is this: Selective Unit Testing – Costs and Benefits http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/ http://blog.stevensanderson.com/2009/11/04/selective-unit-te... The main idea there is to unit test logic, but not unit test "coordination-code".
- gary_bernhardt 12y ago
  That sounds vaguely similar to "Functional Core, Imperative Shell". I merge state management and coordination (together, the shell) so that the logic (the core) can be composed of pure functions without coordination overhead. So far I've done very little testing of the imperative shell.
platz 12y ago
This is a great book. Although I must admit it kind of "washed over me" a bit too much. Perhaps it was just the java.. I think I need to re-read it to be able to synthesize the ideas in it, and connect the high-level ideas to the examples later in the book enough to be able to get the same results in my own work.

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 ago
There 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 ago
You 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.

vinceguidry 12y ago

I'm just happy Gary's gracing us with his wisdom semi-regularly again.