Obviously, I could do more mocking, and I could still write independent tests that do the auth part and the api part separately to check data at the boundaries -- but a cross-project flow test would be the simplest and most "accurate" in terms of real-world tests. I could spin the fixtures out into test-only components -- we've already done that with our core "application" fixtures -- and then have, say, the api base depend on the auth-fixtures component for testing. Is that a good use of components, purely to test across projects/bases? I sort of lean, in my mind, toward an integration project that depends on both bases with its own tests that use both sets of fixtures but I'm not sure Polylith would even let me do that.

What do folks do for such integration tests that need to run across multiple projects/`bases` like this?

Background: We have a polylith-inspired monorepo without actually using polylith (our homegrown thing was built ground-up on deps.edn when polylith was still using lein+symbolic links). We found it useful to have components that provide only test-related functionality and projects that are solely test-specific (ie. a separate project built specifically for writing integration tests that interact between multiple bases). It improves cohesion of the system and gives a nice separate place to put your e2e tests. Reminds a little of the OOP problem of "I have a method that interacts with both class A and B, but is not really a good fit to implement directly as A.foo(B) or B.foo(A)" vs CLOS style multimethods "this is separate from A or B, but needs both for interaction" Just throwing it out there as one anecdotal 👍 for this approach.

Currently all my int tests are in one project. This isn't ideal because this project also needs to CDK to AWS, as well as manage docker containers for local testing etc, as well as managing client int test code (multiple jobs). At a previous company I worked at I really liked the way that services were docker-composed for testing with associated mock and real end points in ancillary services. If I find myself getting to that point, then some projects (int tests) will have to depend on other projects (to produce the docker images). I'm not at that point yet so, it's a problem for later... and it's possible I'll choose a different direction.