Co składa się na dobry test jednostkowy? [Zamknięte]

Jestem pewien, że większość z was pisze wiele testów automatycznych i że podczas testów jednostkowych napotkaliście również pewne typowe pułapki.

Moje pytanie brzmi: czy przestrzegasz jakichś zasad postępowania przy pisaniu testów, aby uniknąć problemów w przyszłości? A dokładniej: jakie są właściwości dobrych testów jednostkowych lub jak piszesz swoje testy?

Zachęca się do sugestii językowych.

Zacznę od podłączania źródeł - pragmatyczne testowanie jednostkowe w Javie z JUnitem (jest też wersja z C # -Nunit ... ale mam tę ... jest w większości agnostyczna.)

Dobre testy powinny być WYCIECZKĄ (akronim nie jest wystarczająco lepki - mam wydruk ściągawki w książce, którą musiałem wyciągnąć, aby upewnić się, że wszystko się zgadza ..)

• Automatyczny : Wywoływanie testów, jak również sprawdzanie wyników dla wyniku PASS / FAIL powinno być automatyczne
• Thorough : pokrycie; Chociaż błędy mają tendencję do gromadzenia się wokół pewnych regionów w kodzie, upewnij się, że przetestowano wszystkie kluczowe ścieżki i scenariusze. Użyj narzędzi, jeśli musisz znać nieprzetestowane regiony
• Powtarzalne : Testy powinny dawać te same wyniki za każdym razem ... za każdym razem. Testy nie powinny opierać się na niekontrolowanych parametrach.
• Niezależne : bardzo ważne.
  • Testy powinny testować tylko jedną rzecz naraz. Wiele asercji jest w porządku, o ile wszystkie testują jedną funkcję / zachowanie. Gdy test się nie powiedzie, powinien wskazać lokalizację problemu.
  • Testy nie powinny na sobie polegać - izolowane. Brak założeń dotyczących kolejności wykonywania testów. Przed każdym testem upewnij się, że jest to „czyste konto”, używając odpowiednio konfiguracji / dezaktywacji

• Profesjonalny : na dłuższą metę będziesz mieć tyle kodu testowego, co produkcyjny (jeśli nie więcej), dlatego postępuj zgodnie z tym samym standardem dobrego projektowania kodu testowego. Dobrze podzielone na czynniki metody-klasy z nazwami ujawniającymi intencje, bez duplikacji, testy z dobrymi nazwami itp.

• Dobre testy również działają szybko . każdy test, który trwa ponad pół sekundy, musi zostać opracowany. Im dłużej trwa uruchomienie zestawu testów… tym rzadziej będzie uruchamiany. Im więcej zmian, które deweloper spróbuje przekraść się między biegami… jeśli coś się zepsuje… zajmie więcej czasu ustalenie, która zmiana była przyczyną.

Aktualizacja 2010-08:

• Czytelne : można to uznać za część wersji Professional - jednak nie można tego wystarczająco podkreślić. Test kwasowości polega na znalezieniu kogoś, kto nie jest częścią twojego zespołu i poproszeniu go o ustalenie testowanego zachowania w ciągu kilku minut. Testy muszą być utrzymywane tak jak kod produkcyjny - więc należy je łatwo odczytać, nawet jeśli wymaga to więcej wysiłku. Testy powinny być symetryczne (według wzorca) i zwięzłe (testuj jedno zachowanie na raz). Używaj spójnej konwencji nazewnictwa (np. Stylu TestDox). Unikaj zaśmiecania testu "przypadkowymi szczegółami" ... stań się minimalistą.

Poza tym, większość innych to wskazówki, które ograniczają pracę o niskich korzyściach: np. „Nie testuj kodu, którego nie jesteś właścicielem” (np. Biblioteki DLL innych firm). Nie próbuj testować metod pobierających i ustawiających. Miej oko na stosunek kosztów do korzyści lub prawdopodobieństwo defektu.

1. Nie pisz gigantycznych testów. Jak sugeruje „jednostka” w „teście jednostkowym”, uczyń każdy z nich możliwie atomowy i odizolowany . Jeśli trzeba, utwórz warunki wstępne za pomocą pozorowanych obiektów, zamiast ręcznie odtwarzać zbyt dużą część typowego środowiska użytkownika.
2. Nie testuj rzeczy, które oczywiście działają. Unikaj testowania klas od zewnętrznego dostawcy, zwłaszcza tego, który dostarcza podstawowe API frameworka, w którym kodujesz. Np. Nie testuj dodawania pozycji do klasy Hashtable dostawcy.
3. Rozważ użycie narzędzia do pokrycia kodu, takiego jak NCover, aby odkryć przypadki skrajne, których jeszcze nie przetestowałeś.
4. Spróbuj napisać test przed wdrożeniem. Pomyśl o teście jako o specyfikacji, do której będzie się stosować Twoja implementacja. Por. także rozwój oparty na zachowaniu, bardziej specyficzna gałąź rozwoju opartego na testach.
5. Bądź konsekwentny. Jeśli piszesz testy tylko dla części swojego kodu, jest to mało przydatne. Jeśli pracujesz w zespole, a niektórzy lub wszyscy inni nie piszą testów, to też nie jest to zbyt przydatne. Przekonaj siebie i wszystkich innych o ważności (i właściwościach oszczędzających czas ) testowania lub nie przejmuj się.

Większość odpowiedzi tutaj wydaje się odnosić do najlepszych praktyk testowania jednostkowego w ogóle (kiedy, gdzie, dlaczego i co), a nie do pisania samych testów (jak). Ponieważ pytanie wydawało się dość konkretne w części „jak”, pomyślałem, że opublikuję to, zaczerpnięte z prezentacji „brązowej torby”, którą przeprowadziłem w mojej firmie.

Pięć zasad pisania testów Womp:

1. Używaj długich, opisowych nazw metod testowych.

   - Map_DefaultConstructorShouldCreateEmptyGisMap()
   - ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
   - Dog_Object_Should_Eat_Homework_Object_When_Hungry()

2. Napisz testy w stylu Rozmieść / Działaj / Potwierdź .

• Chociaż ta strategia organizacyjna istnieje już od jakiegoś czasu i nazywa się wieloma rzeczami, wprowadzenie akronimu „AAA” niedawno było świetnym sposobem na osiągnięcie tego. Ujednolicenie wszystkich testów ze stylem AAA sprawia, że ​​są one łatwe do odczytania i utrzymania.

3. Zawsze dostarczaj komunikat o błędzie wraz z potwierdzeniami.

Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element 
processing events was raised by the XElementSerializer");

• Prosta, ale satysfakcjonująca praktyka, która pokazuje w aplikacji biegacza, co się nie udało. Jeśli nie podasz komunikatu, zwykle w wyniku błędu pojawi się komunikat „Oczekiwano, że prawda, było fałszem”, co oznacza, że ​​musisz przeczytać test, aby dowiedzieć się, co jest nie tak.

4. Skomentuj powód testu - jakie jest założenie biznesowe?

  /// A layer cannot be constructed with a null gisLayer, as every function 
  /// in the Layer class assumes that a valid gisLayer is present.
  [Test]
  public void ShouldNotAllowConstructionWithANullGisLayer()
  {
  }

• Może się to wydawać oczywiste, ale ta praktyka ochroni integralność testów przed osobami, które w ogóle nie rozumieją przyczyny testu. Widziałem wiele testów, które zostały usunięte lub zmodyfikowane, które były całkowicie w porządku, po prostu dlatego, że osoba nie rozumiała założeń, które test weryfikował.
• Jeśli test jest trywialny lub nazwa metody jest wystarczająco opisowa, można zostawić komentarz bez komentarza.

5. Każdy test musi zawsze przywracać stan każdego zasobu, którego dotyka

• Tam, gdzie to możliwe, używaj prób, aby uniknąć korzystania z prawdziwych zasobów.
• Czyszczenie należy wykonać na poziomie testowym. Testy nie mogą w żaden sposób polegać na kolejności wykonania.

Pamiętaj o tych celach (na podstawie książki xUnit Test Patterns autorstwa Meszaros)

• Testy powinny zmniejszać ryzyko, a nie wprowadzać go.
• Testy powinny być łatwe do przeprowadzenia.
• Testy powinny być łatwe w utrzymaniu, ponieważ system wokół nich ewoluuje

Kilka rzeczy, które mogą to ułatwić:

• Testy powinny kończyć się niepowodzeniem tylko z jednego powodu.
• Testy powinny testować tylko jedną rzecz
• Zminimalizuj zależności testowe (brak zależności od baz danych, plików, interfejsu użytkownika itp.)

Nie zapominaj, że możesz również przeprowadzić testy integracyjne ze swoim środowiskiem xUnit, ale oddziel testy integracyjne i testy jednostkowe

Testy powinny być izolowane. Jeden test nie powinien zależeć od drugiego. Co więcej, test nie powinien polegać na systemach zewnętrznych. Innymi słowy, testuj swój kod, a nie kod, od którego ten kod zależy - możesz testować te interakcje w ramach testów integracyjnych lub funkcjonalnych.

Niektóre właściwości świetnych testów jednostkowych:

• Gdy test się nie powiedzie, powinno być natychmiast oczywiste, na czym polega problem. Jeśli musisz użyć debugera, aby wyśledzić problem, testy nie są wystarczająco szczegółowe. Pomaga w tym posiadanie dokładnie jednego potwierdzenia na test.

• Podczas refaktoryzacji żadne testy nie powinny zakończyć się niepowodzeniem.

• Testy powinny przebiegać tak szybko, że nigdy nie wahasz się przed ich uruchomieniem.

• Wszystkie testy powinny zawsze przejść pomyślnie; brak wyników niedeterministycznych.

• Testy jednostkowe powinny być dobrze rozłożone na czynniki, tak jak kod produkcyjny.

@Alotor: Jeśli sugerujesz, że biblioteka powinna mieć testy jednostkowe tylko w swoim zewnętrznym interfejsie API, nie zgadzam się. Chcę testów jednostkowych dla każdej klasy, w tym klas, których nie ujawniam zewnętrznym wywołującym. (Jeśli jednak czuję potrzebę pisania testów dla metod prywatnych, muszę dokonać refaktoryzacji ).

EDYCJA: Pojawił się komentarz dotyczący powielania spowodowanego „jednym potwierdzeniem na test”. W szczególności, jeśli masz kod do skonfigurowania scenariusza, a następnie chcesz dokonać wielu potwierdzeń na jego temat, ale masz tylko jedno potwierdzenie na test, możesz zduplikować konfigurację w wielu testach.

Nie mam takiego podejścia. Zamiast tego używam urządzeń testowych dla każdego scenariusza . Oto przybliżony przykład:

[TestFixture]
public class StackTests
{
    [TestFixture]
    public class EmptyTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
        }

        [TestMethod]
        [ExpectedException (typeof(Exception))]
        public void PopFails()
        {
            _stack.Pop();
        }

        [TestMethod]
        public void IsEmpty()
        {
            Assert(_stack.IsEmpty());
        }
    }

    [TestFixture]
    public class PushedOneTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
            _stack.Push(7);
        }

        // Tests for one item on the stack...
    }
}

