tdd-best-practices

Topics in the source

• TDD Best Practices
• Working Style
• The Red-Green-Refactor Cycle
• The 3 Laws (Uncle Bob)
• Design Workflow
• Choosing Test Granularity
• Heuristics
• When to mock

Use this skill when the main question is how to drive implementation from tests, how to structure a test suite, or how to recover discipline in a codebase where tests were written after the fact. 1. Write one failing test, then make it pass with the minimum code needed. 2. Refactor only when all tests are green. 3. Test behaviors, not implementations — the public API, not private methods. 4. Keep tests as simple as the production code they verify. 5. A test suite that is hard to change is as expensive as production code that is hard to change. The discipline is in the order. Never refactor on Red. On Green, add only the behavior demanded by the current failing test. 1. You may not write production code unless you have a failing unit test. 2. You may not write more of a unit test than is sufficient to fail. An intentionally missing public API/type can be a valid first Red; unrelated compilation or setup failures are not. 3. You may not write more production code than is sufficient to make the currently failing test pass. 1. Describe the behavior — what should the system do? Write the test name first. 2. Write a failing test — make it fail for the right reason (assertion, not setup e

This is an excerpt. Refer to the complete source and its current requirements.