`PostList` mock calls `getPosts` as a side-effect to enable call-count assertions — tests verify internal wiring, not rendered output

[ooloth]

Why

The home and blog page tests verify that getPosts was called with a specific sort direction by having the PostList mock call getPosts internally as a side-effect — which tests a hidden call chain through an artificial seam rather than anything a user can observe, and produces assertions that pass or fail based on mock implementation details rather than real behavior.

Current state

app/(home)/page.test.tsx lines 21–26 define a PostList mock whose body calls void getPosts({ sortDirection: 'descending' }). This call is not used to render anything — it exists solely so that expect(getPosts).toHaveBeenCalledWith({ sortDirection: 'descending' }) at line 74 passes. The same pattern appears in app/blog/page.test.tsx lines 22–23.

The assertion passes because the mock fires the call, not because the real page or PostList component does anything observable with the sort direction. If PostList were rewritten to receive sort direction as a prop instead of calling getPosts internally, these tests would break — even if the rendered output were identical.

Ideal state

• The home page test asserts that the page renders a PostList component with an observable prop (e.g., via a data-testid or rendered attribute) rather than tracking an internal call count.
• The sort-direction contract (sortDirection: 'descending') is verified in blog-post-list.test.tsx where getPosts is the actual module under test.
• The PostList mock in app/(home)/page.test.tsx and app/blog/page.test.tsx does not call getPosts.

Out of scope

• Restructuring blog-post-list.test.tsx.
• Adding new snapshot tests or changing the component's public API.

Starting points

• app/(home)/page.test.tsx lines 21–26 — the PostList mock definition that calls getPosts as a side-effect
• app/blog/page.test.tsx lines 22–23 — same pattern
• ui/sections/blog-post-list.tsx — the real PostList component whose observable contract the home and blog page tests should verify

QA plan

1. Open app/(home)/page.test.tsx — expect the PostList mock body to contain no call to getPosts.
2. Open app/blog/page.test.tsx — expect the same.
3. Run pnpm test app/\(home\)/page.test.tsx app/blog/page.test.tsx — expect all tests to pass.
4. Confirm that the expect(getPosts).toHaveBeenCalledWith(...) assertions in these two files are either removed or replaced with assertions on the rendered output of the page.

Done when

Neither app/(home)/page.test.tsx nor app/blog/page.test.tsx contains a PostList mock that calls getPosts internally; the tests still verify the pages render a post list, and the sort-direction contract lives in blog-post-list.test.tsx.

[ooloth]

Additional evidence from a testing invariant scan: app/blog/page.test.tsx line 74 contains expect(getPosts).toHaveBeenCalledWith({ sortDirection: 'descending' }). This assertion is only possible because the PostList mock fires void getPosts(...) as a side-effect, and it directly asserts an implementation detail of the PostList child component rather than any observable output of the Blog page itself. The Blog page test verifying that PostList internally calls getPosts with a specific argument is the clearest concrete instance of the wiring-verification pattern described in this issue.

---

Generated by Claude Code

[ooloth]

Same pattern found in app/blog/page.test.tsx line 74: expect(getPosts).toHaveBeenCalledWith({ sortDirection: 'descending' }) asserts an implementation detail of the mocked PostList child — the Blog page's own contract is to render a heading and a PostList, not to control which sortDirection the child passes internally. The assertion would break on any PostList refactor that doesn't affect what the Blog page itself renders.

---

Generated by Claude Code