In my projects, specifically working on our React-based low-code platform, I structure our testing strategy around the Testing Trophy model: prioritizing integration and component tests that give high confidence without excessive maintenance overhead, supported by unit tests for pure logic and Playwright for critical end-to-end user journeys.
<h3>1. Unit &amp; Component Testing: Vitest + React Testing Library</h3>
<ul>
<li>
Unit Testing (Vitest): Focused strictly on isolated, pure business logic where edge cases are dense. In a low-code environment, this means our data transformation pipelines, schema validators, state serialization, and expression parsers. Vitest runs these in milliseconds with zero DOM overhead.
</li>
<li>
Component &amp; Integration Testing (Vitest + jsdom + RTL): We test user-facing behavior rather than implementation details. Using React Testing Library, we test interactions from the user's perspective (finding elements by accessible roles/text rather than class names or test IDs).
</li>
<li>
Concrete example: For our documentation and preview engine, we run integration tests that mount the real components, verify dynamic target highlights, ensure portal modals attach correctly, and assert strict network isolation (guaranteeing zero unexpected API requests fire during preview mode).
</li>
<li>
Mocking Boundary: We keep mocks strictly at the network layer (using MSW or mocked fetch handlers) rather than mocking child components, ensuring that our component boundaries communicate properly.
</li>
</ul>
<h3>2. End-to-End Testing: Playwright</h3>
<ul>
<li>Generated Apps vs. Platform Builder: We use Playwright with real Chromium/WebKit/Firefox instances. For end users building applications on our platform, we expose a Playwright-backed runner where users can record workflows via codegen and validate production apps.</li>
<li>Complex UI &amp; Canvas Coverage: A known limitation of <code>jsdom</code> is that it lacks a layout engine and cannot compute bounding boxes, drag-and-drop pointer events, or canvas pixel coordinates. For core builder features such as drag-and-drop block orchestration and canvas positioning, we leverage Playwright to run in real headless browsers where layout geometry and synthetic pointer events are accurate.</li>
<li>Test Selection: We keep E2E suites lean to avoid flakiness and high CI runtimes. We reserve Playwright for critical paths: authentication, saving/publishing a workflow, and the core canvas manipulation loop.</li>
</ul>
<h3>3. CI/CD Pipeline &amp; Merge Discipline</h3>
<ul>
<li>Automated CI Gates: Every PR must pass <code>vitest run</code> and linting in CI before code review or merge. We avoid relying on local pre-push checks or manual developer verification.</li>
<li>Test Reliability &amp; Maintenance: We avoid brittle assertions (like testing snapshot HTML or CSS classes). When using AI tools to assist in generating boilerplate tests, we treat them with high scrutiny, every test must fail when the underlying contract breaks and pass only when the expected behavior is satisfied, rather than just asserting whatever the DOM happens to output currently.</li>
</ul>

This is my answer

There is no right or wrong on this, do review your current project and list up the achievements related to testing. 1. what tools do you use 2. what d…