Haven't tried yet, are you seeing an issue?

Yes, external test runners are broken in a couple of ways as far as I can tell.

I'm working on my test runner to make it compatible with both versions as an interim but @U1G0HH87L is aware of the breakage so it may get fixed.

If it's easy to fix the test runners, to work with both versions, that might be a better option than reverting the changes in poly itself since they are "good" changes...

I have my test runner working with both 0.2.18 and 0.2.19 with minimal changes. Your Kaocha runner uses a different key :projects-to-indirect-changes that has gone away.

FYI: https://github.com/seancorfield/polylith-external-test-runner/commit/a525ae291e56eea30abd82d49dc730dc6a4292dc is the change I made (specifically to components/external-test-runner/src/org/corfield/external_test_runner/core.clj)

Yes, we have two options here. Either, the tool recreates the project-to-xkeys when we execute the test runner (I got that working locally for Sean's test runner, and try to get @imre’s test runner to work), or we decide that this is up to the test runners to support. Both will work. Do you have any opinion about this? When we add support for multiple workspaces, we probably have to introduce a breaking change. The version > :test-runner-api is set to 1.0 today, and can be used to check which version the workspace is in. The poly tool is able to read old workspaces, but will migrate them to the new internal workspace structure (where the :projects key is dropped in :settings).

I'm fine with needing to change the test runner - just be aware that if you change the default test runner at any point, you are likely breaking other people's code at this point.

No changes are needed to 0.2.19 to work with 0.4.0 of my test runner.

The only breakage at this point is the global :test config...

I thought I left the global :test config in :settings, so I need to have a look at that.

I sent https://github.com/polyfy/polylith/pull/426 so there will be a reminder in the code about changing the default test runner create function in future 🙂

> Either, the tool recreates the project-to-xkeys when we execute the test runner ... , or we decide that this is up to the test runners to support If we expect all (most) test runners to need the same project-to-x mappings then I'd probably make the poly tool calculate this rather than making every (most) implementations do the same calculation themselves. That being said it appears my runner only uses project-to-projects-to-test and calculates the -to-bricks itself as the criteria are different

Remind me please as it's been a while I last thought this through: what is (was) project-to-projects-to-test responsible for?

It's a hash map that lives under :changes in the workspace structure (taken from workspace.edn under :projects ) with one key per project (a string) and a vector of projects to test as value. In 0.2.19-SNAPSHOT they have moved to the new key projects-to-test that lives under each project in :projects.

Thanks. And how about projects-to-indirect-changes? same?

The changes of the workspace structure for 0.2.19-SNAPSHOT is documented https://cljdoc.org/d/polylith/clj-poly/0.2.19-SNAPSHOT/doc/versions. Yes.

okay, that actually looks quite logical

previously I had to select the part of those project-to- maps that related to the project under test

Yes, the new structure is an improvement.

good

I'll try and adopt these today

Okay, cool!

@imre I'm curious why the Kaocha runner calculates the bricks to test itself, since those were present in changes before and are present in project now?

Sure. The reason is that the poly tool only considers for testing bricks/projects that have tests in the "test" directory. There are some kaocha plugins that discover tests in src too. One example is the spec-test-check plugin, which runs test.check tests for functions that have s/fdef specs. As the polylith "test" filter happens before execution gets to p-k, some bricks that only have s/fdef but no "test" tests never got to p-k and so kaocha couldn't discover that there are actual specs that could be tested. Here's the explanation I gave back when I made that change: https://github.com/imrekoszo/polylith-kaocha/issues/1#issuecomment-1130505815

The ideal responsibility separation when you use kaocha is that poly determines projects and bricks that are affected by the change and kaocha does test discovery within those projects/bricks, and then runs them

Given :project-to-bricks-to-test (in changes before) and now :bricks-to-test in project, it would seem the test runner has enough information to do that?

project > :paths > :src ? (my test runner only considers project > :paths > :test)

Yeah it looks like I'll have to do one less map lookup going forward

I ought to allow for :src paths to be considered too at some point... but no one has asked for that yet 🙂

Released fix in https://github.com/imrekoszo/polylith-kaocha/releases/tag/v0.8.4

Thanks again for the heads-up, Sean!