Co sprawia, że dobry test jednostkowy? [zamknięte]

1. nie pisz wielkich testów. Jak sugeruje "jednostka" w "badaniu jednostkowym", ułóż każdą z nich jako atomową i izolowaną, Jak to możliwe. Jeśli musisz, Utwórz warunki wstępne za pomocą obiektów wzorcowych, zamiast ręcznie odtwarzać zbyt wiele typowego środowiska użytkownika.
2. Nie testuj rzeczy, które oczywiście działają. unikaj testowania klas od zewnętrznego dostawcy, zwłaszcza tego dostarczającego podstawowe API frameworka, w którym kodujesz. Np. nie testuj Dodawanie elementu do klasy Hashtable dostawcy.
3. rozważ użycie narzędzia do pokrycia kodu, takiego jak NCover, aby pomóc odkryć przypadki krawędzi, które musisz jeszcze przetestować.
4. Spróbuj napisać test Przed implementacją. pomyśl o teście jako o specyfikacji, której będzie przestrzegać twoja implementacja. Cf. również behavior-driven development, bardziej specyficzna gałąź Test-driven development.
5. Bądź konsekwentny. Jeśli piszesz tylko testy dla niektórych z Twój kod jest mało przydatny. 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 znaczeniu (i właściwościachoszczędzających czas ) testów, lub nie przejmuj się.

Większość odpowiedzi tutaj wydaje się dotyczyć najlepszych praktyk w testowaniu jednostkowym w ogóle (kiedy, gdzie, dlaczego i CO), zamiast faktycznie pisać testy (jak). Ponieważ pytanie wydawało się dość specyficzne w części "jak", pomyślałem, że opublikuję to, zaczerpnięte z prezentacji" brązowej torby", którą przeprowadziłem w mojej firmie.

5 praw pisarskich Womp:

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

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

2. Napisz swoje testy w stylu Arrange/Act / Assert.

• podczas gdy ta strategia organizacyjna jest już od jakiegoś czasu i nazwane wieloma rzeczami, wstęp z akronimu " AAA " ostatnio ma to był świetny sposób, żeby to przekazać. Aby wszystkie testy były zgodne z Styl AAA sprawia, że są łatwe do odczytania i utrzymać.

3. Zawsze dostarczaj komunikat o awarii ze swoimi twierdzeniami.

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 czyni ją oczywistą w Twoja aplikacja runner nie powiodła się. Jeśli nie podasz wiadomości, zazwyczaj otrzymasz coś w rodzaju "oczekiwana prawda, było fałszywe" w wyniku błędu, co sprawia, że musisz rzeczywiście iść 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()
  {
  }

To może wydawać się oczywiste, ale to praktyka ochroni integralność Twoich testów od ludzi, którzy nie zrozumieć przyczynę badanie po pierwsze. Widziałem wiele testy zostają usunięte lub zmodyfikowane, że były w porządku, po prostu dlatego, że osoba nie rozumiała założenia, że test był sprawdzam.
• jeśli test jest trywialny lub metoda nazwa jest wystarczająco opisowa, to może być dopuszczalne opuszczenie komentuj off.

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

• używaj szyderstw tam, gdzie to możliwe, aby uniknąć radzenie sobie z rzeczywistością zasoby.
• czyszczenie musi być wykonane podczas testu poziom. Testy nie mogą mieć żadnych poleganie na zleceniu wykonania.

Miej na uwadze te cele (zaadaptowane z książki xUnit test Patterns autorstwa Meszarosa)

• testy powinny zmniejszać ryzyko, a nie przedstaw go.
Testy powinny być łatwe do przeprowadzenia.
• testy powinny być łatwe do utrzymania jako system ewoluuje wokół nich

Kilka rzeczy ułatwiających:

• testy powinny zawieść tylko z powodu jeden powód.
• testy powinny sprawdzać tylko jedną rzecz
• zminimalizuj zależności testu (nie zależności od baz danych, plików, ui itd.)

Nie zapominaj, że możesz również wykonywać testy intergracyjne ze swoim frameworkiem xUnit ale zachowaj testy intergracyjne i testy jednostkowe oddzielnie

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, przetestuj Twój kod, a nie Kod, od którego zależy Twój kod.Interakcje te można przetestować w ramach testów integracyjnych lub funkcjonalnych.

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

• Gdy test nie powiedzie się, powinno być natychmiast oczywiste, gdzie leży problem. Jeśli musisz użyć debuggera, aby wyśledzić problem, twoje testy nie są wystarczająco szczegółowe. Posiadanie dokładnie jednego twierdzenia na test pomaga tutaj.

