Fulcro 3.1.3 on clojars. Makes Inspect more tolerant of crap in your state db, and adds some functions like path-to to the dynamic routing ns, which can be used to keep you code more easily IDE navigable when using dynamic router. See doc strings for more details.

e.g.

(dr/path-to SomeTarget OtherTarget)

["something" "other"]

Thanks @tony.kay

Hi Tony, Is there a way to run a test focused on one behavior block in my deftest ?

not on a behavior block, only at specification level…if you’re using deftest, then you can add ^:focus as metadata on the symbol and use `

(fulcro-spec.reporters.repl/run-tests #(:focus (meta %)))

if using specification, just add :focus after the description string: (specification "a" :focus …)

In IntelliJ I have a Cursive REPL command (see Add REPL Command) that looks like this:

And I set it to a kb shortcut (I have it set to Alt-Shift-F). Then I use this workflow: • Use kb shortcut to move to the ns of my current tests (I have that set to ^C^N) • Use kb shortcut to load that ns (I have that set to ^C^L)

Then I can be in any ns and just press Alt-Sh-F to run those tests

and since I’m using fulcro-spec’s test runner the output comes out as an outline in my REPL

(this is clj/cljc only…cljs test runner is in a browser)

and failures look like this:

this is fantastical magic Tony .. 🧙 .. should I replace term "behavior" with "specification" ( are they essentially synonomous )

so, specification is === deftest

behavior is testing with a bit extra output for the outline

do what you want

🙂

but specification won’t nest well in a specification

The intention of fulcro-spec is of behavioral testing: the top level says what you’re testing, and each behavior (or component) spells out the aspect. The assertions macro supports mixing behavior strings with assertions so that it is a bit less verbose

the above example is what I’d call a “middle-ground” test as far as “ideals”. Ideally each specific behavior would be better-labeled…but there are diminishing returns when doing that. The plus-side is that a failure is easier to comprehend, but I only bother when the assertion itself isn’t particularly obvious….e.g. I could have written:

(assertions
    "user input of 12 means noon"
    (datetime/parse-local-time "12") => (lt/of 12 0)
    "minutes can be input as a single or double digit number."
    (datetime/parse-local-time "12:0") => (lt/of 12 0)
    (datetime/parse-local-time "12:00") => (lt/of 12 0)
    "noon can include a case-insensitive pm indicator"
    (datetime/parse-local-time "12:00 pm") => (lt/of 12 0)
    (datetime/parse-local-time "12:00 Pm") => (lt/of 12 0)
    "pm indicator is allowed when minutes are elided by the user"
    (datetime/parse-local-time "12pm") => (lt/of 12 0)
    (datetime/parse-local-time "12p") => (lt/of 12 0))

which gives a much better error message when there is a regression and my head isn’t in that code:

yes, i use assertions the way you do with string to describe tests and avoid massive behavior blocks .. and this is solid info .. thanks mucho