TomekScieplek
commented
5 years ago Testy integracyjne zawsze (w przeciwieństwie do dobrze napisanych testów jednostkowych) stanowią pewnego rodzaju kompromis i nasze doświadczenia wykazały, że konfiguracja podstawowa bazy demo jest bardzo dobrym punktem wyjściowym. Większość danych w tej bazie się nie zmienia, natomiast jeżeli dane wejściowe mają wpływ na wynik testu, należy to uwzględnić. Mamy tutaj kilka opcji:
- Zasilenie bazy demo danymi przed testem z poziomu samego kodu. Jest to bardzo dobre, łatwe w utrzymaniu rozwiązanie. Zmiany nie zaśmiecają bazy pozostałym testom. Bardzo wygodne kiedy danych wejściowych nie jest dużo. Szczególnie przydatne dla zmian konfiguracyjnych na moment testu.
- Dbinit - tutaj wnosimy już dane trwale, które mają znaczenie w całym procesie testowania. Musimy też zadbać separację, by kolejne dbinity nie psuły rezultatów testów. W handlu separacje robimy za pomocą różnych kartotek towarowych lub kontrahentów. Przykładowo jeśli już mamy jakieś testy oparte o dbinit dla jakiejś kartoteki/kontrahenta, to kolejne dbinit rejestrują dane dla innej kartoteki/kontrahenta. Testy, które działają na szerszym zbiorze danych nie uwzględniając separacji, oczywiście obrywają po dodaniu dbinit.
- Kopia bazy - tutaj rodzi się pytanie ile takich baz się pojawi. Zarządzanie nimi może być dosyć uciążliwe.
- Ładowania plików dbinit na życzenie z kodu testu. Jest to jakiś kompromis pomiędzy 1 i 2.
gentooser
Nie jestem pewien czy to właściwe do tego miejsce. Jeśli mówimy, że testy powinny zapewniać niezmienność wejścia, to czy baza nunit_default powinna zawierać dane demonstracyjne? Okres obrachunkowy jest co roku inny - ten sam test puszczony za rok może nie zadziałać. A co będzie, jak zmienią się nazwiska pracowników? Może lepiej byłoby te dane dodać jako plik dbinit, do wykorzystania, jeśli ktoś ich potrzebuje, a bazę generować pustą?