• Podczas refaktoringu żadne testy nie powinny zawieść.

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

• Wszystkie testy powinny przejść zawsze; nie wyniki niedeterministyczne.

• Testy jednostkowe powinny być dobrze uwzględnione, tak jak Twój kod produkcyjny.

@Alotor: jeśli sugerujesz, że biblioteka powinna mieć tylko testy jednostkowe w swoim zewnętrznym API, Nie zgadzam się. Chcę testów jednostkowych dla każdej klasy, w tym klas, których nie wystawiam zewnętrznym rozmówcom. (Jednakże jeśli czuję potrzebę pisania testów dla metod prywatnych, to muszę refaktorować.)

EDIT: był komentarz o duplikacja spowodowana "jednym twierdzeniem na test". W szczególności, jeśli masz jakiś kod do skonfigurowania scenariusza, a następnie chcesz zrobić wiele twierdzeń na ten temat, ale masz tylko jedno twierdzenie na test, możesz powielać konfigurację w wielu testach.

[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 określenie zachowań badanych klas.

1. weryfikacja oczekiwanych zachowań.
2. weryfikacja przypadków błędów.
3. pokrycie wszystkich ścieżek kodu w klasie.
4. wykonywanie wszystkich funkcji członka w klasie.

Podstawowym celem jest zwiększenie pewności siebie w zachowaniu klasy.

Jest to szczególnie przydatne przy refaktoryzacji kodu. Martin Fowler ma interesującą Artykuł dotyczący testów na jego stronie internetowej.

HTH.

Pozdrawiam,

Rob

Test powinien się początkowo nie udać. Następnie powinieneś napisać kod, który sprawia, że przechodzą, w przeciwnym razie ryzykujesz napisanie testu, który jest na podsłuchu i zawsze przechodzi.

Podoba mi się odpowiedni akronim bicepsa ze wspomnianej książki pragmatyczne testy jednostkowe :

• Right : czy wyniki right?
• B : czy wszystkie warunkiB są prawidłowe?
• I : Czy możemy sprawdzić i nverse relacje?
• C : Czy możemy C sprawdzić wyniki za pomocą innych środków?
• E : Czy możemy wymusić e warunki rror?
• P : Czy P charakterystyka erformancji mieści się w granicach?

Osobiście uważam, że można uzyskać całkiem daleko, sprawdzając, czy masz odpowiednie wyniki (1+1 powinno zwracać 2 w funkcji dodawania), wypróbowując wszystkie warunki brzegowe, o których możesz myśleć (takie jak użycie dwóch liczb, których suma jest większa niż całkowita wartość max w funkcji dodawania) i wymuszając warunki błędów, takie jak awarie sieci.

Dobre testy muszą być utrzymywane.

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

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

• Team interactions explode
• liczba przypadków testowych
[[9]}interakcje między komponentami wybuchają.
• Czas na zbudowanie wszystkich jednostek staje się znaczącą częścią budowy CZAS
• zmiana API może przenieść się do setek przypadków testowych. Mimo że zmiana kodu produkcji była łatwa.
• zwiększa się liczba zdarzeń wymaganych do sekwencji procesów w odpowiednim stanie, co z kolei wydłuża czas wykonania testu.

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

W tym miejscu zaczynasz mieć do czynienia z

• tylko testowanie zewnętrznego API w przeciwnym razie refaktoryzacja wewnętrznych skutkuje znaczącymi przeróbkami przypadków testowych.
• konfiguracja i rozcięcie każdego testu staje się bardziej skomplikowane, ponieważ zamknięty podsystem zachowuje więcej stanu.
• nocne kompilowanie i automatyczne wykonywanie testów rośnie do godzin.
• zwiększony czas kompilacji i wykonania oznacza, że projektanci nie uruchamiają lub nie będą uruchamiać wszystkich testów
• aby skrócić czas wykonywania testów, należy rozważyć przeprowadzenie testów sekwencyjnych reduce set up and tearddown

Musisz również zdecydować:

Gdzie przechowujesz przypadki testowe w bazie kodu?

• jak dokumentujesz swoje przypadki testowe?
• czy oprawy testowe mogą być ponownie używane do oszczędzania konserwacji przypadków testowych?
• co się dzieje, gdy nocne wykonanie przypadku testowego nie powiedzie się? Kto robi ocenę?
• jak utrzymujesz makiety obiektów? Jeśli masz 20 modułów, wszystkie używające własnego stylu mock logging API, zmiana API szybko się zmienia. Zmieniają się nie tylko przypadki testowe, ale także 20 obiektów wzorcowych. Te 20 modułów zostało napisanych w ciągu kilku lat przez wiele różnych zespołów. To klasyczny problem ponownego użycia.
• osoby i ich zespoły rozumieją wartość automatycznych testów, po prostu nie lubią tego, jak robi to drugi zespół. :-)

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

