Pokud je AI správně využívána, je vynikající na vyjmenování části testování — vymýšlí hraniční případy a píše boilerplate kód rychle. Ale musíte ověřit, že jsou aserce smysluplné, protože AI bude s radostí psát testy, které projdou, aniž by cokoliv dokazovaly.
// 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
});
AI navrhla hraniční případy (0 a 100) a chybovou cestu, kterou byste mohli zapomenout. Vaším úkolem je potvrdit, že toBe(80) je správná očekávaná hodnota, ne jen hodnota, kterou se náhodou funkce chová.
Nejtěžší část testování není psaní test(...) bloků — je to myšlení na případy, kterou byste jinak minuli, a AI je v tom opravdu dobrá. Ale nemá ani tušení, co váš kód má dělat, pokud jí to neřeknete, takže bez kontroly má tendenci psát testy, které zrcadlují implementaci (projdou, ale projdou i kdyby byla funkce špatná). Když si AI vezmeš jako generátor hraničních případů a ty si vezmeš odpovědnost za aserce, dostaneš širší pokrytí a skutečnou správnost — rychlost od AI, úsudek od tebe.