To, czego szukasz, to nakreślenie zachowań testowanej klasy.

1. Weryfikacja oczekiwanych zachowań.
2. Weryfikacja przypadków błędów.
3. Pokrycie wszystkich ścieżek kodu w klasie.
4. Ćwiczenie wszystkich funkcji składowych w klasie.

Podstawowym celem jest zwiększenie zaufania do zachowania klasy.

Jest to szczególnie przydatne, gdy patrzymy na refaktoryzację kodu. Martin Fowler opublikował interesujący artykuł dotyczący testowania w swojej witrynie internetowej.

HTH.

Twoje zdrowie,

Obrabować

Test powinien początkowo zakończyć się niepowodzeniem. Następnie powinieneś napisać kod, który sprawi, że przejdą, w przeciwnym razie ryzykujesz napisaniem testu, który jest błędny i zawsze kończy się wynikiem.

Podoba mi się właściwy akronim BICEP z wyżej wymienionej książki Pragmatic Unit Testing :

• Dobrze : czy wyniki są prawidłowe ?
• B : Czy wszystkie b oundary warunki poprawić?
• I : Czy możemy sprawdzić i nverse relacje?
• C : Czy możemy c wyniki Ross-kontrolne przy użyciu innych środków?
• E : Czy możemy zmusić e warunki rror się stało?
• P : Czy p cechy erformance w ryzach?

