Tak, powinieneś przetestować cały łańcuch zdarzeń jako całość. Tak więc w przykładzie z procedurą, która wstawia się do tabeli i powoduje uruchomienie kilku wyzwalaczy, powinieneś napisać testy jednostkowe, które ocenią procedurę dla różnych danych wejściowych. Każdy test jednostkowy powinien przejść pomyślnie lub nie, w zależności od tego, czy zwraca prawidłowe wartości, poprawnie zmienia stan tabel, tworzy poprawny e-mail, a nawet wysyła poprawne pakiety sieciowe, jeśli ma to na celu. Krótko mówiąc, każdy efekt powinien zostać zweryfikowany.
Masz rację, że projektowanie testów jednostkowych wymaga pewnej pracy, ale większość z nich musi zostać wykonana w celu ręcznego przetestowania jednostki, po prostu zapisujesz pracę wymaganą do przetestowania jednostki, aby w przypadku zmiany w przyszłości testowanie może być równie dokładne i znacznie łatwiejsze.
Zmiana danych sprawia, że testowanie jest trudniejsze, ale nie czyni testowania mniej ważnym i faktycznie zwiększa wartość testowania jednostkowego, ponieważ większość trudności należy przemyśleć tylko raz, a nie za każdym razem, gdy wprowadzana jest zmiana w jednostce. Aby to ułatwić, można zapisać zapisane zestawy danych, wstawki / aktualizacje / skasowania, które są częścią instalacji / porzucenia, oraz operacje o wąskim zakresie. Ponieważ pytanie nie jest specyficzne dla bazy danych, szczegóły mogą się różnić.
Na górnym lub dolnym końcu nie ma progu złożoności, który powinien powstrzymywać cię przed testowaniem lub testowaniem jednostkowym. Rozważ następujące pytania:
- Czy zawsze piszesz kod wolny od błędów?
- Czy małe jednostki są zawsze wolne od błędów?
- Czy w przypadku dużego urządzenia może być błąd?
- Ile błędów zajmuje katastrofa?
Załóżmy, że zaczynasz nową pracę i masz za zadanie zoptymalizować małą funkcję używaną w wielu miejscach. Cała aplikacja została napisana i utrzymywana przez pracownika, którego nikt nawet nie pamięta. Jednostki mają dokumentację opisującą normalne oczekiwane zachowanie, ale niewiele więcej. Który z nich wolisz znaleźć?
- Brak testów jednostkowych w aplikacji. Po dokonaniu zmiany możesz wykonać ręczne testowanie samego urządzenia, aby upewnić się, że nadal zwraca oczekiwane wartości w dokumentacji. Następnie możesz wdrożyć go do produkcji, trzymać kciuki i mieć nadzieję, że zadziała (w końcu zawsze piszesz kod wolny od błędów, a optymalizacja w jednej jednostce nigdy nie wpłynie na inną) lub poświęcisz mnóstwo czasu na naukę, jak cała aplikacja działa, dzięki czemu można ręcznie przetestować każdą jednostkę bezpośrednio lub pośrednio.
- Testy jednostkowe w całej aplikacji, które są uruchamiane automatycznie codziennie lub na żądanie. Sprawdzają nie tylko normalne wartości wejściowe i ich oczekiwaną odpowiedź, ale także nieprawidłowe wartości i oczekiwane wyjątki. Dokonujesz zmiany i uruchamiasz pakiet testów jednostkowych dla aplikacji, natychmiast zauważając, że trzy inne jednostki nie zwracają już oczekiwanych wyników. Dwa z nich są łagodne, więc dostosowujesz testy jednostkowe, aby to uwzględnić. Trzeci wymaga kolejnego drobnego ulepszenia i małego nowego testu jednostkowego. Po wprowadzeniu zmian cały zestaw testów kończy się powodzeniem, a Ty wprowadzasz zmiany z pewnością.