Published

Following this approach consistently produces a set of interfaces that define the relationship between our application and the rest of the world in our application’s terms and discourages low-level technical concepts from leaking into the application domain model. benefits: define the relationship of our application the rest of the world in our application’s terms prevent low-level technical concepts in domain model (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

(src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

Interface name vs Implementing class name Interface name what it does point of view = “user” object Implementing class name how it does it point of view = implementation (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce) Method name should describe what it does, not how Method name should be what it does point of view = “user” object instead of how it does it point of view = implementation src: ?...

often used interchangeably but actually refer to two separate, and largely orthogonal, qualities Encapsulation behavior of an object can only be affected through its API reduces dependencies Information hiding Conceals how an object implements its functionality work at higher level abstraction Aliasing break encapsulation by sharing references to mutable objects increases dependencies accidental aliasing can couple unrelated parts of a system (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

Model: External vs Internal Quality internal quality is how well it meets the needs of its developers and administrators (is it easy to understand, easy to change, etc.) External quality is how well the system meets the needs of its customers and users (is it functional, reliable, available, responsive, etc.) (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

Caveat: test terminology is not very standardized End to end tests Focused on business requirements. Exercise the complete flow, including external systems. Usually these tests are slow to execute. Acceptance tests Focused on business requirements. Exercise all parts of the flow in our system. Compromise on feedback and speed of execution. Faster than end to end tests, but not as thorough. Integration tests Focused on technical implementation. Exercise parts of our system that connect with external systems....

Pattern: Include the deployment step in the testing process We want our test to - start from scratch, - build a deployable system, - deploy it into a production-like environment, and then - run the tests through the deployed system benefits deployment is error prone => now covered by tests development team bumps into the rest of the organization If it’s going to take six weeks and four signatures to set up a database, we want to know now, not two weeks before delivery....

Tell, don’t ask Model: Law of Demeter Objects make their decisions based only on the information they hold internally or that which came with the triggering message; they avoid navigating to other objects to make things happen. this style produces more flexible code because it’s easy to swap objects that play the same role. why? information hiding flexible code forces us to name the interactions between objects But Sometimes Ask...

Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan. -- Eliel Saarinen (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

The big idea is “messaging” [...] The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. -- Alan Kay [Kay98] (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce) (origin: [Kay98])