About running too many tests, unfortunately there's no out of the box solution here. The only way I saw it happening was through a scripted pipeline. I really hope to be wrong here, and happy to investigate Gradle and TeamCity deeper in this sense.
I’ve started work on this, I ran some tests over the weekend whilst TeamCity was quiet. I bumped gradle to the latest version and enabled failFast, the next step is to force a test to fail on the branch early on to see if it works.
The next step after that is to enable parallel compilation, force a bunch of runs and see if that’s reliable.
Then the next step after that is to enable parallel execution of the unit tests (but not integration tests). Again, run 20 times in a row or something like that, see if any flakes appear.
The goal should be thoughroughly testing adapters e.g., the Hibernate-based implementation of a Vault interface in isolation, and then replace it with an in memory closure in all other tests.
Yes for unit tests (integration tests need to stay testing the integration of things of course!). But isn’t that what we’re both agreeing on? MockNetwork customises MockNode via sub-classing rather than changing what’s passed to a constructor (at least partly), but that’s not a very important detail.