Fork me on GitHub
#kaocha
<
2022-03-19
>
javahippie20:03:51

Hey! I am currently exploring if it makes sense to write a kaocha plugin for our Clojure Testcontainers wrapper (https://github.com/javahippie/clj-test-containers) , so we can initialize defined Docker images either before all tests or before every test. The documentation on extending kaocha is amazing and made writing the plugin really easy. But currently I am stuck on two questions: • Is it possible to run a plugin only with a certain test id, e.g. for all :integration tests, but not :unit? Or would I have to apply a similar :ns-patterns config in my plugin configuration? • I have to manage the state somehow, and I’d like to provide the possibility to create new Docker containers per test and an easy way to access them. I think that working with bindings would be nice, and a naive way to achieve this would be to wrap the function associated with :kaocha.var/test in the pre-test step with my own function to set the bindings. Are there reasons to not do this, that I can’t see right now? Or would there be a better, more elegant way to achieve this?

javahippie20:03:16

And the tests.edn looks like this

plexus22:03:18

there's a specific affordance for the wrapping of the test function, this may not be really well documented. I found this in the changelog: > • Testable now has an optional :kaocha.var/wrap key, which can contain a seq > of functions that will be used to "wrap" the actual test function, useful e.g. > for providing bindings. clojure.test style :each fixtures are also handled > through this key, so plugins can choose to add wrapping functions at the start > or the end of this seq to wrap "inside" or "around" the fixtures.

plexus22:03:03

> Is it possible to run a plugin only with a certain test id We don't have anything like that, a plugin stack/chain is always active for the complete test run. This has come up before, the challenge is that not all plugin hooks pertain to a specific testable or suite. That said you should have all the context available to figure out what's executing. E.g. you can have people add a :your.ns/test-containers? true on the suite and check for that.

plexus22:03:47

Cool intiative BTW, I was chatting with someone about testcontainers just yesterday. Gotta pick more good ideas from the java folks 🙂

javahippie22:03:25

> there’s a specific affordance for the wrapping of the test function, this may not be really well documented. I found this in the changelog: That’s what I was looking for, thanks!

javahippie22:03:02

> E.g. you can have people add a :your.ns/test-containers? true on the suite and check for that. Thats ~ what I was planning to do, thanks for the confirmation!

javahippie22:03:46

> Cool intiative BTW, I was chatting with someone about testcontainers just yesterday. Gotta pick more good ideas from the java folks 🙂 They have some stuff that has merit 😉

javahippie07:03:49

Just as an addition, the key :kaocha.var/wrap was renamed to :kaocha.testable/wrap in a later commit

plexus10:03:59

right, makes sense. kaocha.var is very clojure.test specific. If you like you can go ahead and add a mention of kaocha.testable/wrap to the extension docs. That would be mightily appreciated!

javahippie11:03:40

It is briefly mentioned at https://github.com/lambdaisland/kaocha/blob/main/doc/09_extending.md#tips-for-developing-test-types but I’d be happy to write something in a little more detail, will try and do so in the next days