Fork me on GitHub

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.

❤️ 36
👏 24
👍 8


(dr/path-to SomeTarget OtherTarget)
instead of
["something" "other"]


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:

    "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