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.