Przypadki testowe "kiedy", "co" i "dlaczego"?

Question

Będąc nowicjuszem w rozwoju testowym, to pytanie mnie dręczyło. Jak dużo jest za dużo? Co powinno być testowane, jak powinno być testowane i dlaczego powinno być testowane? Podane przykłady są w języku C# z NUnit, ale zakładam, że samo pytanie jest agnostyczne.

Oto dwa aktualne przykłady własne testy na ogólną listę obiektów (testowane z ciągami, funkcja inicjalizacji dodaje trzy elementy {"Foo", "Bar", "Baz"}):

[Test] 
public void CountChanging() 
{ 
    Assert.That(_list.Count, Is.EqualTo(3)); 
    _list.Add("Qux"); 
    Assert.That(_list.Count, Is.EqualTo(4)); 
    _list[7] = "Quuuux"; 
    Assert.That(_list.Count, Is.EqualTo(8)); 
    _list.Remove("Quuuux"); 
    Assert.That(_list.Count, Is.EqualTo(7)); 
} 

[Test] 
public void ContainsItem() 
{ 
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false)); 
    _list.Add("Qux"); 
    Assert.That(_list.Contains("Qux"), Is.EqualTo(true)); 
    _list.Remove("Qux"); 
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false)); 
} 

Kod jest dość self-komentowania, więc Nie będę się wdawał w to, co się dzieje, ale czy to nie jest zajęcie zbyt daleko? Add() i Remove() są testowane osobno oczywiście, więc na jaki poziom powinienem przejść z tego rodzaju testami? Czy powinienem mieć nawet tego rodzaju testy?

Answer 1

Powiedziałbym, że to, co faktycznie testujesz, to klasy równoważności.Moim zdaniem nie ma różnicy między dodaniem do listy zawierającej 3 przedmioty lub 7 przedmiotów. Istnieje jednak różnica między 0 pozycjami, 1 pozycją i> 1 pozycjami. Najprawdopodobniej będę miał 3 testy dla metod Add/Remove dla tych przypadków.

Po pojawieniu się błędów z QA/użytkowników, dodałem każdy taki raport o błędzie jako przypadek testowy; zobacz błąd rozmnażaj się przez uzyskanie czerwonego paska; napraw błąd, zdobywając zielony pasek. Każdy taki "wykrywanie błędów" pozostanie - to moja sieć bezpieczeństwa (czytaj: test regresji), że nawet jeśli popełnię ten błąd ponownie, będę miał natychmiastową informację zwrotną.

Answer 2

Czy _list jest instancją klasy, którą napisałeś? Jeśli tak, powiedziałbym, że testowanie jest uzasadnione. Jednak w takim przypadku, dlaczego tworzysz niestandardową klasę List?

Jeśli nie jest to kod, który napisałeś, nie testuj go, chyba że podejrzewasz, że jest w jakiś sposób błędny.

---

Próbuję przetestować kod, który jest niezależny i modułowy. Jeśli istnieje jakiś rodzaj funkcji Boga w kodzie, który muszę utrzymywać, rozszyfrowuję go jak najwięcej w podfunkcje i testuję je niezależnie. Wtedy funkcja Boga może być napisana jako "oczywiście poprawna" - bez gałęzi, bez logiki, po prostu przekazując wyniki z jednej dobrze przetestowanej podfunkcji do drugiej.

Answer 3

Pomyśl o swoich testach jako o specyfikacji. Jeśli Twój system może się zepsuć (lub mieć istotne błędy) bez niepowodzenia testów, oznacza to, że nie masz wystarczającego zasięgu testowego. Jeśli jeden punkt awarii powoduje, że wiele testów się zepsuje, prawdopodobnie masz za dużo (lub są zbyt ściśle powiązane).

To jest naprawdę trudne do zdefiniowania w obiektywny sposób. Przypuszczam, że powiedziałbym, że popełniłem błąd przy testowaniu zbyt wiele. Wtedy, gdy testy zaczynają was denerwować, są to konkretne testy do refaktoryzacji/zmiany przeznaczenia (ponieważ są zbyt kruche, albo testują niewłaściwą rzecz, a ich niepowodzenia nie są użyteczne).

Answer 4

Kilka porad:

1. Każdy powinien przetestować testcase tylko jedno. Oznacza to, że struktura testówki powinna być "setup", "execute", "assert". W swoich przykładach mieszasz te fazy. Spróbuj podzielić swoje metody testowe. Dzięki temu łatwiej zobaczyć dokładnie, co testujesz.

2. Spróbuj podać metodom testowym nazwę opisującą to, co testuje. To znaczy. trzy testcases zawarte w twoim ContainsItem() stają się: containsReportsFalseIfTheItemHasNotBeenAdded(), containsReportsTrueIfTheItemHasBeenAdded(), containsReportsFalseIfTheItemHasBeenAddedThenRemoved(). Uważam, że zmuszanie się do wymyślania opisowej nazwy pomaga mi wyobrazić sobie to, co muszę przetestować, zanim zakodowuję rzeczywisty test.

3. Jeśli wykonujesz TDD, powinieneś napisać swój test jako pierwszy i dodać kod do swojej implementacji tylko wtedy, gdy masz awaryjny test. Nawet jeśli tego nie zrobisz, da ci to pojęcie, ile testów wystarczy. Możesz też użyć narzędzia do pokrycia. W przypadku prostej klasy, takiej jak kontener, powinieneś dążyć do 100% pokrycia.