Mutation testing: Too good to be true?

Widziałem w sieci artykuły ogłaszające, że code coverage umarł i nadszedł czas testowania mutacyjnego. ThoughtWorks po przerwie wraca do polecania w swoim raporcie Technology Radar narzędzia Pitest, które implementuje testowanie mutacyjne dla JVM. Postanowiłem przyjrzeć się, czy to podejście to faktycznie epokowa zmiana w podejściu do pisania testów jednostkowych. Będzie o czasie działania, zawartości raportów, skuteczności wyłapywania problemów, konfiguracji, obsłudze Kotlina. Artykuł po angielsku — zapraszam na Medium*.

* wejście z tego specjalnego linku nie zmniejszy waszego miesięcznego limitu darmowych artykułów w serwisie

Fast and stable MongoDB-based tests in Spring

Tradycyjne uruchamianie testowego MongoDB przez Flapdoodle Embedded Mongo kontra nowoczesne podejście z Testcontainers. Krótko o kontekstach w testach Springa przy okazji potwornego zużycia zasobów przez Flapdoodle. Mierzenie obciążenia systemu narzędziem sar i o użyteczności starego dobrego gnuplota. Artykuł po angielsku — zapraszam na Medium*.

* wejście z tego specjalnego linku nie zmniejszy waszego miesięcznego limitu darmowych artykułów w serwisie

Dzielenie się testowymi klasami pomocniczymi w Gradle’u

Czasem mamy przypadek, że piszemy test jednostkowy jakiejś klasy i okazuje się, że część kodu testowego może być przydatna w innych częściach naszego projektu. Jak udostępnić ten kod, żeby był widoczny zarówno w testach aktualnego projektu, jak i w testach projektów od niego zależnych? Gradle od wersji 5.6 udostępnia dla tego celu plugin java-test-fixtures.

Czytaj dalej Dzielenie się testowymi klasami pomocniczymi w Gradle’u

Testy kontraktowe: Pact bez Pact Brokera

pact-jvm to jeden z dwóch wiodących frameworków do pisania testów kontraktowych dla Javy i JVM. Problemem na wejściu może być znalezienie sposobu na dzielenie się kontraktami: oficjalnie polecanym rozwiązaniem jest serwer Pact Broker, napisany w Rubym. Postawienie serwera trochę ułatwia dostępność obrazu dockerowego, ale wciąż całość wymaga nieco zabawy. Jeśli chcemy na szybko sprawdzić, czy Pact nam się podoba, wolelibyśmy opcję wymagającą minimalnego nakładu pracy.

Tu pojawia się możliwość rzadko wspominana w tutorialach Pacta: wymiana kontraktów przez repozytorium Mavena, nawet takie lokalnie na dysku. Nie potrzebujemy niczego poza narzędziami, które i tak mamy programując w Javie.

Czytaj dalej Testy kontraktowe: Pact bez Pact Brokera

ExpectedException i pułapki łapania wyjątków w testach

Pisząc testy we frameworku JUnit 4 mamy kilka opcji na zapisanie warunku, że testowany kod powinien rzucić wyjątkiem. Wymieniając najprostsze, niewymagające dodatkowych bibliotek:

  1. dodanie atrybutu „expected” do adnotacji na metodzie testowej: @Test(expected = IllegalStateException.class)
  2. otoczenie kodu blokiem try-catch
  3. użycie reguły ExpectedException

Pierwsza opcja wymaga najmniej pisania, ale jest mało elastyczna: nie jesteśmy w stanie zapewnić niczego o wyjątku, jedynie jego klasę. Gdyby przyszła potrzeba upewnienia się, jaki jest komunikat wyjątku, metodę testową trzeba całkowicie przepisać, zmieniając podejście na któreś z opisanych niżej.

Czytaj dalej ExpectedException i pułapki łapania wyjątków w testach