Clarification on TestArgs Serialization and Scope (Context from PR #6552)

[Ashutosh0x]

To ensure I learn from this and better understand the codebase, could I ask for some brief clarification on where my analysis was flawed?

Test Discovery Scope: My observation was that discoveredTestClasses in TestModule seemed to be pulling in classes from upstream dependencies, which felt incorrect for a focused test run. Is this behavior intentional (e.g., for test inheritance), or was my diagnosis of the root cause simply incorrect?
Windows Serialization: I encountered TestArgs parsing failures on Windows which appeared to be due to backslash escaping. I assumed upickle defaults were the culprit, but I see JsonFormatters handles os.Path via string conversion. Do you have any pointers on what usually trips people up with Windows paths in this context?
Thanks!

[lefou]

The used classpath is

mill/libs/javalib/src/mill/javalib/TestModule.scala

Lines 36 to 40 in 6e96aa8

	/**
	* The classpath containing the tests. This is most likely the output of the compilation target.
	* By default, this uses the result of [[localRunClasspath]], which is most likely the result of a local compilation.
	*/
	def testClasspath: T[Seq[PathRef]] = Task { localRunClasspath() }

, which is typically wired to the compiled output.

There is also the use case, where a annotated super-class is the only indicator for being a test suite, e.g. LambdaTest is a test library, which provides functional test API, but piggy-backs on JUnit or TestNG. Both frameworks use Java annotations to denote their tests, but the actual LambdaTest test suites don't have any annotations except in their inherited abstract parent classes.