Testy Jednostkowe w C# Jak Profesjonalista - Najlepsze Praktyki i Wzorce

Testy jednostkowe są fundamentem wysokiej jakości oprogramowania. Dobrze napisane chronią przed regresjami, dokumentują zachowanie kodu i ułatwiają jego projektowanie. Z kolei słabo napisane testy potrafią utrudnić życie. Stają się kruche, nieczytelne i zabierają czas. Aby testy jednostkowe spełniały swoją rolę, muszą być pisane z głową. Dobry test jednostkowy powinien być m.in. szybki, izolowany (niezależny od zewnętrznych czynników), powtarzalny (zawsze daje ten sam wynik) i samo-sprawdzający (automatycznie wykrywa, czy przeszedł czy nie). W tym artykule zebrałem kluczowe praktyki i wzorce, które pomogą Ci pisać świetne testy jednostkowe w C#, utrzymując je prosto i czytelnie.

Najlepsze praktyki pisania testów jednostkowych w C#

[Fact]
public void Add_TwoNumbers_ReturnsTheirSum()
{
    /* Arrange */
    var calculator = new Calculator();

    /* Act */
    var result = calculator.Add(2, 3);

    /* Assert */
    Assert.Equal(5, result);
}

W powyższym teście od razu widać, jaki scenariusz jest sprawdzany. Separacja sekcji AAA zapobiega mieszaniu logiki z asercjami i sprawia, że test jest łatwiejszy do zrozumienia i utrzymania.
    
3. Testuj jedną rzecz na test (jeden scenariusz na raz). Każdy test jednostkowy powinien koncentrować się na jednym konkretnym przypadku lub warunku. Unikaj testów, które sprawdzają wiele niezwiązanych aspektów naraz. Zasada "jedna asercja na test" bywa nieco dyskusyjna, ale kluczowe jest, by test sprawdzał jeden fragment zachowania. Dzięki temu w razie niepowodzenia od razu wiadomo, która konkretna sytuacja zawiodła. To podejście często oznacza także jedno wywołanie akcji (Act) na test, jeśli potrzebujesz przetestować wiele wariantów, lepiej napisać osobne testy lub użyć parametryzowanych przypadków niż wywoływać metodę wiele razy w pętli. Efektem jest zestaw mniejszych, ale bardziej precyzyjnych testów, które łatwiej diagnozować.
    
4. Unikaj logiki w kodzie testów. Kod testowy powinien być możliwie prosty i pozbawiony skomplikowanych konstrukcji. Gdy w testach zaczynasz dodawać pętle, instrukcje warunkowe (if/else, switch) czy wykonywać manipulacje na stringach, zwiększasz ryzyko, że same testy zawierają błędy. Test ma w zamierzeniu wykrywać problemy w kodzie produkcyjnym, a nie generować własne błędy. Dlatego nie umieszczaj w asercjach obliczeń ani złożonych wyrażeń. Oczekiwany rezultat zwykle najlepiej zapisać "na sztywno" w kodzie testu. Jeżeli czujesz potrzebę umieszczenia w teście bardziej złożonej logiki, rozważ podzielenie go na kilka prostszych testów lub użycie atrybutów [Theory] z kilkoma przypadkami zamiast pętli. Zasada jest prosta: testy mają być proste i zrozumiałe, nawet kosztem pewnej powtarzalności.
    
5. Stosuj minimalne dane wejściowe i czytelne stałe (bez "magicznych" wartości). Każdy test powinien używać najprostszych możliwych danych, potrzebnych do zweryfikowania danego scenariusza. Unikaj nadmiarowych informacji. Wszystko, co nie jest istotne dla danej asercji, tylko zaciemnia obraz. Przykładowo, jeśli testujesz sumowanie dwóch liczb, nie ma potrzeby tworzyć obiektu z dziesięcioma różnymi polami konfiguracyjnymi. Podobnie, wystrzegaj się "magicznych" wartości w kodzie testów, czyli wpisywania "z palca" liczbowych czy tekstowych literałów bez kontekstu. Takie wartości mogą dezorientować: ktoś czytający test może zastanawiać się, dlaczego akurat ta liczba czy string została użyta. Zamiast tego wyrażaj intencję, np. przypisz taką wartość do stałej o nazwie wyjaśniającej znaczenie (const string MAXIMUM_RESULT = "1001"; zamiast gołego "1001"). Dzięki temu test jest bardziej czytelny i łatwiejszy w utrzymaniu.
    
