Dobrze wykorzystana AI jest doskonała w części wyliczania testów — wymyśla przypadki brzegowe i szybko pisze boilerplate. Ale musisz zweryfikować, że asercje są sensowne, ponieważ AI chętnie pisze testy, które przechodzą bez udowodnienia czegokolwiek.
// 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 zaproponowała przypadki brzegowe (0 i 100) i ścieżkę błędu, którą możesz zapomnieć. Twoim zadaniem jest potwierdzić, że toBe(80) jest prawidłową oczekiwaną wartością, nie tylko tym, co funkcja zwraca.
Trudna część testowania to nie pisanie bloków test(...) — to myślenie o przypadkach, które w innym razie przegapiłbyś, a AI jest naprawdę w tym dobre. Ale nie wie, co Twój kod powinien robić, chyba że mu powiesz, więc bez nadzoru ma tendencję do pisania testów, które odbijają implementację (przechodzą, ale przeszłyby nawet jeśli funkcja byłaby błędna). Traktując AI jako generator przypadków brzegowych, podczas gdy ty posiadasz asercje, otrzymujesz szerokie pokrycie i rzeczywistą poprawność — szybkość od AI, sąd od ciebie.