[rant] Runner.addCases is a trap

[Simn]

So you can use addCase to add an individual case, cool. Naturally, you'd expect its plural version, addCases, to add multiple cases. Probably accepting an array as argument, right?

But it does something completely different. It's actually a macro which does something with package paths. The problem here is that runner.addCases(classes) type-checks without a problem, it just won't do anything unless you happen to have a classes package somewhere.

I don't really know why I'm opening this issue.

[RealyUniqueName]

But it has a doc with explanation :)

But ok. Can anyone suggest a better name? addCasesInPackages?

[Gama11]

Couldn't it just error in case no tests were added (in which case the user probably tried to pass something in that isn't a package)?

FWIW, I've also tried to use this method before and it didn't behave as I would've expected, although in a different way. I'm honestly not quite sure what's going on here:

[Simn]

IMO this entire functionality is out-of-scope in the Runner class...

[saem]

Adding another point of view, this doesn't work at all like I expected when I just tried to use it.

My expectation was that I gave it a path/package and it should go spelunking and find all classes that extend Test or implement ITest. Instead it threw an error as it tried to instantiate non-test classes.

I imagine due to various macro phases this is all very tricky, but ideally it should take a path and a filter predicate function and then properly discover and add actual tests. A non-recursive variety should simply have a different name.

I tried to figure if I could do the auto-discovery in my project, but I'm rather new and not yet comfortable enough with the macro system to even know if this is feasible.

Nonetheless, the library is super straightforward otherwise and it's pretty nice to use, thanks!

[cedx]

Same issue as @Gama11 here: I always get the Unexpected import error when I try to use Runner.addCases().

Haxe: 4.1.1 (x64) on Windows 10.
UTest: 1.10.3