Osobiście uważam, że można zajść całkiem daleko, sprawdzając, czy otrzymujesz prawidłowe wyniki (1 + 1 powinno zwrócić 2 w funkcji dodawania), wypróbowując wszystkie warunki brzegowe, o których myślisz (np. Używając dwóch liczb, których suma jest większa niż maksymalna wartość całkowita w funkcji add) i wymusza warunki błędu, takie jak awarie sieci.

Dobre testy muszą być możliwe do utrzymania.

Nie do końca wymyśliłem, jak to zrobić w złożonych środowiskach.

Wszystkie podręczniki zaczynają się odklejać, gdy baza kodu zaczyna sięgać do setek tysięcy lub milionów linii kodu.

• Interakcje zespołowe eksplodują
• liczba przypadków testowych eksploduje
• eksploduje interakcje między komponentami.
• czas na zbudowanie wszystkich jednostek staje się znaczącą częścią czasu budowy
• zmiana interfejsu API może spowodować setki przypadków testowych. Mimo że zmiana kodu produkcji była łatwa.
• liczba zdarzeń wymaganych do sekwencjonowania procesów do odpowiedniego stanu wzrasta, co z kolei wydłuża czas wykonania testu.

Dobra architektura może kontrolować część eksplozji interakcji, ale nieuchronnie, gdy systemy stają się bardziej złożone, rośnie wraz z nią automatyczny system testowania.

