Ostatnio było o tym, jak spowodować, że nasz stary skryptowy pierdolnik był bardziej stabilny i przewidywalny. No super, to może pobawmy się bardziej procesem testowania i rozważeniem dostępnych opcji związanych z testowaniem skryptów.
Co wybrać i dlaczego?
Popularne frameworki do testowania skryptów powłoki
Poniżej znajduje się zestawienie kilku najpopularniejszych frameworków i narzędzi służących do testowania skryptów powłoki, wraz z krótkim omówieniem i porównaniem ich głównych cech.
1. Bats (Bash Automated Testing System)
Opis
- Bats to jeden z najczęściej używanych frameworków do testowania skryptów Bash.
- Pozwala pisać testy w sposób przypominający testy jednostkowe w językach wysokiego poziomu (np. w Pythonie, Javie).
- Każdy test to osobna funkcja rozpoczynająca się od słowa
test_, w której korzysta się z asercji. - Bats jest łatwy w konfiguracji i użytkowaniu, a wyniki testów pokazywane są w przyjaznej formie (PASSED/FAILED).
Zalety
- Dobra dokumentacja i duże wsparcie społeczności.
- Prosta składnia pozwala szybko rozpocząć pisanie testów.
- Logi i wyniki testów prezentowane są w czytelnej formie.
- Łatwa integracja z systemami CI/CD.
Wady
- Skupia się głównie na Bashu – jeśli nasze skrypty muszą działać w różnych powłokach (sh, zsh itp.), może to być ograniczenie.
- Rozszerzenia czy pluginy do bardziej zaawansowanych zastosowań wymagają dodatkowych narzędzi bądź forka (np. bats-core).
Link
2. shUnit2
Opis
- Lekki framework do testowania skryptów w POSIX shell (może działać z Bash, Dash, Zsh itd.).
- Inspiruje się popularnym stylem xUnit, stąd nazwa (shUnit2).
- Testy pisane są w postaci funkcji
testNazwa, a asercje dostępne są za pomocą wbudowanych funkcji (np.assertEquals,assertTrueitp.).
Zalety
- Działa w wielu powłokach, co bywa przydatne przy testowaniu skryptów, które muszą być przenośne.
- Struktura testów jest przejrzysta i wzorowana na xUnit, więc dość intuicyjna.
- Posiada wbudowane funkcje asercji i raportuje wyniki testów w standaryzowany sposób.
Wady
- Mniej „przyjazny” format wyników w porównaniu z Bats (choć wciąż czytelny).
- Nie jest aż tak popularny jak Bats – mniej przykładów w sieci i mniejsza społeczność, choć wciąż wystarczająca.
Link
3. ShellSpec
Opis
- ShellSpec to framework do testów w stylu BDD (Behavior-Driven Development) dla skryptów shellowych (POSIX/Bash).
- Umożliwia pisanie testów w formie
Describe/Iti używania asercji w stylu „should equal”, „should match” itp. - Pozwala na tworzenie bardziej opisowych scenariuszy testowych.
Zalety
- BDD może być bardziej czytelne dla osób nietechnicznych (testy w formie scenariuszy).
- Obsługuje różne powłoki, w tym POSIX shell, Bash, Dash, Zsh.
- Daje możliwość integracji z CI/CD i generowania raportów w różnych formatach (np. JUnit XML).
Wady
- Mniejsza popularność niż Bats i mniejsza społeczność (choć nadal rośnie).
- Dla niektórych składnia BDD może być mniej intuicyjna, jeśli przyzwyczajeni są do klasycznego stylu xUnit.
Link
4. zUnit
Opis
- zUnit to framework testowy przeznaczony głównie do Zsh, choć może działać też w innych powłokach (z ograniczeniami).
- Również inspirowany konwencją xUnit.
- Umożliwia integrację z takimi narzędziami jak Docker, Jenkins czy Travis CI.
Zalety
- Dobrze integruje się z Zsh i potrafi wykorzystać jej specyficzne funkcjonalności.
- Czytelna składnia, podobna do xUnit.
- Możliwe równoległe uruchamianie testów w niektórych konfiguracjach.
Wady
- Mniej uniwersalny – nastawiony przede wszystkim na Zsh, co może ograniczać przenośność testów.
- Mniejsza społeczność i dokumentacja w porównaniu z Bats i shUnit2.
Link
5. Shpec
Opis
- Narzędzie testowe w stylu BDD podobne do RSpec (z Ruby).
- Skupia się na prostocie składni: testy piszemy w blokach
describe,itoraz używamyassert/expect. - Domyślnie działa w Bash, ale dość łatwo uruchomić go też w innych powłokach.
Zalety
- BDD-owy styl testów bywa bardziej czytelny i opisowy.
- Szybka konfiguracja i prostota użytkowania.
- Dobry wybór, jeśli zależy nam na prostych testach w stylu „Spec”.
Wady
- Mniejsza popularność niż Bats czy shUnit2, przez co wsparcie społeczności jest bardziej ograniczone.
- Niekiedy brakuje rozbudowanych przykładów czy tutoriali.
Link
Porównanie w pigułce
| Nazwa | Główna powłoka | Styl testów | Popularność (społeczność) | Łatwość nauki | Integracja CI/CD | Główne zalety | Potencjalne wady |
|---|---|---|---|---|---|---|---|
| Bats | Bash | xUnit | Bardzo duża | Wysoka | Łatwa (plug & play) | Prosta składnia, czytelne wyniki, duże wsparcie | Dedykowany głównie Bash, mniejsza elastyczność |
| shUnit2 | POSIX shell (wiele) | xUnit | Średnia | Średnia | Łatwa | Uniwersalność wielu powłok, struktura xUnit | Mniej „przyjazny” output, ograniczona liczba przykładów |
| ShellSpec | POSIX/Bash | BDD | Średnia/rośnie | Średnia | Łatwa | Styl BDD, wsparcie wielu powłok, rozbudowane asercje | Mniejsza społeczność, nieco bardziej rozbudowana konfiguracja |
| zUnit | Zsh | xUnit | Niewielka | Średnia | Łatwa | Integracja z Zsh i jej funkcjonalności | Mniejsza popularność, mocne powiązanie z Zsh |
| Shpec | Bash (pozostałe z pewnym nakładem) | BDD | Niewielka | Wysoka | Łatwa | Prosty styl RSpec, minimalizm | Mniejsza społeczność, ograniczona dokumentacja |
Dodatkowe narzędzia wspierające testowanie i jakość skryptów
- ShellCheck – narzędzie do statycznej analizy kodu powłoki. Nie jest to framework testowy, ale bardzo przydatne do wychwytywania błędów składniowych i potencjalnych błędów logicznych (np. niezainicjowane zmienne).
- shellcheck-action (GitHub Action) – integracja ShellCheck z GitHub Actions, przydatna w CI/CD.
Podsumowanie
- Bats (lub bardziej rozwijany bats-core) pozostaje najpopularniejszym rozwiązaniem do testowania skryptów w Bashu. Prosta składnia, duża społeczność oraz łatwa integracja sprawiają, że jest to najczęstszy wybór.
- Jeżeli potrzebujesz testów przenośnych między różnymi powłokami, rozważ shUnit2, który jest bardziej zorientowany na POSIX.
- Jeśli preferujesz podejście BDD i bardziej opisowe testy, ShellSpec będzie dobrą opcją – obsługuje kilka powłok i ma przyjemną składnię BDD.
- zUnit to opcja, gdy pracujesz przede wszystkim w Zsh i chcesz wykorzystać jej specyficzne funkcjonalności.
- Shpec jest ciekawą alternatywą w stylu BDD, lecz ma mniejszą społeczność i jest nieco mniej elastyczny od ShellSpec.
Dobór frameworka zależy więc od:
- Wymagań co do przenośności (czy testy mają działać w różnych powłokach, czy wystarczy Bash/Zsh).
- Preferencji stylistycznych (xUnit vs BDD).
- Dostępności wsparcia i przykładowych testów (co często przekłada się na czas nauki).
- Integracji z istniejącymi narzędziami CI/CD.
Najbezpieczniejszym wyborem „na start” zazwyczaj jest Bats, głównie ze względu na mnogość przykładów, popularność i prostą składnię. Jeśli jednak Twoje skrypty muszą działać w środowiskach z różnymi powłokami (szczególnie w minimalistycznych Dockerach opartych o Dash), rozważ shUnit2 lub ShellSpec.