Standardy pisania testów jednostkowych

Powinieneś rzucić okiem na serię "pragmatyczne testy jednostkowe". This is the C# version but there is another for Java.

W odniesieniu do twojego spec, ja bymNie poszedł za burtę. Masz bardzo dobry początek - konwencje nazewnictwa są bardzo ważne. Wymagamy również, aby struktura katalogów pasowała do oryginalnego projektu. Zakres musi również obejmować przypadki graniczne i nielegalne wartości (sprawdzanie WYJĄTKÓW). To oczywiste, ale twój spec jest to miejsce, aby zapisać go do tego argumentu, że nieuchronnie będziesz miał w przyszłości z facetem, który nie chce testować na kogoś przekazującego nielegalną wartość. Ale nie rób specyfikacji więcej niż kilka stron, bo nikt nie użyje jej do zadania, które jest tak zależne od kontekstu.

Update: nie zgadzam się z Panem ziemniaczanym łbem co do jednego twierdzenia na test jednostkowy. W teorii brzmi to całkiem dobrze, ale w praktyce prowadzi to albo do mnóstwa zbędnych testów, albo do ludzi wykonujących Tony pracy w skonfigurować i zburzyć, że sam należy przetestować.

Podążam za stylem BDD TDD. Zobacz też: http://blog.daveastels.com/files/BDD_Intro.pdf http://dannorth.net/introducing-bdd http://behaviour-driven.org/Introduction

W skrócie oznacza to, że

• Testy nie są traktowane jako "testy", ale jako specyfikacje zachowania systemu (zwane dalej "specyfikacjami"). Intencją specyfikacji nie jest sprawdzanie, czy system działa w każdych okolicznościach. Ich intencją jest określenie zachowanie i kierowanie projektowaniem systemu.

• Nazwy metod spec zapisywane są jako pełne zdania angielskie. Na przykład specyfikacje dla piłki mogą zawierać "piłka jest okrągła" i "gdy piłka uderza w podłogę, to odbija się".

• Nie ma wymuszonej relacji 1:1 między klasami produkcyjnymi a klasami spec (a generowanie metody testowej dla każdej metody produkcyjnej byłoby szalone). Zamiast tego istnieje zależność 1:1 między zachowaniem systemu i specyfikacje.

Jakiś czas temu napisałem tutorial TDD (w którym zaczyna się pisać grę Tetris na podstawie dostarczonych testów), który pokazuje ten styl pisania testów jako specyfikacje. Możesz go pobrać z http://www.orfjackal.net/tdd-tutorial/tdd-tutorial_2008-09-04.zip instrukcje jak zrobić TDD / BDD nadal brakuje w tym samouczku, ale przykładowy kod jest gotowy, więc możesz zobaczyć, jak są zorganizowane testy i napisać kod, który je przechodzi.

Będziesz zauważ, że w tym samouczku klasy produkcyjne są nazwane, takie jak plansza, blok, kawałek i Tetrominoe, które są skupione wokół koncepcji gry Tetris. Ale zajęcia testowe skupiają się wokół zachowania gry Tetris: FallingBlocksTest, RotatingPiecesOfBlocksTest, RotatingTetrominoesTest, FallingPiecesTest, MovingAFallingPieceTest, RotatingAFallingPieceTest itp.

1. spróbuj użyć jak najmniejszej liczby instrukcji assert dla każdej metody testowej. Zapewnia to, że cel testu jest dobrze określony.
2. wiem, że to będzie kontrowersyjne, ale nie testuj kompilatora - czas spędzony na testowaniu accesorów i mutatorów Java Bean lepiej poświęcić na pisanie innych testów.
3. spróbuj, jeśli to możliwe, użyć TDD zamiast pisać testy po kodzie.

Odkryłem, że większość konwencji testowania może być egzekwowana poprzez użycie standardowej klasy bazowej dla wszystkich testów. Zmuszanie testera do nadpisywania metod, aby wszystkie miały tę samą nazwę.

