test/animation/legacyAnimationLengthChange.spec.tsx (3)

180-183: Add the 3 -> 2 shrink path to this suite too.

Everything here exercises 2 -> 3, so the removal branch of the legacy matching logic is still unprotected. Length decreases often take a different path than appended-item growth, and that seems in scope for a “length change” regression suite.

Also applies to: 185-429

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/animation/legacyAnimationLengthChange.spec.tsx` around lines 180 - 183,
Add test cases that exercise the shrink path (3 -> 2) in the same suite so the
removal branch of the legacy matching logic is covered: create equivalents to
the existing growth tests but initialize with largeData/largePolarData and
transition to smallData/smallPolarData (the variables smallData, largeData,
smallPolarData, largePolarData are present) and run the same assertions and
animation checks used for the 2 -> 3 path; ensure these new tests mirror the
setup/teardown and expectation logic (e.g., legacy matching/cleanup assertions)
used elsewhere in this spec so the removal branch is executed.

---

272-279: Assert the captured item count before reading index 2.

These tests assume the appended shape exists and immediately dereference [2]. If the rerender stops producing the third item entirely, the failure becomes a generic undefined access instead of clearly showing that the appended element was never rendered.

Suggested assertion pattern

     await renderResult.animationManager.setAnimationProgress(0.5);
     const midBars = getCapturedBars(renderResult.container);
     await renderResult.animationManager.completeAnimation();
     const finalBars = getCapturedBars(renderResult.container);

+    expect(midBars).toHaveLength(3);
+    expect(finalBars).toHaveLength(3);
     const midBar = midBars[2];
     const finalBar = finalBars[2];

Also applies to: 314-315, 349-350, 386-387, 422-423

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/animation/legacyAnimationLengthChange.spec.tsx` around lines 272 - 279,
Add explicit assertions that the captured arrays contain at least three items
before dereferencing index 2: after calling
renderResult.animationManager.setAnimationProgress(...) and after
completeAnimation() assert the lengths of the arrays returned by
getCapturedBars(renderResult.container) (and the other captured lists at the
other locations) are >= 3 so that reading midBars[2] and finalBars[2] fails with
a clear test assertion when the appended element is missing; update each
occurrence (the pairs around setAnimationProgress/completeAnimation shown and
the other locations mentioned) to perform this pre-check using the test
framework's assert/expect API.

---

185-429: Track selector churn across these rerenders as well.

The geometry checks are good, but this suite never asserts how many selector recalculations happen during the length-change rerender. That leaves a performance regression path open even if the sampled animation state stays correct. As per coding guidelines, "Verify the number of selector calls using the spy object from createSelectorTestCase to spot unnecessary re-renders and improve performance".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/animation/legacyAnimationLengthChange.spec.tsx` around lines 185 - 429,
Add assertions that verify selector call counts using the spy from
createSelectorTestCase around the length-change rerenders: wrap the initial
render and the rerender (or the primeAndRerender flow) with
createSelectorTestCase to obtain selectorSpy, then assert selectorSpy.callCount
(or individual selectorSpy.getCallCount) before and after the rerender in each
relevant spec (those using rechartsTestRender and primeAndRerender, e.g., the
Area, Line, Radar, Bar, Funnel, Scatter, Pie, and RadialBar tests), ensuring you
check that only the expected minimal number of selector recalculations occurred
during animationManager.setAnimationProgress and completeAnimation. Use the
existing test helpers (createSelectorTestCase, selectorSpy, primeAndRerender,
rechartsTestRender, animationManager) to locate the insertion points and keep
the assertions tight to avoid false positives.

test/animation/legacyAnimationLengthChange.spec.tsx (1)

293-355: Consider table-driving the Area/Line curve cases.

These four tests repeat the same flow that setLengthChangeProgress and completeLengthChangeAnimation already help with, with only the renderer, selector, and data direction changing. Folding them into a small helper or it.each would reduce copy/paste drift.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/animation/legacyAnimationLengthChange.spec.tsx` around lines 293 - 355,
The four tests ('Area uses the final curve geometry immediately when data length
increases/decreases' and 'Line ...') duplicate the same flow; refactor them into
a table-driven test (it.each or a small helper) that iterates over
renderer/selector/data pairs to avoid copy/paste. Use the existing helpers
setLengthChangeProgress and completeLengthChangeAnimation and the spy helper
renderChartWithSelectorSpy, and parameterize the renderer functions
(renderAreaChart, renderLineChart), the selector strings
('.recharts-area-curve', '.recharts-line-curve'), and data directions
(smallData→largeData vs largeData→smallData) while keeping assertions that
initialCurve !== finalCurve and midCurve === finalCurve via getCurvePoints.