@andrut parametryzacja fikstury - np. masz fiksturę redisa i chcesz wszystkie testy intergracyjne uruchamiać raz pod jedną i raz pod drugą wersją. Parametryzujesz fiksturę wersjami i wszystkie testy używające tej fikstury raz uruchamiają się pod jedną i raz pod drugą.

Zależność fisktur - masz fiksturę bazy danych (nawet w osobnym pakiecie), od której zależy fikstura połączenia do bazy, od której zależą fikstury wsadzające tam dane. Fikstura bazy może być sesyjna (raz na test suite), a fikstura połączenia może być per-test i w teardownie może czyścić bazę.

(W powyższym przykładzie pomijam fiksturę db schemy dla uproszczenia)

Można to rozwiązać prostą kompozycją tak długo jak nie mamy różnych zasięgów - a i wtedy robi się do żmudne, bo nagle gdy komponujemy fiksturę łączenia z bazą (zwraca połączenie) i wsadzania tam danych (zwraca wsadzone dane), to w teście chcemy obie rzeczy. I w efekcie, żeby łatwo to skomponować, wymślamy zależność fisktur.

parametryzacja fikstury - ciekawy przypadek, jak to obecnie rozwiązujecie? zależność fikstur - coś w stylu Component dla fikstur 🙂 może i masz rację, że ma to sens

Nie rozwiązujemy. A jak trzeba, można uciec do uruchamiania testów z ns z różnie zbindowanymi varami.

my takie rzeczy ustawiamy sobie w pliku .edn jak zmieniamy konfigurację w tym pliku, to i testy działają z innymi ustawieniami jest szansa, że troszkę lepsze niż różnie zbindowane vary, no i działa jak dla nas ok jak na razie