Jak przetestować prawdziwy system – Notatka z nauki

Zanotowałem z tego materiału:

• Wybierz jedną bibliotekę do rozwiązania danego problemu. Nie używaj kilku bibliotek do rozwiązywania tego samego.
  • Skorzystaj z assercji, które przypominają język mówiony, np. AddertThat(XXX).IsNotNull();
• Zbuduj swój stos technologiczny!
• Spisz praktyki i zasady robienia testów (i programowania) w swoim zespole, a potem pilnuj ich za pomocą testów konwencji.
  • Nie rób klas bazowych BaseTest, lecz użyj @Rule.
  • Dziel testy na mniejsze i twórz klasy przygotowujące dane do testów (enkapsuluj).
  • Użyj BDD (behave driven development).
  • Twórz klasy przedstawiające kontekst testów (dane wejściowe dla danego testu).
  • W testach można wykorzystać prawdziwą bazę danych, ale trzeba bardzo uważać na zrobienie tego w sposób czysty.
  • Róbcie testy całym zespołem, uczcie się, refaktoryzujcie, wyciągajcie wnioski.
• Test integracyjny:
  • Testuje prawdziwy system w wersji release.
  • Zamockowane są zewnętrzne systemy (może być klasa Connectora zamockowana albo wystawiony na innym urlu zamockowany serwis np. za pomocą biblioteki WireMock).
• Testuj jak najwięcej w testach jednostkowych, bo są tanie i szybkie.
• Twórz nowe testy na pokrycie zgłoszonych błędów.
• Testy integracyjne są drogie w utrzymaniu i skomplikowane.
  • Przetestuj negatywny i pozytywny scenariusz.
  • Przetestuj uprawnienia.
  • Nie testuj wszystkich przypadków.
  • Przetestuj przekrój przez całą aplikację.
• Nie testuj wszystkiego. Nie zawsze opłaci się coś przetestować i naprawić błąd. Czasem koszty programistów są wyższe niż straty wynikające z błędów oprogramowania.