Generating unit tests for code that has none
A model reads an existing class and proposes extra test cases. Each candidate is then put through a filter chain — it must compile, it must pass repeatedly without flaking, and it must cover a branch the existing suite misses — before a person is ever asked to look at it.
- Effort
- Days of work
- Skill level
- Some technical skill
- Organisation size
- Mid-market
- Value
- Quality, Time saved
Tools named for this
- A large language model prompted with the class under test and its existing tests
- The project's own build, coverage and flakiness tooling, used as the filter chain
- A re-prompting loop that feeds a failing candidate back with its compiler or assertion error
What to check before you ship it in India
- Fixtures cloned from a production table are the quickest route to a realistic test and to a purpose-limitation problem: consent under section 6(1) is limited to the personal data necessary for the specified purpose, and populating a test database is not that purpose. Synthesise the fixture or mask it at the export step.
- A generated test that simply asserts today's behaviour freezes a defect in place. The suite goes green, the bug becomes the specification, and the next engineer reads the assertion as intent.
Sources
Every claim on this page traces to one of these, on the date it was read.
- The Digital Personal Data Protection Act, 2023 (No. 22 of 2023) — most obligations commence 13 May 2027 under the DPDP Rules 2025 — s.6(1) · Ministry of Electronics and Information Technology · a rule · read 2026-09-01
- An Empirical Evaluation of Using Large Language Models for Automated Unit Test Generation · arXiv (Schäfer, Nadi, Eghbali, Tip) · how it is done · read 2026-09-01
- Automated Unit Test Improvement using Large Language Models at Meta · arXiv (Alshahwan et al., Meta) · how it is done · read 2026-09-01