Breaking Dependencies to Allow Unit Testing - DevIntersection Spring 2016

Editor's Notes

• #3: https://twitter.com/hashtag/devintersection https://twitter.com/hashtag/breakdependencies Set low expectations
• #6: And specifically, we want fast, automated tests.
• #8: Developers like to build things, but often the way they connect parts of an application together (if there even are separate parts) is like using super glue. Good luck testing the interface of one building block.
• #9: If you haven’t seen it yet, you should. This guy wants to use krazy glue to keep anything from changing. Probably not how we want our software to be designed.
• #10: I want to answer these questions in this session. 1. 2. 3.
• #14: …unless the system is difficult to break apart
• #15: Avoid names that provide no information: CustomerTests Test1 Test2 Test3
• #16: PC (seams) vs. MAC (no seams) PC – Power supply goes bad. Solution: Order new power supply, open case, replace. MAC – Power supply goes bad. Solution: Buy a new Mac.
• #17: Because they’re small and fast, you should have a lot of unit tests. They should be the foundation of your testing approach. Integration tests can include tests of services that sit between different layers of your application. Defense in Depth These aren’t the only kinds of tests
• #18: Test at the lowest level you can, since that will be the least expensive test to write, run, and maintain.
• #19: ReSharper calls any test you run a unit test, regardless of what kind of test it actually is.
• #20: Also, they shouldn’t be terribly complex, slow, or involve more than one or two classes.
• #21: Dependencies are transitive. If A depends on B and B depends on C, then A depends on C. When I talk about breaking dependencies, I’m also talking about reducing coupling. Loosely coupled code can be tested more easily, since there are fewer connections to have to break apart, and they’re easier to swap out.
• #29: This can be difficult to test, especially if either of the two classes in question are difficult to set up in a particular state. To fix this, move the behavior where it belongs.
• #30: This can of course be refactored further to eliminate the conditional complexity, using inheritance or a compositional pattern.
• #31: “Well, the code is more like guidelines than rules.” Assume as little as possible about collaborators’ collaborators Law of Demeter is not just about having two many dots in an expression.
• #32: Imagine when you order a pizza, the delivery person uses code like this to get paid. Does this seem to model how things actually work? Should the delivery person have access to your wallet and its contents? What if you don’t have a wallet? This code is now tightly coupled not only to a Customer, but to a Wallet and its implementation.
• #33: What if instead the Customer could respond to requests for payment, like this? Note that wallet is no longer exposed outside of the Customer class.
• #34: At this point, the original code makes a bit more sense. Payment is requested, and how it is achieved is no longer a concern of the calling code. Payment can come from a money clip, purse, or from under a mattress and this code will still work. Testing this code could use a simplified fake customer and wouldn’t require implementation of both a fake customer and a fake wallet, making test code simpler. Reduce coupling – keep your classes from having to know too much about the details of their collaborators.
• #35: Drink water
• #38: Constructors should be extremely simple. They shouldn’t choose the object’s collaborators, or how the object is retrieved from persistence. These things violate the Single Responsibility Principle for the constructor’s class, and tightly couple the class to certain implementation details. Constructors that accept collaborators provide seams – hard-coding collaborators erases such seams. New is probably OK for initializing simple things like strings, datetimes, or collections to avoid nulls. Prefer the new C# 6 syntax for this with properties.
• #39: Note, it’s fine to create simple types and value objects – simply consider whether it’s making the object harder to test or not when deciding.
• #41: This code is difficult to test and tightly coupled to a dbContext, which in this case probably makes it impossible to test this code without a database.
• #42: Note that in this case the only thing the constructor does is assign parameters to fields, and no fields are instantiated as part of their declaration.
• #43: Likewise, avoid making static lookup calls or assignments within a constructor, especially ones that depend on infrastructure or the local environment. Avoid depending on configuration directly – remember it’s a dependency.
• #44: The solution is the same – avoid creating things in the constructor in favor of passing these things in. If you can’t pass in the thing itself, pass in a means of getting to it (like we’re doing with IConfig in this case), but keep it simple as possible.
• #47: Dependency injection again saves the day. The initialization logic is a separate responsibility from whatever the service does, and so belongs in another class.
• #53: Adds coupling in an invisible, hard to track manner. Makes testing difficult, especially parallel testing or testing in any order Causes Spooky Action at a Distance – your method causes some unexpected behavior in some other part of the system
• #55: Third party library with static call
• #56: Use a wrapper and inject