Tutaj zaczynasz zajmować się kompromisami:

• testuj tylko zewnętrzne API, w przeciwnym razie refaktoryzacja wewnętrznych elementów skutkuje znaczną poprawką przypadku testowego.
• konfiguracja i zakończenie każdego testu staje się bardziej skomplikowane, ponieważ hermetyzowany podsystem zachowuje więcej stanu.
• nocna kompilacja i automatyczne wykonywanie testów wydłuża się do godzin.
• wydłużony czas kompilacji i wykonywania oznacza, że ​​projektanci nie wykonują lub nie będą wykonywać wszystkich testów
• Aby skrócić czas wykonywania testów, należy rozważyć sekwencjonowanie testów, aby skrócić konfigurację i porzucanie

Musisz także zdecydować:

gdzie przechowujesz przypadki testowe w swojej bazie kodu?

• jak dokumentujesz swoje przypadki testowe?
• czy osprzęt testowy może zostać ponownie użyty, aby zaoszczędzić na konserwacji przypadków testowych?
• co się dzieje, gdy nocne wykonanie przypadku testowego nie powiedzie się? Kto zajmuje się segregacją?
• Jak dbasz o pozorowane obiekty? Jeśli masz 20 modułów, z których wszystkie używają własnego smaku fałszywego interfejsu API, zmiana interfejsu API szybko się zmienia. Zmieniają się nie tylko przypadki testowe, ale także 20 pozorowanych obiektów. Te 20 modułów zostało napisanych przez kilka lat przez wiele różnych zespołów. To klasyczny problem z ponownym użyciem.
• osoby i ich zespoły rozumieją wartość testów automatycznych, po prostu nie podoba im się sposób, w jaki robi to inny zespół. :-)

Mógłbym trwać wiecznie, ale chodzi mi o to:

Testy muszą być możliwe do utrzymania.

Omówiłem te zasady jakiś czas temu w tym artykule w MSDN Magazine, który moim zdaniem jest ważny do przeczytania dla każdego programisty.

Sposób definiowania „dobrych” testów jednostkowych polega na tym, że mają one następujące trzy właściwości:

• Są czytelne (nazewnictwo, potwierdzenia, zmienne, długość, złożoność ...)
• Można je utrzymywać (bez logiki, nieprecyzyjne, oparte na stanie, refaktoryzowane ..)
• Są godne zaufania (przetestuj to, co właściwe, izolowane, nie testy integracyjne ...)

• Testy jednostkowe tylko testują zewnętrzny interfejs API jednostki, nie powinieneś testować zachowania wewnętrznego.
• Każdy test TestCase powinien testować jedną (i tylko jedną) metodę wewnątrz tego interfejsu API.
  • Należy uwzględnić dodatkowe przypadki testowe dla przypadków niepowodzenia.
