tdd-green-phase

To write the minimal code for a failing unit test in TDD, focus solely on satisfying the current test's assertions to prevent over-engineering. You decide between using an 'obvious implementation' or 'faking it til you make it' based on logic clarity.

In test-driven development, 'obvious implementation' means writing the direct, correct logic immediately, while 'faking it' means returning hardcoded values to pass the test before generalizing. The choice depends on your confidence in the solution's clarity and coverage.

To avoid over-implementation when writing code test-first, restrict your coding strictly to the assertions in the current failing test. Do not add extra parameters, error handling, or features until a subsequent failing test explicitly demands them.

Yes, TDD green phase guidance supports async patterns for FastAPI and SQLAlchemy. It provides expert strategies for implementing minimal async code to satisfy failing tests without over-engineering the asynchronous database or API logic.

Use triangulation to make a failing test pass when the general algorithm or logic is not immediately obvious. By writing a second test with different inputs, you force the implementation to generalize beyond the hardcoded values used in the initial fake implementation.

When implementing code to satisfy a unit test, classicist tradeoffs involve testing real object interactions and state, while mockist tradeoffs focus on verifying specific method calls and collaboration patterns, impacting how you write the minimal passing logic.