This workaround alters the classpath scanning logic to only consider classes defined in the first test-classes directory encountered on the classpath to be those defined in 'current module'. It seems that for SBT the heuristic that the current test module classes will be placed in the first test-classes dir on the classpath generally holds. However, if it fails, you may be able to fix test running by overriding _sbtIsClassDefinedInCurrentTestModule or _sbtFindCurrentTestModuleClasspathElement in your tests to suit your needs.
Also fix DistageScalatestTestSuiteRunner#modifyClasspathScan modifier not being applied (it was never applied, ugh...)
This workaround alters the classpath scanning logic to only consider classes defined in the first
test-classesdirectory encountered on the classpath to be those defined in 'current module'. It seems that for SBT the heuristic that the current test module classes will be placed in the firsttest-classesdir on the classpath generally holds. However, if it fails, you may be able to fix test running by overriding_sbtIsClassDefinedInCurrentTestModuleor_sbtFindCurrentTestModuleClasspathElementin your tests to suit your needs.Also fix
DistageScalatestTestSuiteRunner#modifyClasspathScanmodifier not being applied (it was never applied, ugh...)