DevCezz

Programistyczny blog dla Ciebie

Biblioteka testowa Spock a IntelliJ
Testy

Biblioteka testowa Spock a IntelliJ

Spock według mnie jest naprawdę dobrą alternatywą dla JUnit oraz TestNG. Wyróżnia go fakt, że jest to testowy framework oparty o język Groovy. Dzięki temu może on wykorzystywać jego wyraziste konstrukcje językowe do pisaniu testów jak np. nazwy metod w cudzysłowach czy podwójny znak mniejszości '<<’, aby dodać elementy do kolekcji. Jednak pomimo tak wielu korzyści zawsze znajdzie się coś na co można trochę ponarzekać. W przypadku tego artykułu jest to połączenie Spocka z IntelliJ. Czasem ta para ze sobą nie współgra tak jakby można było się tego spodziewać.

EDIT: Dzięki komentarzowi użytkownika kcybulski wiadomo jak ustawić wcięcia dla linii kodu pod etykietami w Groovy. Trzeba zmienić następującą opcję w Intellij: „Editor -> Code Style -> Groovy -> Tabs and Indents -> Label indent: 4„.

Open Source at Exception

Pierwszym przypadkiem jest niedziałająca opcja „Open Source at Exception”, której zadaniem jest przeniesienie nas w kodzie testu do miejsca, gdzie nie przeszła asercja. Dla JUnit działa to jak należy, natomiast w Spock już niekoniecznie. Ta opcja wydaje się być po prostu wygodna w przypadku, gdy kod danej metody testowej znacznie się rozrośnie i będzie posiadał sporo asercji.

Po podwójnym kliknięciu na test, który nie przeszedł w przypadku JUnit zostaniemy przeniesieni do błędnej asercji. Natomiast w Spock kursor nakieruje się na nazwę metody testowej. Na platformie YouTrack od JetBrains może sprawdzić, że istnieje już taki błąd od roku.

Brak wsparcia formatowania dla podzielonej tabeli danych

Czasami wiele parametrów jest od siebie zależnych i nie chcielibyśmy pisać wielu metod testowych o takim samym ciele. Z tego powodu stosujemy testy parametryzowane i muszę przyznać, że w Spock ich implementacja jest naprawdę wygodna. Piszemy po prostu sekcję where w ramach tej samej metody i podajemy tabelę danych rozdzielając je przez '|’ lub ’;’. Czasami jednak tych kolumn jest tak dużo, że chcielibyśmy ją podzielić. Oczywiście jest to jak najbardziej możliwe, ale gorzej już z automatycznym formatowaniem takiej tabeli.

Po naciśnięciu kombinacji Ctrl+Alt+L jak można zauważyć druga część tabeli pozostała nienaruszona. Ten błąd jest na pewno irytujący, ponieważ czasami trzeba formatować ręcznie sporą ilość kodu. Oczywiście go również znajdziemy na YouTrack, powstał on 2 miesiące temu.

Dla mnie osobiście powinno się robić jeszcze formatowanie w taki sposób, aby wszystkie linijki pod słowami takimi jak given, when, then, where itd. wyszły o jeden tabulator dalej. W ten sposób każda z sekcji byłaby widoczna na pierwszy rzut oka. Próbowałem z tym walczyć, ale przy każdym formatowaniu automatycznym moja praca szła na marne. To jest tylko jednak moje osobiste odczucie i nie utrudnia pracy.

Zmiana nazwy zmiennej a literał w @Unroll

Po napisaniu kawałka kodu praktycznie w 100% wiemy, że dane nazwy zmiennych się zmienią. Nie inaczej ma się to w przypadku kodu metod testowych. W Spock istnieje adnotacja @Unroll, której zadaniem jest uznanie każdego przypadku z parametryzowanego testu jako osobnego testu. Ma to głównie znaczenie przy tworzeniu raportu. Łącząc te dwa zagadnienia dostaniemy problem przedstawiony na poniższej grafice.

Obydwa sposoby użycia @Unroll są prawidłowe. Jednak w przypadku wykorzystania adnotacji bez literału oraz użycia nazw zmiennych w nazwie metody, gdy zrefaktoryzujemy je w kodzie to nie ulegną one zmianie. Natomiast przy zwykłej nazwie metody, a parametryzacji nazwy metody w @Unroll wszystko zadziała prawidłowo. Ten błąd również znajduje się na w sferze problemów od 9 lat z aktualizacją sprzed roku w lutym.

Podsumowanie

Wyżej wymienione błędy nie są krytyczne, ale potrafią być uciążliwe. Sam Spock to naprawdę dobry framework do testowania i stanowi świetną alternatywę dla pisania testów w samej Javie. Oczywiście są też takie uciążliwości jak brak błędu, gdy dana klasa nie ma konstruktora z wybranymi parametrami, a my chcemy go przez przypadek użyć. Dostaniemy tylko ostrzeżenie, które podświetli nam problematyczny fragment kodu na żółto, a testy i tak się uruchomią. Oczywiście ten przypadek testowy nie przejdzie i dopiero w logach dostaniemy informacje o błędzie kompilacji. Jednak ten problem to po prostu pokłosie wykorzystania skryptowego języka Groovy i ciężko winić za to Spocka. Nie zmienia to faktu, że pisanie testów w ten sposób jest utrudnione.

Oczywiście możemy również dostać się w teście do prywatnych pól danego obiektu i je nadpisywać. IntelliJ również nas poinformuje o tym poprzez wyróżnienie danego wywołania żółtą poświatą. Jednak okazuje się, że to jest poważny błąd języka Groovy samego w sobie:

Jestem ciekaw czy Ty również wykorzystujesz Spocka do testów w pracy i również napotkałeś bądź napotkałaś problemy z nim związane. Podziel się swoim doświadczeniem w komentarzu.

Podziel się tym z innymi!

2 KOMENTARZE

  1. „…wyszły o jeden tabulator dalej”
    Editor -> Code Style -> Groovy -> Tabs and Indents -> Label indent: 4

Możliwość komentowania została wyłączona.