Popieram również styl testowania Arrange-Act-Assert (AAA), ponieważ możesz następnie wygenerować dość przydatną dokumentację z testów. Zmusza również do zastanowienia się, jakiego zachowania oczekujesz ze względu na styl nazewnictwa.

Innym elementem, który możesz umieścić w swoich standardach, jest próba utrzymania małego rozmiaru testu jednostkowego. To są faktycznie same metody testowania. Jeśli nie wykonujesz pełnego testu jednostkowego integracji, zazwyczaj nie ma potrzeby przeprowadzania dużych testów jednostkowych, jak np. ponad 100 linii. Dam ci tyle na wypadek, gdybyś miał dużo możliwości, by dostać się do jednego testu. Jednak jeśli to zrobisz, może powinieneś go refaktorować.

Ludzie mówią też o refaktoryzacji tam kodu upewnij się, że ludzie zdają sobie sprawę, że jednostka testy to też kod. Więc refaktor, refaktor, refaktor.

Uważam, że największym problemem w zastosowaniach, które widziałem, jest to, że ludzie nie zdają sobie sprawy, że chcesz, aby twoje testy jednostkowe były lekkie i zwinne. Nie chcesz monolitycznej bestii do testów. Mając to na uwadze, jeśli masz metodę, którą próbujesz przetestować, nie powinieneś testować każdej możliwej ścieżki w jednym teście jednostkowym. Powinieneś mieć wiele testów jednostkowych, aby uwzględnić każdą możliwą ścieżkę przez metodę.

Tak jeśli poprawnie wykonujesz testy jednostkowe, powinieneś mieć średnio więcej linii kodu testu jednostkowego niż Twoja aplikacja. Chociaż brzmi to jak dużo pracy, zaoszczędzi Ci dużo czasu w końcu, gdy nadejdzie czas na nieuniknioną zmianę wymagań biznesowych.

Użytkownicy w pełni funkcjonalnych IDE przekonają się, że "niektórzy z nich" mają dość szczegółowe wsparcie dla tworzenia testów w określonym wzorze. Dana klasa:

public class MyService {
    public String method1(){
        return "";
    }

    public void method2(){

    }

    public void method3HasAlongName(){

    }
}

Kiedy wciskam ctrl-shift-T w intellij IDEA dostaję tę klasę testową po odpowiedzi na 1 okno dialogowe:

public class MyServiceTest {
    @Test
    public void testMethod1() {
        // Add your code here
    }

    @Test
    public void testMethod2() {
        // Add your code here
    }

    @Test
    public void testMethod3HasAlongName() {
        // Add your code here
    }
}

Więc możesz chcieć przyjrzeć się dokładnie obsłudze narzędzi przed napisaniem swoich standardów.

Używam prawie prostego angielskiego dla nazw funkcji testów jednostkowych. Pomaga określić, co dokładnie robią:

TEST( TestThatVariableFooDoesNotOverflowWhenCalledRecursively )
{
/* do test */
}  

Używam C++ , ale konwencja nazewnictwa może być używana wszędzie.

Upewnij się, że zawiera to, co nie jest testem jednostkowym. Zobacz: czego nie testować, jeśli chodzi o testy jednostkowe?

Zawierają wytyczne, dzięki czemu testy integracyjne są jasno określone i mogą być uruchamiane oddzielnie od testów jednostkowych. Jest to ważne, ponieważ można zakończyć zestawem testów "jednostkowych", które są naprawdę powolne, jeśli testy jednostkowe są mieszane z innymi rodzajami testów.

Sprawdź to, aby uzyskać więcej informacji na ten temat: Jak mogę poprawić moje testy junit ... szczególnie drugi aktualizacja.

Jeśli używasz narzędzi z rodziny Junit (OCunit, SHunit, ...), nazwy testów już przestrzegają pewnych zasad.

Do moich testów używam niestandardowych tagów doxygen w celu zebrania ich dokumentacji na konkretnej stronie.