Clojurians Log v2

i see that at least one person has written a custom reporter for lazytest, which means i now cannot change the format of the reporters system. this makes me nervous about hooks lol

let me bounce some ideas off y'all, see how it feels to write out

(taking a break from my $DAYJOB to think about this lol)

Currently, the runner takes in a single suite and then recurses over it with the run-tree multimethod. for each suite, it produces a suite-result, a map with :type :lazyteset.suite/suite-result, docs, and then :source and :children, where :source is the given suite that was run, and :children are the results of the recursive calls (other suite results or test case results). for each test case, it produces a test-case-result with :source (the given test case) and other relevant details

this creates a nice map of {:type :lazytest.suite/suite-result :source ... :children [...]} etc that can be iterated over to find all of the suites and test cases and other pieces

the pre and post hooks for each of these are keyed to the input suite/test case and then the suite/test case result object:

(defmethod run-tree :lazytest/ns
  run-test--lazytest-ns
  [suite config]
  (let [suite (hooks/run-hooks config suite :pre-test-suite)]
    (report config (assoc suite :type :begin-test-ns))
    (run-befores suite)
    (let [results (->suite-result suite config :lazytest/ns)]
      (report config (-> suite
                       (assoc :type :end-test-ns)
                       (assoc :results results)))
      (run-afters suite)
      (hooks/run-hooks config results :post-test-suite))))

comparatively, pre reporters take the base object, and then post reporters take the base object plus a :results key, holding the results (which also holds the :source and :children)

so the two objects are going to be different on output, which i find ugly, but i'm not sure there's a better way to do it?

if i'd thought ahead, i might have changed the post- reporters to take the results object with its :source and :children directly instead of nesting it

but the symmetry seemed worthwhile when i first wrote them (probably mirroring clojure.test)

Just so I'm understanding: run-hooks with :pre-test-suite gets a suite hash map, but run-hooks with :post-test-suite gets a results hash map where the suite is under :source? But report gets the suite hash map in both cases (`:begin-test-ns` and :end-test-ns), but in the second case, it also has :results with the results object in it?

lol yes 😵‍💫

with report, the results object is the same object that's passed to run-hooks (so it has suite under :source), it's just that extra layering that bothers me

maybe this is just how it is and we're stuck with it lol

i'd like for the post- hooks to take the result object and either modify or return it. it's the simplest, most obvious way for a hook function to operate: it takes a result and returns a result, no nesting or destructuring required, no docs that say "you must update the :result object, any other changes will be discarded"

one way to thread this needle would be to assoc results onto the results itself, lol: results (assoc results :results results). then existing custom reporters wouldn't need to change (they're most likely only using :results), and now the signature of both reporters and hooks would be the same: :pre-/`:before-` gets the source hashmap, :post-/`:after-` gets the results with source hashmap under :source.

Would assoc'ing results into itself likely to cause a usability problem for folks debugging hooks, since the whole of results is then duplicated into itself?

What is the suite hash map? What keys does that have?

yeah, the size of these objects is incredibly unwieldy already, the run and ns objects hold a lot of stuff

I've defined suite as a record with (defrecord Suite [type doc source children context ns file line var metadata]) but it of course can hold arbitrary data as well

i think i will have to stick with what i have. in changing the reporter to use results as a base, a number of tests broke in non-obvious ways, and i suspect that there are other users of the current format I'm not acocunting for

the messiness will just have to exist, until at some point i change to v2, maybe with a whole new library name lol