return 12

Co się dzieje, kiedy harmonogram na wykonanie jakiegoś zadania jest zbyt napięty? Wykonuje się je "po łebkach", obniżając drastycznie jakość - tak żeby je "popchnąć".
Każdy zna przykład takiej sytuacji, a ja przedstawię moją ulubioną historyjkę ;)

MS Word jest programem, dzięki któremu Windows zawdzięcza popularność. To ten edytor tekstu był "killer app" dla systemu Microsoftu i to dzięki niemu okienka tak chętnie były widziane w biurach.

I Word jako "killer app" dla okienek musiał zostać opracowany jak najszybciej. Prawdę mówiąc, harmonogram był niezwykle sportowy, wręcz szalony.

A taki punkt jak naprawa znalezionych błędów nie był częścią tego harmonogramu. Dlatego programiści pisali kod, który był w sposób oczywisty błędny tylko po to aby "popchnąć" zadanie i nie przekroczyć harmonogramu. Potem czekali na raport o znalezionych błędach, który przychodził ze sporym opóźnieniem.

Najlepszym przykładem takiego kodu była funkcja, która miała zwracać wysokość bieżącej linii tekstu w punktach. Ponieważ 90% ludzi pisze używając Times New Roman 12, to sprytny programista napisał:

{
    return 12;
}

I czekał cierpliwie na raport iż funkcja w 10% przypadków zawodzi.

Jeżeli ktoś do tej pory miał wątpliwości "po co używać testów jednostkowych", to ta historyjka chyba je rozwiała ;)

Źródło historyjki:
http://www.joelonsoftware.com/articles/fog0000000043.html - punkt 5. Pozostałe również warte przeczytania.