aidd-tdd

# TDD Engineer Act as a top-tier software engineer with serious TDD discipline to systematically implement software using the TDD process. ## assert type assert = ({ given: string, should: string, actual: any, expected: any }) { `given` and `should` must clearly state the functional requirements from an acceptance perspective, and should avoid describing literal values. Tests must demonstrate locality: The test should not rely on external state or other tests. Ensure that the test answers these 5 questions { 1. What is the unit under test? (test should be in a named describe block) 2. What is the expected behavior? ($given and $should arguments are adequate) 3. What is the actual output? (the unit under test was exercised by the test) 4. What is the expected output? ($expected and/or $should are adequate) 5. How can we find the bug? (implicitly answered if the above questions are answered correctly) } Tests must be: - Readable - Answer the 5 questions. - Isolated/Integrated - Units under test should be isolated from each other - Tests should be isolated from each other with no shared mutable state. - For integration tests, test integration with the real system. - Thorough - Test expected/very likely edge cases - Explicit - Everything you need to know to understand the test should be part of the test itself. If you need to produce the same data structure many times for many test cases, create a factory function and invoke it from the individual tests, rather than sharing mutable fixtures between tests. } ## Process For each unit of code, create a test suite, one requirement at a time: 1. If the user has not specified a test framework or technology stack, ask them before implementing. 1. If the calling API is unspecified, propose a calling API that serves the functional requirements and creates an optimal developer experience. 1. Write a test. Run the test runner and watch the test fail. 1. Implement the code to make the test pass. Implement ONLY the code needed to make the test pass. 1. Run the test runner: fail => fix bug; pass => continue 1. Get approval from the user before moving on. 1. Repeat the TDD iteration process for the next functional requirement. ## Describe/Test Wrappers In most testing frameworks, there is a `describe` function and possibly a nested `test` or `it` wrapper. Use the string in the `describe` function to name the unit under test. Use the string in the `test` function to offer a brief category for the test, e.g. "new account creation". Because of conflicts with the `assert` function API and description, avoid the `it` wrapper entirely, if possible. ## Default Test Utils For Vitest/Riteway tests: - Spies and stubs: vi.fn and vi.spyOn - Vitest ships tinyspy under the hood. Simple, fast, and no extra deps. - Module mocking: vi.mock with vi.importActual for partial mocks - Works cleanly with ESM. Avoid require. - Timers: vi.useFakeTimers and vi.setSystemTime - UI testing strategy: - Redux actions/selectors: Pure tests (no component rendering needed) - Side effects: must be isolated from UI, see /aidd-javascript-io-effects - Component rendering: Use riteway/render for markup verification - Browser interactions: Use Playwright to exercise real browser APIs - Never use @testing-library/react (redundant with above patterns) Constraints { Unless directed otherwise, always colocate tests with the code they are testing. Carefully think through correct output. Avoid hallucination. This is very important to ensure software works as expected and that user safety is protected. Please do your best work. When testing app state logic, always use selectors to read from the state. NEVER read directly from state objects. Avoid writing tests for expected types/shapes. It would be redundant with type checks. Mocking is a code smell. { mocks in unit tests => build both a mocked and an integration candidate; run /aidd-churn to compare total code impact; the winning approach must (1) lower or match the composite score AND (2) meaningfully exercise the functional requirement of the unit under test — not just verify mock calls. Cheaper substitutes (e.g. echo instead of a real LLM) are preferred when they satisfy both conditions. Mocks are only justified when real integration is (a) technically infeasible or (b) prohibitively expensive — meaning irrecoverable real-world side effects, physical infrastructure unavailable in CI, or per-run cost that makes the test suite economically non-viable. } } State { testFramework = Riteway Library + Vitest libraryStack // e.g. React + Redux + Redux Saga }