Załóżmy, że masz testy dla dwóch metod klasy. Pierwsza metoda zbiera dane z innej warstwy i umieszcza je w jakimś magazynie niezależnym od środowiska wykonawczego (takim jak tabela SQL), więc wszystkie dane obsługiwane przez ten test są zakodowane na stałe w teście. Druga metoda jest odpowiedzialna za pobieranie danych z miejsca, w którym opuściła je pierwsza metoda i przekształcanie jej w jakiś sposób (obliczenia, przenoszenie niektórych części w inne miejsca itp.).
Teraz ta druga metoda może mieć zakodowane dane wejściowe, takie jak pierwsza, lub można założyć, że dwa testy zostaną uruchomione sekwencyjnie i może zacząć od miejsca, w którym zakończył się pierwszy test, biorąc dane, które były naprawdę zapisane w pierwszym teście.
Jeśli wybrałeś drugą opcję, naprawdę miałbyś dobry pomysł, że obie metody dobrze się ze sobą bawią, jednak jeśli pierwszy test się nie powiedzie, wszystkie testy po nim się nie powiodą, pozbawiając korzyści z testowania, pomagając szybciej izolować błędy.
Jeśli wybrałeś pierwszą opcję, każda metoda byłaby izolowana i testowana niezależnie, ale tak naprawdę nigdy nie wiedziałbyś, że naprawdę mogą ze sobą poprawnie współpracować.
Która jest tutaj lepsza opcja? Czy istnieje jakaś alternatywa, na przykład posiadanie jednego testu dla każdej izolowanej metody z kodowaniem na twardo, a następnie większych testów, które zawierają obie metody w jednym?
źródło
Odpowiedzi:
Jeśli twoje metody są naprawdę niezależne, nie powinno to mieć znaczenia. Twoja druga metoda powinna:
a) Działa poprawnie, jeśli jest przedstawiany z ważnymi danymi.
b) Zawodzą w sposób rozsądny i konsekwentny, gdy są przedstawiane z nieprawidłowymi danymi.
Podobnie twoja pierwsza metoda powinna zrobić to samo. Tak długo, jak zajmujesz się przypadkami błędów, będą one działały poprawnie.
Jeśli chcesz sprawdzić, czy metody działają poprawnie razem, to jest to test integracyjny, a nie test jednostkowy.
źródło
Jeśli testy nie mogą przebiegać niezależnie, to nie są to testy jednostkowe.
Test jednostkowy nie powinien opierać się na żadnym stanie zewnętrznym, takim jak zawartość tabeli bazy danych. Powinien on czysto przetestować jedną jednostkę kodu w izolacji.
Testy, które zmieniają lub wymagają określonego stanu, są ważne, mogą na przykład stanowić część testów integracyjnych, w takich przypadkach ważne jest, aby upewnić się, że dokonano odpowiedniej konfiguracji, ale nie byłyby to testy jednostkowe. W tym przypadku nadal nie radziłbym, aby jeden test wymagał uruchomienia innego. Jeśli tak jest, powinieneś prawdopodobnie rozdzielić wymagany kod na osobną metodę konfiguracji. Możesz mieć jeden test, który następnie wywołuje kod konfiguracji i weryfikuje na przykład, czy nie zgłoszono wyjątku, a następnie inny test, który aktywnie wykorzystuje dane ustawione w metodzie konfiguracji.
źródło
Jestem pewien, że teraz wydaje się OK, aby mieć test jednostkowy B, który zależy od stanu pozostawionego przez test jednostkowy B. Ale zastanów się za rok, kiedy masz tysiąc testów jednostkowych. Czy naprawdę chcesz poczekać dziesięć minut, aż cały zestaw testów zakończy się za każdym razem, gdy musisz wprowadzić zmiany?
Zależy to oczywiście od twojego stylu programowania, ale jeśli chcesz mieć nadzieję na przyzwoity rozwój oparty na testach, w którym możesz wiele razy przeprowadzić indywidualny test podczas opracowywania funkcji, sugeruję, aby dać każdemu testowi możliwość samodzielnego działania.
źródło
Wygląda na to, że mówisz o konfiguracji testowej, którą można wykonać na kilka sposobów. Chcesz czystą kopię danych testowych (zwaną urządzeniem) dla każdego testu, więc każdy z nich nie powinien zależeć od siebie.
Istnieje kilka frameworków, które pozwalają na tego typu testy, oraz narzędzia takie jak DBUnit, które pozwalają szybko budować i burzyć struktury danych na początku i na końcu testów oraz pakietów testowych.
źródło