• Przetestuj zasięg swoich testów: Po przetestowaniu jednostki powinno zostać wykonanych 100% linii wewnątrz tej jednostki.

Jay Fields ma wiele dobrych rad dotyczących pisania testów jednostkowych i jest post, w którym podsumowuje najważniejsze porady . Tam przeczytasz, że powinieneś krytycznie przemyśleć swój kontekst i ocenić, czy rada jest dla Ciebie warta. Otrzymasz tutaj mnóstwo niesamowitych odpowiedzi, ale od Ciebie zależy, która z nich będzie najlepsza w Twoim kontekście. Wypróbuj je i po prostu dokonaj refaktoryzacji, jeśli źle ci to pachnie.

Z poważaniem

Nigdy nie zakładaj, że trywialna metoda dwuwierszowa zadziała. Napisanie szybkiego testu jednostkowego jest jedynym sposobem, aby zapobiec ukąszeniu Cię przez brakujący test zerowy, niewłaściwy znak minus i / lub subtelny błąd zakresu, nieuchronnie wtedy, gdy masz jeszcze mniej czasu na rozwiązanie tego problemu niż teraz.

Popieram odpowiedź "WYCIECZKA", z tym że testy POWINNY polegać na sobie !!!

Czemu?

DRY - nie powtarzaj się - dotyczy również testów! Zależności testowe mogą pomóc 1) zaoszczędzić czas konfiguracji, 2) oszczędzić zasoby urządzeń i 3) wskazać awarie. Oczywiście pod warunkiem, że twój framework testowy obsługuje zależności pierwszej klasy. W przeciwnym razie, przyznaję, są złe.

Dalsze informacje http://www.iam.unibe.ch/~scg/Research/JExample/

Często testy jednostkowe są oparte na pozorowanych obiektach lub próbnych danych. Lubię pisać trzy rodzaje testów jednostkowych:

• „przejściowe” testy jednostkowe: tworzą własne pozorowane obiekty / dane i testują za ich pomocą swoje funkcje, ale niszczą wszystko i nie pozostawiają śladów (jak brak danych w testowej bazie danych)
• „trwały” test jednostkowy: testują funkcje w kodzie, tworząc obiekty / dane, które będą później potrzebne bardziej zaawansowanym funkcjom do ich własnego testu jednostkowego (unikając dla tych zaawansowanych funkcji ponownego tworzenia za każdym razem własnego zestawu pozorowanych obiektów / danych)
• „trwałe” testy jednostkowe: testy jednostkowe wykorzystujące pozorowane obiekty / dane, które już istnieją (ponieważ zostały utworzone w innej sesji testu jednostkowego) przez trwałe testy jednostkowe.

Chodzi o to, aby unikać powtarzania wszystkiego , aby móc przetestować wszystkie funkcje.

• Bardzo często uruchamiam trzeci rodzaj, ponieważ wszystkie pozorowane obiekty / dane już tam są.
• Drugi rodzaj prowadzę za każdym razem, gdy zmienia się mój model.
• Pierwszy z nich uruchamiam, aby raz na jakiś czas sprawdzić podstawowe funkcje, sprawdzić podstawowe regresje.

Pomyśl o dwóch rodzajach testów i traktuj je inaczej - testy funkcjonalne i testy wydajnościowe.

Użyj różnych danych wejściowych i danych dla każdego. Może być konieczne użycie innego oprogramowania dla każdego typu testu.

Używam spójnej konwencji nazewnictwa testów opisanej przez standardy nazewnictwa testów jednostkowych Roya Osherove'a. Każda metoda w danej klasie przypadku testowego ma następujący styl nazewnictwa MethodUnderTest_Scenario_ExpectedResult.

Pierwsza sekcja z nazwą testu to nazwa metody w testowanym systemie.

Następny jest konkretny scenariusz, który jest testowany.

Wreszcie są wyniki tego scenariusza.

Każda sekcja używa Upper Camel Case i jest oddzielona podcięciem.

Uważam, że jest to przydatne, gdy uruchamiam test, testy są grupowane według nazwy testowanej metody. A konwencja pozwala innym programistom zrozumieć cel testu.

Dołączam również parametry do nazwy metody, jeśli testowana metoda została przeciążona.