Testy muszą być konserwowane.

Opisałem te zasady jakiś czas temu w tym artykule magazynu MSDN, który moim zdaniem jest ważny dla każdego dewelopera.

Sposób, w jaki definiuję "dobre" testy jednostkowe, polega na tym, że posiadają one następujące trzy właściwości:

• są czytelne (nazewnictwo, twierdzenia, zmienne, długość, złożoność..)
• są Utrzymywalne (bez logiki, nie nadane, oparte na stanie, refakturowane..)
• są godni zaufania (testować właściwą rzecz, izolować, nie integrować testy..)

• Unit Testing po prostu testuje zewnętrzne API Twojej jednostki, nie powinieneś testować wewnętrznego zachowania.
• Każdy test TestCase powinien przetestować jedną (i tylko jedną) metodę wewnątrz tego API.
  • dodatkowe przypadki testowe powinny być uwzględnione dla przypadków awarii.
• Przetestuj pokrycie swoich testów: gdy jednostka zostanie przetestowana, 100% linii wewnątrz tej jednostki powinno zostać wykonane.

Jay Fields ma wiele dobrych rad na temat pisania testów jednostkowych i jest post, w którym podsumowuje najważniejsze Rady . Tam przeczytasz, że powinieneś krytycznie przemyśleć swój kontekst i ocenić, czy Rada jest dla Ciebie warta. Dostajesz mnóstwo niesamowitych odpowiedzi tutaj, ale to do ciebie zdecydować, który jest najlepszy dla Twojego kontekstu. Wypróbuj je i po prostu refaktoruj, jeśli śmierdzi ci źle.

Z Poważaniem

Nigdy nie zakładaj, że trywialna Metoda 2 linii będzie działać. Pisanie szybkiego testu jednostkowego jest jedynym sposobem, aby zapobiec zagryzieniu Cię przez brakujący test null, zagubiony znak minus i / lub subtelny Błąd zakresu, nieuchronnie, gdy masz jeszcze mniej czasu na radzenie sobie z nim niż teraz.

Popieram odpowiedź "A TRIP", tyle że testy powinny polegać na sobie!!!

Dlaczego?

DRY-Dont Repeat Yourself-dotyczy również testów! Zależności testowe mogą pomóc 1) zaoszczędzić czas konfiguracji, 2) oszczędzać zasoby urządzenia i 3) wskazywać na awarie. Oczywiście, tylko biorąc pod uwagę, że Twój Framework testowy obsługuje zależności pierwszej klasy. W przeciwnym razie, przyznaję, są źli.

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

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

• "przejściowe" testy jednostkowe: tworzą własne obiekty / Dane i testują za ich pomocą swoją funkcję, ale niszczą wszystko i nie zostawiają śladu (jak żadne dane w testowej bazie danych)
• "persistent" unit test: testują funkcje w Twoim kodzie, tworząc obiekty / dane, które będą później potrzebne bardziej zaawansowanym funkcjom do ich własnego testu jednostkowego (unikanie dla tych zaawansowanych funkcja do odtworzenia za każdym razem własnego zestawu mock obiektów / danych)
• "trwałe" testy jednostkowe: testy jednostkowe z wykorzystaniem obiektów / danych, które już istnieją (ponieważ zostały utworzone w innej sesji testów jednostkowych) przez trwałe testy jednostkowe.

Chodzi o to, aby uniknąć powtarzania wszystkiego , aby móc przetestować każdą funkcję.

• uruchamiam trzeci rodzaj bardzo często, ponieważ wszystkie makiety / dane już tam są.
• uruchamiam drugi rodzaj kiedykolwiek moja zmiana modelu.
• uruchamiam pierwszy, aby sprawdzić podstawowe funkcje raz na jakiś czas, aby sprawdzić podstawowe regresje.

Pomyśl o 2 rodzajach testów i traktuj je inaczej - testy funkcjonalne i testy wydajności.

Używaj różnych danych wejściowych i wskaźników dla każdego z nich. 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 przypadków testowych ma następującą metodę stylu nazwundertest_scenario_expectedresult.

Sekcja pierwsza nazwa 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 wielkich wielbłądów i jest oddzielona przez poniżej punktacji.

Uznałem to za przydatne, gdy uruchamiam test, testy są pogrupowane według nazwy testowanej metody. I mieć konwencję pozwalającą innym programistom zrozumieć intencję testu.

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