Used well, an AI is excellent at the enumeration part of testing — it brainstorms edge cases and writes the boilerplate fast. But you must verify the assertions are meaningful, because an AI will happily write tests that pass without proving anything.
// Function under test, with its contract:
// applyDiscount(price, percent) -> price reduced by percent.
// Contract: percent must be 0..100; throws RangeError otherwise. price >= 0.
function applyDiscount(price, percent) {
if (percent < 0 || percent > 100) throw new RangeError('percent out of range');
return price - (price * percent) / 100;
}
// AI-suggested test cases (Jest) — note the edge and error paths, not just happy path:
test('applies a normal discount', () => {
expect(applyDiscount(100, 20)).toBe(80); // happy path
});
test('0% leaves price unchanged', () => {
expect(applyDiscount(100, 0)).toBe(100); // boundary: lower edge
});
test('100% makes it free', () => {
expect(applyDiscount(100, 100)).toBe(0); // boundary: upper edge
});
test('rejects percent above 100', () => {
expect(() => applyDiscount(100, 150)).toThrow(RangeError); // error path
});
The AI proposed the boundary cases (0 and 100) and the error path you might forget. Your job is to confirm toBe(80) is the correct expected value, not just whatever the function happens to return.
The hard part of testing isn't typing the test(...) blocks — it's thinking of the cases you'd otherwise miss, and an AI is genuinely good at that breadth. But it has no idea what your code is supposed to do unless you tell it, so left unchecked it tends to write tests that mirror the implementation (they pass, but they'd pass even if the function were wrong). Treating the AI as an edge-case generator while you own the assertions gives you broad coverage and real correctness — speed from the AI, judgment from you.