To jest.
Nawet jeśli przeprowadzasz tylko testy jednostkowe, nie jest niczym niezwykłym posiadanie w testach większej ilości kodu niż faktycznie testowany. Nie ma w tym nic złego.
Rozważ prosty kod:
public void SayHello(string personName)
{
if (personName == null) throw new NullArgumentException("personName");
Console.WriteLine("Hello, {0}!", personName);
}
Jakie byłyby testy? Istnieją co najmniej cztery proste przypadki do przetestowania tutaj:
Imię osoby to null. Czy wyjątek jest rzeczywiście zgłaszany? To co najmniej trzy wiersze kodu testowego do napisania.
Imię osoby to "Jeff". Czy otrzymamy "Hello, Jeff!"odpowiedź? To cztery linie kodu testowego.
Imię osoby jest pustym ciągiem. Jakiej wydajności oczekujemy? Jaka jest rzeczywista wydajność? Pytanie poboczne: czy spełnia wymagania funkcjonalne? Oznacza to kolejne cztery wiersze kodu dla testu jednostkowego.
Imię osoby jest wystarczająco krótkie, aby napisać, ale jest zbyt długie, aby można je było połączyć z "Hello, "wykrzyknikiem. Co się dzieje?
Wymaga to dużo kodu testowego. Co więcej, najbardziej elementarne fragmenty kodu często wymagają kodu instalacyjnego, który inicjuje obiekty potrzebne do testowania kodu, co często prowadzi również do napisania kodów pośredniczących i próbnych itp.
Jeśli stosunek jest bardzo duży, w takim przypadku możesz sprawdzić kilka rzeczy:
Czy w testach występuje duplikacja kodu? Fakt, że jest to kod testowy, nie oznacza, że kod powinien być duplikowany (kopiowany-wklejany) między podobnymi testami: takie kopiowanie utrudni utrzymanie tych testów.
Czy istnieją zbędne testy? Zasadniczo, jeśli usuniesz test jednostkowy, zasięg gałęzi powinien się zmniejszyć. Jeśli nie, może to oznaczać, że test nie jest potrzebny, ponieważ ścieżki są już objęte innymi testami.
Czy testujesz tylko kod, który powinieneś przetestować? Nie oczekuje się, że przetestujesz podstawowe biblioteki bibliotek zewnętrznych, ale wyłącznie kod samego projektu.
Dzięki testom dymu, testom systemowym i integracyjnym, testom funkcjonalnym i akceptacyjnym oraz testom obciążeniowym i obciążeniowym dodajesz jeszcze więcej kodu testowego, więc posiadanie czterech lub pięciu LOC testów dla każdego LOC rzeczywistego kodu nie jest czymś, o co powinieneś się martwić.
Uwaga na temat TDD
Jeśli martwisz się czasem, jaki zajmuje testowanie kodu, być może robisz to źle, to znaczy najpierw kod, a później testujesz. W takim przypadku TDD może pomóc, zachęcając cię do pracy w iteracjach 15-45 sekund, przełączając między kodem a testami. Według zwolenników TDD przyspiesza proces programowania, zmniejszając zarówno liczbę testów, które musisz wykonać, a co ważniejsze, ilość kodu biznesowego do napisania, a zwłaszcza przepisania na potrzeby testów.
¹ Niech n będzie maksymalną długością łańcucha . Możemy wywoływać SayHelloi przekazywać przez referencję ciąg o długości n - 1, który powinien działać dobrze. Teraz na Console.WriteLineetapie formatowanie powinno kończyć się ciągiem o długości n + 8, co spowoduje wyjątek. Być może ze względu na ograniczenia pamięci nawet ciąg znaków zawierający n / 2 znaków prowadzi do wyjątku. Pytanie, które należy zadać, brzmi: czy ten czwarty test jest testem jednostkowym (wygląda jak jeden, ale może mieć znacznie większy wpływ pod względem zasobów w porównaniu do średnich testów jednostkowych) i czy testuje rzeczywisty kod lub podstawową strukturę.