6. Izoluj testy od zewnętrznych zależności. Test jednostkowy powinien testować logikę w izolacji, dlatego nie może polegać na infrastrukturze zewnętrznej, takiej jak bazy danych, sieć, system plików czy API. Jeśli test wymaga danych z bazy lub wywołania usługi, to tak naprawdę nie jest testem jednostkowym, tylko integracyjnym. Takie przypadki należy albo odpowiednio odseparować, albo użyć atrap (test doubles), takich jak mocki czy stuby, aby zasymulować zachowanie zależności. W .NET mamy do dyspozycji biblioteki do mockowania (np. Moq, NSubstitute), które pozwalają tworzyć obiekty udające np. warstwę bazy danych. Ideą jest to, by w teście jednostkowym mieć pełną kontrolę nad środowiskiem, w którym działa testowany kod. Przykładowo, jeśli metoda korzysta z DateTime.Now, rozważ wprowadzenie interfejsu IDateTimeProvider i podstawienie w teście kontrolowanego "zegara" zwracającego określoną datę. Unikając prawdziwych zależności infrastrukturalnych, testy będą szybsze i mniej podatne na fałszywe alarmy, a ewentualne błędy w zewnętrznych systemach nie zaburzą wyników Twoich testów jednostkowych.
    
7. Dbaj o czytelność i utrzymanie testów (czasem odłóż zasadę DRY). Kod testów zasługuje na taką samą dbałość jak kod produkcyjny. Nie traktuj go po macoszemu tylko dlatego, że "to przecież testy". Czytelność testu jest najważniejsza, dlatego czasami dopuszczalne jest powtórzenie pewnego kodu w różnych testach, jeśli dzięki temu każdy z nich będzie bardziej zrozumiały. Innymi słowy, nie zawsze musisz na siłę usuwać duplikacji (zasada DRY - Don't Repeat Yourself) w testach kosztem klarowności. Od pewnego czasu mówi się wręcz o zasadzie DAMP (Descriptive And Meaningful Phrases) w testach, co oznacza, że testy mogą być lekko "wilgotne" (czyli zawierać powtórzenia), byle były opisowe i przejrzyste. Sam Martin Fowler zauważa: "Czytelność ma znaczenie. Nie staraj się być na siłę DRY. Powielanie kodu jest w porządku, jeśli poprawia czytelność.". Oczywiście trzeba zachować zdrowy rozsądek i nie tworzyć chaosu. Przydatne mogą być metody pomocnicze ułatwiające powtarzalne czynności w testach (np. tworzenie obiektów domyślnych), ale stosuj je tylko tam, gdzie nie ukrywają istotnych szczegółów testu. Pamiętaj też o refaktoryzacji testów, gdy zmienia się logika w aplikacji, popraw również testy, żeby nadal były aktualne i spełniały swoją rolę. Zwracaj uwagę na nazwy metod testowych, duplikujący się kod czy nieużywane już przypadki, utrzymuj swoją bazę testów w czystości.
    
8. Testuj zachowanie z perspektywy publicznego API, nie szczegóły implementacji. Testy jednostkowe powinny weryfikować co robi kod, a nie jak to robi. Oznacza to, że zwykle piszemy testy wyłącznie dla metod publicznych lub chronionych (w uzasadnionych przypadkach), zamiast testować metody prywatne bezpośrednio. Prywatne metody są detalem implementacyjnym klasy, jeśli spełniają swoją rolę, będzie to widoczne poprzez działanie metod publicznych, które je wywołują. Skupiając się na interfejsie publicznym, zyskujesz pewność, że testy sprawdzają faktyczną funkcjonalność modułu w sposób używany przez resztę aplikacji. Próby testowania metod prywatnych (np. poprzez refleksję lub zmiany ich modyfikatora na potrzeby testów) prowadzą do kruchej i mocno związanej z implementacją bazy testów, co utrudnia refaktoryzację kodu produkcyjnego. Zamiast tego pisz testy tak, jakbyś był konsumentem danego komponentu, dzięki temu będą one odporne na zmiany wewnętrzne, o ile kontrakt (zachowanie zewnętrzne) pozostaje bez zmian.

Podsumowanie