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


97

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.

Odpowiedzi:


93

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.


Możemy nie zgodzić się na użycie Mocks, ale był to bardzo fajny opis najlepszych praktyk testowania jednostkowego.
Justin Standard,

W takim razie podbiję to jako odpowiedź, ponieważ uważam, że akronim „WYCIECZKA” jest przydatny.
Spoike,

3
W większości się zgadzam, ale chciałbym zwrócić uwagę, że testowanie kodu, którego nie jesteś właścicielem, przynosi korzyści ... Testujesz, czy spełnia on Twoje wymagania. Jak inaczej możesz mieć pewność, że aktualizacja nie uszkodzi twoich systemów? (Ale oczywiście, robiąc to, pamiętaj o stosunku kosztów do korzyści.)
Rozczarowany

@Craig - Myślę, że masz na myśli (na poziomie interfejsu) testy regresyjne (lub w niektórych przypadkach testy uczniów), które dokumentują zachowanie, na którym polegasz. Nie pisałbym testów `` jednostkowych '' dla kodu innej firmy, ponieważ plik. sprzedawca wie więcej o tym kodzie niż ja b. Dostawca nie jest zobowiązany do zachowania żadnej konkretnej implementacji. Nie kontroluję zmian w tej bazie kodu i nie chcę tracić czasu na naprawianie zepsutych testów poprzez aktualizację. Więc wolałbym zakodować kilka testów regresji wysokiego poziomu dla zachowania, którego używam (i chcę być powiadamiany, gdy jest uszkodzony)
Gishu,

@Gishu: Tak, absolutnie! Testy należy wykonywać tylko na poziomie interfejsu; i tak naprawdę powinieneś co najwyżej przetestować funkcje, których faktycznie używasz. Ponadto przy wyborze tego, co napisać te testy; Zauważyłem, że proste, nieskomplikowane ramy testowania „jednostkowego” zwykle idealnie pasują do rachunku.
Rozczarowany

42
  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ę.

1
Dobra odpowiedź. Ale nie jest tak źle, jeśli nie wykonujesz testów jednostkowych dla wszystkiego w dostawie. Jasne, że to lepsze, ale potrzebna jest równowaga i pragmatyzm. Re: zaangażowanie współpracowników; czasami wystarczy to zrobić, aby zademonstrować wartość i jako punkt odniesienia.
Martin Clarke,

1
Zgadzam się. Jednak na dłuższą metę trzeba umieć polegać na testach, które tam są, tj. Zakładać, że zostaną przez nie złapane typowe pułapki. W przeciwnym razie korzyści są znacznie zmniejszone.
Sören Kuklau,

2
„Jeśli piszesz testy tylko dla części swojego kodu, jest to mało przydatne”. Czy tak jest naprawdę? Mam projekty z 20% pokryciem kodu (obszary kluczowe / podatne na awarie) i bardzo mi pomogły, a projekty też są w porządku.
dr. zły

1
Zgadzam się ze Slough. Nawet jeśli jest tylko kilka testów, biorąc pod uwagę, że są dobrze napisane i wystarczająco odizolowane, będą bardzo pomocne.
Spoike

41

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.

2
+1 z powodu punktu 1, 2 i 5 są ważne. 3 i 4 wydają się raczej przesadne w przypadku testów jednostkowych, jeśli już używasz opisowych nazw metod testowych, ale polecam dokumentację testów, jeśli mają duży zakres (testy funkcjonalne lub akceptacyjne).
Spoike

+1 za praktyczną i praktyczną wiedzę oraz przykłady
Phil

17

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


Myślę, że miałeś na myśli adaptację z książki „xUnit Test Patterns” autorstwa Gerarda Meszarosa. xunitpatterns.com
Spoike,

Tak, masz rację.
Wyjaśnię

Doskonałe punkty. Testy jednostkowe mogą być bardzo przydatne, ale bardzo ważne jest, aby nie wpaść w pułapkę posiadania złożonych, współzależnych testów jednostkowych, które stanowią ogromny podatek za wszelkie próby zmiany systemu.
Klin

9

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.


9

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...
    }
}

Nie zgadzam się co do jednego stwierdzenia na test. Im więcej asercji masz w teście, tym mniej będziesz mieć przypadków testowych typu „wytnij i wklej”. Uważam, że przypadek testowy powinien koncentrować się na scenariuszu lub ścieżce kodu, a stwierdzenia powinny wynikać ze wszystkich założeń i wymagań, aby spełnić ten scenariusz.
Lucas B

Myślę, że zgadzamy się, że DRY dotyczy testów jednostkowych. Jak powiedziałem, „Testy jednostkowe powinny być dobrze rozłożone na czynniki”. Jednak istnieje wiele sposobów rozwiązania problemu powielania. Jedna, jak wspomniałeś, polega na przeprowadzeniu testu jednostkowego, który najpierw wywołuje testowany kod, a następnie potwierdza wiele razy. Alternatywą jest utworzenie nowego „osprzętu testowego” dla scenariusza, który wywołuje testowany kod podczas kroku inicjalizacji / konfiguracji, a następnie wykonuje serię testów jednostkowych, które po prostu potwierdzają.
Jay Bazuzi

Moja ogólna zasada jest taka, że ​​jeśli używasz kopiuj-wklej, robisz coś nie tak. Jednym z moich ulubionych powiedzeń jest „Kopiuj-wklej nie jest wzorcem projektowym”. Zgadzam się również, że jedno twierdzenie na test jednostkowy jest ogólnie dobrym pomysłem, ale nie zawsze się na to upieram. Podoba mi się bardziej ogólne „przetestuj jedną rzecz na test jednostkowy”. Chociaż zwykle przekłada się to na jedno potwierdzenie na test jednostkowy.
Jon Turner

7

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ć


Rob - mechaniczny to jest dobre, ale mija się z celem. Dlaczego to wszystko zrobiłeś? Myślenie w ten sposób może pomóc innym podążać ścieżką TDD.
Mark Levison,

7

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.


@Rismo Nie jest wyłączny per se. Z definicji to, co napisał tutaj Quarrelsome, dotyczy wyłącznie metodologii „Test First”, która jest częścią TDD. TDD bierze również pod uwagę refaktoryzację. Najbardziej "smarty pants", jaką przeczytałem, to TDD = Test First + Refactor.
Spoike,

Tak, to nie musi być TDD, po prostu upewnij się najpierw, że twój test się nie powiedzie. Następnie drut w pozostałej części. Zdarza się to najczęściej podczas wykonywania TDD, ale możesz to zastosować, gdy nie używasz TDD.
Quibblesome

6

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.


6

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.


5

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 ...)

Roy, z całego serca się zgadzam. Te rzeczy są o wiele ważniejsze niż pokrycie przypadków skrajnych.
Matt Hinze,

godny zaufania - doskonała uwaga!
ratkok

4
  • 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.

2

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


1

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.


1

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/


Zgadzam się z tobą. TestNG to kolejny framework, w którym zależności są łatwo dozwolone.
Davide,

0

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.

0

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.


A co z testami jednostkowymi?
Spoike,

0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.