Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Dojrzałość do testów

Paweł Potaczała Regular Software Engineer
Czy wyobrażasz sobie projekt z paroma tysiącami linii kodu? Od czego zacząć analizę, za co dany kawałek kodu odpowiada?
Dojrzałość do testów

Czy wyobrażasz sobie projekt z paroma tysiącami linii kodu? Od czego zacząć analizę, za co dany kawałek kodu odpowiada?



Czasami samodokumentujący się kod nie wystarcza, a opisywanie go dodatkowymi komentarzami, kawałek po kawałku, potrafi doprowadzić projekt z biegiem czasu do nieaktualnych w nim treści. Kod i komentarze zaczynają żyć własnym życiem. Jednym z dobrych sposobów jest właśnie zapoznanie się z napisanymi do niego testami, które w teorii powinny dać nam odpowiedź odnośnie przypadków biznesowych, jakie aplikacja powinna spełniać.

Na początku mojej kariery jako programista nie interesowało mnie zbytnio, czy kod posiada testy, miał po prostu działać. Z czasem zaczynałem jednak dostrzegać coraz większą wartość tego, jak bardzo ważne jest pisanie scenariuszy testowych. Tak naprawdę tylko testy gwarantują nam, że każdorazowo skompilowany kod źródłowy działa prawidłowo według oczekiwanych założeń biznesu. Mając dokładnie zdefiniowane scenariusze testowe oparte na realnych przypadkach biznesowych, możemy z całą pewnością powiedzieć, że nasz kod jest sterowany testami. Pamiętajmy też, że nie chodzi tutaj o 100%-owe pokrycie testami aplikacji, lecz przypadków jej użycia przez klientów.


Jak zatem pisać dobre testy?

Mamy tu tak naprawdę szeroki wachlarz możliwości i wskazówek. Od technik takich jak TDD czy BDD, przez różnego rodzaje kategorie testów, gdzie chciałbym się skupić na kluczowej, lecz mało wspominanej zalecie testów integracyjnych nad testami jednostkowymi - kosztem utrzymania.

W internecie możemy spotkać się z opinią, iż testy jednostkowe są tanie i szybko się je pisze. To wszystko prawda, lecz koszt ich utrzymania często jest większy, niż w przypadku testów integracyjnych. Podczas zwykłego chociażby refactoringu kodu, cały szkielet powiązanych testów jednostkowych przynależnych do zmienionych klas, także należy zmienić.

Zauważmy tutaj, że z punktu widzenia klienta przypadek użycia dalej jest taki sam, nic się nie zmieniło. Dobrze napisany test integracyjny w tym przykładzie zostanie nienaruszony dopóki nie zajdzie potrzeba zmiany przypadku. W moim przekonaniu to wszystko zależy od specyfiki aplikacji, ile % powinny stanowić testy jednostkowe, a integracyjne, lecz na pewno warte jest uwagi pytanie, czy zawsze testy jednostkowe powinny być jedyną lub najliczniejszą grupą w naszym projekcie.


Zaproszenie

Tym krótkim tekstem o dojrzałości do testów zapraszam do udziału w IT Pikniku, który odbędzie się 4 czerwca! Będzie można zadawać tam wszelkie nurtujące Was pytania. Odpowiadać na nie będą doświadczeni pracownicy branży IT.

IT Piknik to wydarzenie powstałe w odpowiedzi na potrzeby studentów kierunków informatycznych oraz osób rozważających zmianę swojego obecnego stanowiska. Jego wizją jest umożliwienie studentom znalezienia własnej ścieżki kariery, poprzez wymianę informacji i doświadczeń z przedstawicielami firm w swobodnej atmosferze.

Zapraszam na stronę FB IT Pikniku i do wydarzenia na Facebooku.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej

Zobacz jakie firmy chcą Ci płacić więcej.

Ile teraz zarabiasz?

Podpowiedzieliśmy już razy.

Mamy ponad 1200 ofert pracy. Zobacz o ile więcej możesz zarabiać. » [zamknij]