test-gen

Focus on behavior rather than implementation: cover the happy path, edge cases like empty or null inputs, error paths, and boundary conditions. Use Arrange-Act-Assert structure, descriptive test names, and keep tests deterministic with no real time, randomness, or network calls.

Brainstorm across seven categories: Happy, Sad, Bad, Race, Boundary, Permission, and State transitions. Build a matrix of input times state times permission, then prioritize Critical scenarios first and map each scenario to unit, integration, or E2E level.

Cover successful payment, insufficient funds, adversarial inputs like negative amounts or SQL injection, idempotency against duplicate charges, card expiration boundaries, non-logged-in users, and valid versus blocked state transitions such as paid back to cart.

Yes. The workflow first discovers the project's framework by inspecting files like package.json, pyproject.toml, Cargo.toml, or go.mod, then matches the existing test style, naming conventions, fixtures, and the project's runner command.

Flaky tests usually come from real time, randomness, network calls, shared state, or sleeping to wait for async behavior. Make tests deterministic by mocking time and randomness, isolating state, and using proper synchronization primitives instead of sleeps.

Use unit tests for single-function inputs and edge cases, integration tests for module interactions, concurrency, and permission checks, and E2E tests for core user journeys. Follow the pyramid: many fast unit tests, fewer integration tests, and five to ten critical E2E scenarios.