Part I. Introduction Chapter 1. What Is the Point of Test-Driven Development? Acceptance: Does the whole system work? Integration: Does our code work against code we can’t change? Unit: Do our objects do the right thing, are they convenient to work with? preference: acceptance test = end-to-end Our preferred implementation of the “role” of acceptance testing is to write end-to-end tests which, as we just noted, should be as end-to-end as possible [[model-external-vs-internal-quality.md|Model_ External vs Internal Quality]] Chapter 2. Test-Driven Development with Objects Object-oriented design focuses more on the communication between objects than on the objects themselves. [[quote-how-modules-communicate-is-more-important-than-their-internals.md|Quote_ how modules communicate is more important than their internals]] Model: Values vs Objects values that model unchanging quantities or measurements objects that have an identity, might change state over time, and model computational processes [[technique-crc-cards-candidates-responsibilities-collaborators.md|Technique_ CRC cards (Candidates, Responsibilities, Collaborators)]] [[pattern-tell-dont-ask-but-sometimes-ask.md|Pattern_ Tell, don’t ask (but sometimes ask)]] Unit-Testing the Collaborating Objects mock the neighbours, check the communication Chapter 3. An Introduction to the Tools JUnit 4 Hamcrest Matchers jMock2 Part II. The Process of Test-Driven Development Chapter 4. Kick-Starting the Test-Driven Cycle Deploying and testing right from the start of a project forces the team to understand how their system fits into the world. [[technique-walking-skeleton-for-incremental-development.md|Technique_ Walking Skeleton for incremental development]] [[pattern-include-the-deployment-step-in-the-testing-process.md|Pattern_ Include the deployment step in the testing process]] Chapter 5. Maintaining the Test-Driven Cycle [[technique-outside-in-tdd-london-style-tdd-mockist-tdd-atdd-acceptance.md|Technique_ Outside-in TDD = London style TDD = mockist TDD = ATDD (Acceptance)]] Watch the Test Fail write a failing test check the failure make the error message clear ![[./resources/book-growing-object-oriented-software-guided-by-te.resources/unknown_filename.png]] why? check assumption express intention includes failure messages [[heuristic-test-behaviour-instead-of-x.md|Heuristic_ Test Behaviour, Not Methods]] Listen to the Tests When we find a feature that’s difficult to test, we don’t just ask ourselves how to test it, but also why is it difficult to test. when code is difficult to test, the most likely cause is that our design needs improving. why? early warning of potential maintenance problems fix a problem while it’s still fresh Chapter 6. Object-Oriented Style [[quote-design-considering-its-context.md|Quote_ design considering it’s context]] We value code that is easy to maintain over code that is easy to write Heuristic: Separation of concerns gather together code that will change for the same reason Heuristic Higher levels of abstraction These two combined will create something like [[pattern-ports-and-adapters-architecture.md|Pattern_ Ports and Adapters architecture]] [[model-encapsulation-vs-information-hiding.md|Model_ Encapsulation vs Information hiding]] [[model-object-peer-relationship-stereotypes.md|Model_ Object Peer Relationship Stereotypes]] [[heuristic-composite-simpler-than-the-sum-of-its-parts.md|Heuristic_ Composite Simpler Than the Sum of Its Parts]] [[heuristic-context-independence.md|Heuristic_ Context Independence]] Chapter 7. Achieving Object-Oriented Design Design Prinicples (1) find the right boundaries (chapter 6) plays well with its neighbors (2) coherent unit flexibility to reconfigure and adapt as requirements change TDD causes information hiding separation of concerns context independence [[model-interface-vs-protocol.md|Model_ interface vs protocol]] Benefits of Technique: TDD with mock objects encourages information hiding make communication protocols visible ([[model-interface-vs-protocol.md|Model_ interface vs protocol]]) [[model-3-techniques-for-introducing-types.md|Model_ 3 techniques for introducing types]] [[pattern-split-what-and-how-when-naming.md|Pattern_ Split what and how when naming]] interface = what implementation = how Refactor Interfaces Too merge when: represent a single concept split when: too many responsibilities [[model-web-of-objects.md|Model_ web of objects]] [[model-2-layers-in-higher-level-programming.md|Model_ 2 layers in Higher-Level Programming]] Chapter 8. Building on Third-Party Code Only Mock Types That You Own Don’t Mock Types You Can’t Change [[pattern-adapter-layer-for-3rd-party-integration.md|Pattern_ Adapter Layer for 3rd party integration]] exceptions to ’never’ mocking 3rd party stuff trigger hard-to-trigger situations trigger error conditions [[pattern-integration-test-should-mock-application-objects.md|Pattern_ Integration test should mock application objects]]