Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-09-15

Channels

#kaocha
<
2022-09-15
>
plexus05:09:07

Some issues on the kaocha repo with more info about what people's needs are would be great. We do have it on our roadmap to provide better monorepo support, see https://github.com/lambdaisland/kaocha/issues/305 This would be fairly simple, a way of detecting tests.edn in nested projects and running the combined set of tests in a single process. No classloader separation which it seems polylith-kaocha does do. So I'm not sure to what extent this generic monorepo support would help polylith. I see only two open issues on polylith-kaocha so I assume that is working fairly well for people? (https://github.com/imrekoszo/polylith-kaocha/issues) Generally speaking any polylith specific stuff should happen in polylith-kaocha, *but* if polylith-kaocha needs certain affordances from kaocha to be able to do its job properly then we are interested in those, especially if they are generic affordances that could support multiple use cases.

Eugen18:09:29

polylith-kaocha does not expose kaocha-cli options. Actually, this is something that IMO would be needed.

Eugen18:09:45

the issue right now is most kaocha cli is private, not exposed interface. This means that if a project wants to integrate kaocha they need to: • A) make their own cli interface - people will need to learn it and they won't be able to reuse kaocha cli knowledge. • B) reimplement kacha CLI and try to follow kaocha - to benefit from existing kaocha cli knowlege. Right now maintenance in case B is quite big IMO

plexus19:09:06

Can you elaborate? There's very little in kaocha that is private. But a cli interface meant for human consumption is not a good fit for building integrations on. That's why we provide kaocha.api. nothing's stopping you from calling kaocha.runner though or shelling out to kaocha.

plexus19:09:09

That top level interface is very hard to reuse. We also have a separate kaocha-boot, because things are different when boot is in charge. It seems it's similar with polylith. It has its own cli tools and own rules.

Eugen19:09:11

nothing more concise right now

Eugen19:09:45

just the fact that I dropped to default test runner on polylith because I had some issues . Default poly test runner is not great either - with regard to features. I hope I get some time to look into this. Poly tooling is not mature on testing side.

imre20:09:44

poly has its own command line tool through which devs interact with it, for example running poly test which, in case of using the p-k integration layer would invoke kaocha through code. I'm not fully up to date on how poly handles extra arguments but I think for people familiar with the kaocha cli it could be useful to be able to call say poly test -- --focus 'my.test.ns' --fail-fast --reporter debug

imre20:09:38

It would help an integration layer like p-k to not have to parse what comes after the --, just pass an arglist to kaocha

imre20:09:08

that way the integration layer wouldn't have to know what args kaocha supports

imre20:09:21

I think polylith-kaocha's only job is to make kaocha accessible through poly test and not much else

imre20:09:22

and so it shouldn't need to understand more about how kaocha works

Eugen21:09:10

thanks @U08BJGV6E for explainig what I could not 🙂

Victor Millan16:09:48

Hi guys, thanks for all the work that you are doing with this project. We are surfacing this issue https://github.com/lambdaisland/kaocha/issues/226 in our project. Should we create a new issue in github? Thanks one more time

plexus18:09:20

I've reopened the ticket. Feel free to add more info if you think you can provide any extra useful information.

imre20:09:26

While working on polylith-kaocha I noticed that kaocha's 3 entry points (cli, -x, repl) seemingly reimplement common functionality with some subtle differences (like cloverage not being usable from repl/run). Because I wanted to support cloverage in p-k I had to again reimplement some of the stuff that -x does. @plexus would there be interest in spending some time refactoring the infrastructure around there so it's perhaps a little more straightforward to call a fully functional kaocha from code without the need to reimplement and without kaocha thinking it's being run directly from the command line?

imre20:09:52

Whether this would potentially be useful anywhere outside of polylith-kaocha, I don't know

imre20:09:50

I'm guessing kaocha was mostly written to serve as a sort of porcelain, not plumbing

plexus04:09:25

It's a policy vs mechanism thing. Kaocha.api is mechanism (plumbing), it allows you to turn a test config into a test result, without caring how you end up with the config. kaocha.runner and kaocha.repl implement different policies about where the config comes from and what is done with the result (they are porcelain). That said there are some common things that could be handled in a middle layer, or in a utility namespace. A proposal for refactoring this is certainly welcome.

plexus04:09:23

-X was added due to popular demand. I still do not see the point of it, and it does mean maintaining another entry point. People should use -m if they can.