This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-16
Channels
- # beginners (144)
- # boot (40)
- # cljsjs (1)
- # cljsrn (30)
- # clojure (190)
- # clojure-india (1)
- # clojure-poland (7)
- # clojure-russia (13)
- # clojure-spec (2)
- # clojurescript (2)
- # component (23)
- # css (6)
- # emacs (3)
- # events (5)
- # garden (4)
- # hoplon (2)
- # jobs-discuss (2)
- # klipse (1)
- # lein-figwheel (1)
- # off-topic (36)
- # re-frame (28)
- # reagent (2)
- # ring (7)
- # ring-swagger (2)
- # rum (3)
- # test-check (4)
- # untangled (4)
@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.