Clojurians Log v2

@braden.shepherdson you should be able to do this with hooks

or a custom plugin, but hooks are probably good enough

it's a little tricky in this case, since most hooks are before/after, rather than wrap-around. We only have wrap-run, but that one has the downside that it doesn't explicitly receive the current testable or test-plan, so you'll have to make use of kaocha.testable/*current-testable*, and kaocha.testable/*test-plan* to determine whether the test that is being run belongs to a specific suite. Might be easier to use pre-test/`post-test`, and instead of binding use the lower level push-thread-bindings / pop-thread-bindings

pseudocode:

(ns my.kaocha.hooks)

(defn pre-test [test test-plan]
  (when (= :some.specific.suite (:kaocha.testable/id test))
    (push-thread-bindings {...}))
  test)

(defn post-test [test test-plan]
  (when (= :some.specific.suite (:kaocha.testable/id test))
    (pop-thread-bindings {...}))
  test)

#kaocha/v1
{:plugins [:hooks]
 :kaocha.hooks/pre-test [my.kaocha.hooks/pre-test]
 :kaocha.hooks/post-test [my.kaocha.hooks/post-test]

 }

Hi, I am Urwashi, teammate of @rmailbox1004. Looking forward to contributing to the project.

Hello! Welcome! Im there as one of the coaches for Bits&Bytes 😄 Happy hacking!

Yes, Thanks for being our coach.

Hi @urwashipriya2016! Welcome to Kaocha and good luck with your application!

Hello @everyone,

This Danjela, a Rails Girls Summer of Code Applicant who is looking for a coach. If anyone is interested in coaching, please feel free to reach out to me.

I'm based in Tirana, Albania at the moment

hi Danjela! 👋:skin-tone-2: welcome to #kaocha!

@plexus ah, looks sensible. I'm actually fine with having a separate suite and separate deps.edn alias for each backend, so I'm not worried about running kaocha once and hitting all the backends. that might simplify things.

I'll try it shortly. I see you're UTC+2 while I'm -4, so I'll try this shortly in case I get stuck.

I'm having classpath problems with the hooks being able to access the var that needs changing. where should the hooks live?

okay, I got it working using (ns-resolve), and it can see the var's (nonsense) default value. after push-thread-bindings dereferencing the var gives the new value. but then when the test actually runs, it's back to the default value.

(I'm using kaocha-midje, in case that changes up the system somehow)

even replacing the dynamic var with an atom and reset!ing it doesn't work. that leads me to wonder if there's something strange going on with the Midje runner, and the hooks are running in a different universe altogether from the tests.

it's worth mentioning that while running with kaocha-midje and --watch it seems like there's two test environments - the real one and an empty one. perhaps I'm running my hooks in the empty one somehow?