create "testable" code

problem: class does too much

why that’s bad:

• Hard to debug
• Hard to test
• Non-extensible system
• Difficult for new resources and hard to hand off

problem: class does too much

why that’s bad:

• Not subject to altering behavior via standard mechanisms: decorator, strategy, subclassing: you end up adding another conditional test
• Hard to give a name to describe what the class does. Whenever struggling with a name, the code is telling you that the responsibilities are muddled. When objects have a clear name, it is easy to keep them focused and shear off any excess baggage.

problem: class does too much

how to tell

solution: class does too much

Class-responsibility-collaboration (CRC) card

"If it fits, it ships!"

solution: class does too much

Reduce Cyclomatic Complexity: Number of paths through a code base

• Higher complexity is harder to test
• High complexity is tied to low cohesion (degree to which the elements of a module belong together.)

problem: constructor does real work

solution: constructor does real work

Dependency Injection

moe money moe problems?

developer workflow

modifying workflow to encourage testing

• start thinking about features in the context of "how do we test that??"
• think outside the container: You don’t need to start the Web container to run code (even database code)!

developer workflow

• business logic tests: Fast, Repeatable (automatable??)
• database CRUD tests: Slow, Unrepeatable (non-automatable??)