Timeline for (Why) is it important that a unit test not test dependencies?
Current License: CC BY-SA 2.5
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 6, 2011 at 17:42 | comment | added | dsimcha | @Brook: More types doesn't increase complexity per se. More types is fine if those types make conceptual sense in the problem domain and make the code easier, not harder, to understand. The problem is artificially decoupling things that are conceptually coupled at the problem domain level (i.e. you only have one implementation, will probably never have more than one, etc.) and decoupling doesn't map well to problem domain concepts. In these cases it's silly, bureaucratic and verbose to create serious abstractions around this implementation. | |
| Apr 6, 2011 at 17:40 | comment | added | Brook | @dsimcha I would suggest furthering your understanding of SRP via examples. More typically it's understood to be "single reason to change" (in the problem domain), your example seems contrived to me. | |
| Apr 6, 2011 at 17:29 | comment | added | dsimcha | Also, my interpretation of the SRP is that a class should have a single responsibility at the conceptual/problem domain level. It doesn't matter if fulfilling that responsibility requires it to do a lot of different things when viewed at a lower level of abstraction. If taken to the extreme the SRP would be contrary to OO because most classes hold data and perform operations on it (two things when viewed at a sufficiently low level). | |
| Apr 6, 2011 at 17:23 | comment | added | Brook | @dsimcha I think that's where most TDD'ers would disagree. More types != More Complexity. What I mean is, the complexity is going to be there one way or the other, it's a matter of whether or not you are isolating responsibilities into their own types. Combining multiple concerns into a single class just to achieve fewer types does not lessen complexity, it only lessens # of types at the expense of testability. | |
| Apr 6, 2011 at 17:17 | comment | added | dsimcha | @Brook: I'm only against SOLID when it increase the complexity of your codebase (e.g. more types, more plumbing code or making objects harder/more verbose to construct) for the purpose of adding modularity that you have no real or reasonably anticipated use case for. In my experience abstraction lines that are drawn before you have clear use cases usually end up in the wrong places. When you need strong modularity, SOLID principles provide good hints about how to create it. The root of the question is whether testing isolation is a good enough use case for strong modularity. | |
| Apr 6, 2011 at 15:03 | comment | added | Brook | @dsimcha, I don't really understand what you mean "design your codebase to support mocking". Do you mean following SRP? You dislike interface segregation? It seems to me your issue isn't mocking but rather the SOLID principles in general. | |
| Apr 6, 2011 at 14:18 | comment | added | dsimcha | @asoundmove: Because then you have to design your codebase to support mocking. This is the whole point of the question. I know mocking has some benefits in the way you describe, but I'm skeptical that they're large enough to justify the artificial requirements they introduce into your design. | |
| Apr 6, 2011 at 11:52 | comment | added | Brook | @dsimcha, that sounds reasonable until you get into a non-trivial dependency graph. Say you've got a complex object that has 3+ layers deep with dependencies, it turns into an O(N^2) search for the problem, rather than O(1) | |
| Apr 6, 2011 at 5:19 | comment | added | asoundmove | @dsimcha, but now you are adding complexity back in the game to check the intermediate steps. Why not simplify and just do simple unit tests first? Then do your integration test. | |
| Apr 6, 2011 at 3:55 | comment | added | dsimcha | @Brook: How about seeing what the results are for all Widget's dependencies? If they all pass, it's a problem with Widget until proven otherwise. | |
| Apr 6, 2011 at 1:28 | history | answered | Brook | CC BY-SA 2.5 |