Czas Mavena minął

Aż ciężko uwierzyć, jak mocno ludzie potrafią trzymać się rozwiązań, które kiedyś podbijały rynek i ułatwiały życie, a obecnie są już tylko groteskowym reliktem przeszłości i hamulcem rozwoju. Japończycy cały czas używają faksów, Amerykanie czeków, a programiści Javy — Mavena. Od razu trochę sprostuję, żeby nie być niesprawiedliwym w ocenach: przywiązanie do czeków może nie być takie złe, bo zapewne nie pozwala na społeczne wykluczenie ludzi, którzy mają kłopoty z nauczeniem się korzystania z komputerów lub są zbyt biedni, żeby z łatwo z nich korzystać. Skupmy się jednak na programowaniu.

Czytaj dalej Czas Mavena minął

Funkcyjna obsługa błędów w Kotlinie i Javie

Czasem obsługa błędów jest prosta, „zerojedynkowa”: albo operacja się powiedzie, albo rzuci wyjątkiem. Mamy jednak też sytuacje, gdy od strony biznesowej podejście „wszystko albo nic” nie ma sensu i oczekiwane jest działanie w trybie „best effort”. Na wejściu jest zestaw danych, wykonujemy na nich operacje, jeśli w trakcie pojawiają się błędy, to po prostu idziemy dalej i próbujemy doprowadzić do końca tak wiele, jak się da, nie wycofując się z niczego. Nie mówimy o beztroskim ignorowaniu błędów: nawet jeśli zgadzamy się na częściowe niepowodzenie, dobrze jest wiedzieć, które z danych były przetworzone pomyślnie, a które z błędem. Jak zaprogramować takie podejście w sposób czytelny i jasno przekazujący intencję?

Imperatywne podejście (try-catch) w naturalny sposób modeluje sytuację zerojedynkową. Żeby zamodelować wersję „best effort” musimy myśleć w sposób bardziej funkcyjny, potraktować zarówno operację do wykonania jak i błąd jako byty na równi z danymi. Będziemy „kolekcjonować” błędy, żeby móc później zanalizować, ile ich było.

Języki nastawione na programowanie funkcyjne ułatwiają tu sprawę, ponieważ mają sprawdzone i dobrze opisane rozwiązania. Przykładowo Scala ma w bibliotece standardowej typ Try. Kotlin i Java nie są językami tradycyjnie wykorzystywanymi w sposób funkcyjny — nie oznacza to, że nie da się działać w nich w analogiczny sposób, jedynie to, że może być trudno znaleźć odpowiedź, jak do tego podejść.

Czytaj dalej Funkcyjna obsługa błędów w Kotlinie i Javie

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

Importy nieprzerywające pracy w IntelliJ

Do niedawna nienawidziłem przeklejania kodu do IDE. Nie dlatego, żebym uważał, że prawdziwemu programiście nie wypada robić copy-paste ze Stack Overflow (to bzdura). Cierpiałem na samą myśl, że będę musiał dodać importy do wszystkich użytych w tym fragmencie klas, ponieważ normalnie w IntelliJ jest to niewygodne. Dobra wiadomość: istnieje wbudowana opcja, która pozwala ułatwić sobie życie — ale domyślnie jest wyłączona. W dalszej części pokażę, jak ustawić swoje IDE do wydajnej pracy z importami. Na samym końcu będzie krótka dygresja o modelach mentalnych dla programistów.

Czytaj dalej Importy nieprzerywające pracy w IntelliJ

Niebezpieczny isEmpty() z utili Springa

Wyobraźmy sobie, że znajdujemy w projekcie taki kod w Javie (lub prawie identyczny — w Kotlinie):

public void assertNoViolations(Collection<ConstraintViolation> violations) {
    if (!isEmpty(violations)) {
        throw new IllegalStateException("violates constraints: " + violations);
    }
}

Na oko — kod jak kod, robi co trzeba, nuda. Co może pójść nie tak?

Metoda zgodnie z oczekiwaniami bezproblemowo akceptuje nulla. Rzuca wyjątkiem, gdy przekażemy jej listę zawierającą contraint violations. Jest jeden szkopuł:

assertNoViolations(emptyList());
java.lang.IllegalStateException: violates constraints: []

Jak to jest możliwe?

Czytaj dalej Niebezpieczny isEmpty() z utili Springa

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