test/cartesian/YAxis/YAxis.7362.derivedDomain.spec.tsx (1)

47-60: ⚡ Quick win

Advance timers after rendering to account for Redux batching.

The helper renders a chart but doesn't call vi.runOnlyPendingTimers() afterward. According to coding guidelines, timer advancement is needed after renders due to Redux autoBatchEnhancer dependency on timers and requestAnimationFrame, even when isAnimationActive={false}.

⏱️ Proposed fix

 function renderDerivedDomainChart({ data, domain }: { data: ReadonlyArray<Datum>; domain: AxisDomain }) {
   const axisDomainSpy = vi.fn();
 
   const renderResult = render(
     <LineChart width={500} height={300} data={data}>
       <XAxis dataKey="name" />
       <YAxis type="number" domain={domain} allowDataOverflow ticks={[...explicitTicks]} />
       <Line type="monotone" dataKey="value" stroke="`#8884d8`" isAnimationActive={false} connectNulls />
       <ExpectAxisDomain assert={axisDomainSpy} axisType="yAxis" />
     </LineChart>,
   );
+
+  vi.runOnlyPendingTimers();
 
   return { ...renderResult, axisDomainSpy };
 }

As per coding guidelines: Call vi.runOnlyPendingTimers() to advance timers after renders when not using createSelectorTestCase helper due to Redux autoBatchEnhancer dependency on timers and requestAnimationFrame.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/cartesian/YAxis/YAxis.7362.derivedDomain.spec.tsx` around lines 47 - 60,
The renderDerivedDomainChart helper does not advance timers after rendering,
which is required because Redux autoBatchEnhancer and requestAnimationFrame can
queue work even when isAnimationActive={false}; after calling render(...) inside
renderDerivedDomainChart, call vi.runOnlyPendingTimers() to flush pending timers
so ExpectAxisDomain (axisDomainSpy) observes the settled state—add the
vi.runOnlyPendingTimers() invocation immediately after the render(...) call in
renderDerivedDomainChart.

test/cartesian/YAxis/YAxis.7362.derivedDomain.spec.tsx (1)

76-91: ⚡ Quick win

Consider adding a test for empty data with wholeDomainFunction.

The suite tests functionUpperBound with both allNullData and empty data: [], but only tests wholeDomainFunction with allNullData. Adding an it.fails test for empty data with wholeDomainFunction would provide symmetric coverage and more thoroughly document the bug.

➕ Suggested additional test case

   it.fails('renders the ladder for all-null data with a whole-domain function', () => {
     const { container } = renderChart({ data: allNullData, domain: wholeDomainFunction });
     expectYAxisTicks(container, ladder);
   });
+
+  it.fails('renders the ladder for empty data with a whole-domain function', () => {
+    const { container } = renderChart({ data: [], domain: wholeDomainFunction });
+    expectYAxisTicks(container, ladder);
+  });
 });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/cartesian/YAxis/YAxis.7362.derivedDomain.spec.tsx` around lines 76 - 91,
Add a symmetric failing test for the empty-data case using wholeDomainFunction:
mirror the existing it.fails that uses allNullData with wholeDomainFunction by
adding an it.fails that calls renderChart({ data: [], domain:
wholeDomainFunction }) and asserts expectYAxisTicks(container, ladder); locate
the other tests around the describe('YAxis issue 7362 …') block and use the same
pattern as the functionUpperBound empty-data test to ensure coverage for
wholeDomainFunction with empty data.