Человеки, а нужен кому билет на EuroClojure, который через пару дней начинается?

привет можете подсказать про организацию тестов в cljs есть какое-то чувство того, что что-то не так идет 1) для набора тестов нужен общий контекст - общие "переменные" 2) есть однотипные проверки компонентов, которые я вынес в функции 3) в cljs получается много deftest, т.к. async done можно только один раз вызвать 4) перед let нужно комментарий писать, иначе не понятно, что это за группа тестов https://github.com/darkleaf/form/blob/master/test/darkleaf/form/bootstrap4_test.cljs#L91 вроде все разбито на функции, но есть сомнения 😃

https://clojuredocs.org/clojure.test/use-fixtures я обычно для создания и изоляции контекста фикстуры создаю, они через compose-fixtures делают тестовую кодобазу сильно чище

это по факту тот же let, но все же выглядит приятнее

вместо комментов можно использовать testing https://clojure.github.io/clojure/clojure.test-api.html#clojure.test/testing

а есть пример с use-fixtures?

я их тоже использую, что бы создать контейнер, куда компонент рендерить

FIXTURES

Fixtures allow you to run code before and after tests, to set up
the context in which tests should be run.

A fixture is just a function that calls another function passed as
an argument.  It looks like this:

(defn my-fixture [f]
   Perform setup, establish bindings, whatever.
  (f)  Then call the function we were passed.
   Tear-down / clean-up code here.
 )

Fixtures are attached to namespaces in one of two ways.  "each"
fixtures are run repeatedly, once for each test function created
with "deftest" or "with-test".  "each" fixtures are useful for
establishing a consistent before/after state for each test, like
clearing out database tables.

"each" fixtures can be attached to the current namespace like this:
(use-fixtures :each fixture1 fixture2 ...)
The fixture1, fixture2 are just functions like the example above.
They can also be anonymous functions, like this:
(use-fixtures :each (fn [f] setup... (f) cleanup...))

The other kind of fixture, a "once" fixture, is only run once,
around ALL the tests in the namespace.  "once" fixtures are useful
for tasks that only need to be performed once, like establishing
database connections, or for time-consuming tasks.

Attach "once" fixtures to the current namespace like this:
(use-fixtures :once fixture1 fixture2 ...)

Note: Fixtures and test-ns-hook are mutually incompatible.  If you
are using test-ns-hook, fixture functions will *never* be run.

это все понятно непонятно как разные фистуры вешать на разные тесты и как делать binding, через dynamic?

например через dynamic, а насчет “разные фикстуры на разные тесты” - я стараюсь создавать новый нэймспейс для тестов на каждую комбинацию контекста и внутри него использовать (use-fixtures :each ...)

получается немного многословно, но проще в поддержке кмк, потому что не приходится задумываться о том как выглядит окружение для конкретно того теста на который я смотрю

но это имхо, конечно же

может еще какие-то примеры есть, в опенсорсе?

сходу не могу вспомнить, но если что-то попадется - скину

State Design Pattern

Intent

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
An object-oriented state machine
wrapper + polymorphic wrappee + collaboration

а кто-нибудь Arcadia щупал?

But don’t let the fancy name ("guard") and the concise UML notation fool you. When you actually code an extended state machine, the guards become the same IFs and ELSEs that you wanted to eliminate by using the state machine in the first place. Too many of them, and you’ll find yourself back in square one ("spaghetti code"), where the guards effectively take over handling of all the relevant conditions in the system.