Testy zależą od powszechnie używanej funkcjonalności z NUnit

Question

Mam kod inicjalizacyjny do korzystania z mojego API. Inicjalizacja może się nie powieść i chciałbym ją przetestować w teście NUnit.

Po inicjalizacji można użyć interfejsu API. Testuję również API, ale wszystkie moje metody testowe będą używały tego samego, wspólnego kodu inicjalizacyjnego.

Co bym najlepiej jak jest, jeśli to zachowanie:

1. Test inicjalizacji jest uruchamiany.
2. Pozostałe testy są uruchamiane, jeśli [1] się powiedzie.

We wszystkich przypadkach, w których [1] się nie powiedzie, zostaną wykonane wszystkie inne testy. Ale cenną informacją jest to, że [1] się nie udaje. Właśnie tam najprawdopodobniej znajdę problem. Byłoby miło, gdyby inne testy mogły być oznaczone? lub coś, co wskazuje, że nie zostały wykonane, ponieważ zależą od nich funkcjonalności, które nie przeszły testów.

Wiem, że testy nie powinny być kruche. Ale nie mogę ominąć faktu, że kod inicjujący jest niezbędny do poprawnego wykonywania innych funkcji.

Jest to bardziej ogólny problem, gdy niektóre funkcje zależą od innych funkcji. Gdzie "inna funkcjonalność" jest zbyt często używana, aby zapewnić jakąkolwiek prawdziwą wartość, nieudawiąc wszystkich testów w zależności od tego. Byłoby lepiej, gdyby "inną funkcjonalność" testowano osobno.

Answer 1

Byłem w kontakcie z programistami NUnit. W tej chwili nie jest to możliwe bez napisania dość skomplikowanej wtyczki. Funkcja pojawi się gdzieś w bazie kodu 3.x, ale nie pojawi się w wersji 2.5. Rozważę napisanie tego, ale nie na razie.

Answer 2

OK oto jak pójdę na ten temat ...

Put wspólnego inicjalizacji do metody instalacji, ponieważ jej potrzebne dla wszystkich testów. Jeśli inicjalizacji zgłasza błąd, można zobaczyć

• Wszystkie testy w apartamencie upadającego (które zostały przeszkolone w czasie, aby uznać za wskazówkę, że może setup/porzuca został rzucony wyjątek).
• ślad stosu dla testów niepowodzeń zawierających metodę instalacji.

Jeśli jest to zbyt niejawne, możesz (chociaż nie polecam go) dodać do tego samego zestawu pusty test z dobrą nazwą. Jeśli ten test jest zielony, możesz być pewien, że Setup/common init zakończył się pomyślnie.

[Test] 
public void VerifySetup() {} 

Aktualizacja: Wydaje się, że masz dość niszowe wymaganie. Nie znam żadnego mechanizmu w NUnit, który określałby taką warunkową realizację testów - np. Uruchom Test2 do 10 tylko wtedy, gdy Test1 przejdzie.

Answer 3

Spróbuj tego:

1. Określenie "test inicjujących" jako TestCase

2. Dokonaj wszystkich innych testów podklasę tej TestCase

3. Tworzenie Suite kursujący swoje testy w określonej kolejności, tak aby twój "test inicjalizacji" był pierwszy.

Answer 4

Myślę, że to całkiem jasne cięcie.Problem polega na tym, że masz trudności z oddzieleniem obowiązków związanych z interfejsem API. Ty masz dwa. Inicjalizacja wykonania API i API. Pisanie testów, aby mieć taki rodzaj zależności, może cię zabić.

Zalecam więc, aby interfejs API utworzył obiekt inicjujący, a następnie różne obiekty poleceń, aby uruchomić interfejs API. Obiekty poleceń będą znajdować się w jakimś sklepie lub można je tworzyć w locie.

Interfejs API użyje wyśmiewanego obiektu inicjalizacyjnego i użyje wyśmianych obiektów poleceń.

Obiekt inicjujący naprawdę nie ma żadnych zależności oprócz tego, co jest potrzebne do zainicjowania.

Obiekty poleceń będą wymagały wyśmiewanego obiektu inicjalizacyjnego.

[EDIT]

Istnieją dwie drogi, aby uzyskać inne testy na niepowodzenie, jeśli test inicjalizacji nie

1. Dodaj zmiennej prywatnej przypadku testowego. private isInitialized = false;. Następnie wszystkie inne testy sprawdzają stan tej zmiennej, jeśli nie są prawdziwe, a następnie zawodzą.

2. Poszerz swoją walizkę testową o klasę API. Dodaj prywatną funkcję, która analizuje stan inicjalizacji.

Odkurzacz z nimi jest 2. Najszybszy realizacja to 1.

IMHO Może to być zapach kod kiedy trzeba kilka swoich badań w taki sposób. Jeśli, jak powiedziałeś, jest to test integracyjny. Dlaczego masz osobny test do inicjalizacji. Integracja polega bardziej na uruchomieniu akcji przeciwko Twojemu API. Dlatego każdy test integracyjny musi zainicjować interfejs API.

Może zajść potrzeba ponownego przemyślenia scenariusza awarii kaskady. Może to być zbyt duży hałas po zakończeniu testów.

[EDIT1a]

Jedynym sposobem, widzę, aby zaspokoić wymagania jest extend NUnit. W szczególności zajrzyj do producentów obudów testowych i Dekoratory testowe.

Link jest datowany na marzec 2008, więc mam nadzieję, że nie jest już nieaktualny.