Mój kod jest świetny!

Testowanie to naprawdę świetna sprawa. Pokazuje, czy wszystko działa:)
Tylko, że niestety nie pokazuje. Jedynie dostarcza nam informacji, że nie udało nam się znaleźć błędu, a to jest naprawdę istotna różnica.

Pośrednio właśnie z tego powodu, tak istotne jest, moim zdaniem, aby wszelkie testy akceptacyjne były pisane przez osobę która nie uczestniczyła w tworzeniu danej funkcjonalności, a wie "jedynie", jak powinno to wszystko działać.

Dlaczego?
Dlatego, że mój kod (Wasz również :) jest świetny! Przecież spędziłem trochę czasu nad jego implementacją, napisałem testy jednostkowe, które "dowodzą" jego niezawodności! Ba! Nawet go trochę zrefaktoryzowałem na sam koniec, aby był czytelniejszy i żeby się z nim lepiej pracowało:)

"Mój kod jest świetny, a testy pokazują, że działa" - jest to mylne przeświadczenie, ale ciężko się go oduczyć, a nawet wtedy trudno jest programiście myśleć o testach inaczej.

I o ile w przypadku testów jednostkowych, to nie jest problem, bo dotykają stosunkowo małej i niezbyt złożonej funkcjonalności, to w przypadku testów akceptacyjnych osoba je wykonująca musi pamiętać o tym, co tak naprawdę jest jej zadaniem.
Tester nie ma za zadanie udowodnić, że dostarczony kod działa, o to powinni zadbać programiści. Tester ma za zadanie znaleźć braki i/lub błędy w funkcjonalności. To jest jego cel.

Programista, nawet zdając sobie sprawę z tego, jaki cel powinien mu przyświecać, gdy tworzy testy do swojego kodu, mimowolnie zakłada, że wszystko działa. W końcu sam to pisałem! Myślałem o tym, żeby napisać to jak najlepiej!

W takim myśleniu nie ma nic złego. To dobrze, gdy uważamy, że nasz kod jest dobry i działa, ale to czasami nie wpływa dobrze na jakość naszych testów. Nie wymyślimy przypadków użycia, o których nie pomyśleliśmy na etapie implementacji.
Komuś innemu może się to jednak udać :)