Using testOnly with multiple matches results in multiple shared resource instantiations

[ssahayam-zd]

Hi,

I followed the recommendations for using testOnly as per Regarding "testOnly" build tool commands which works as expected when testOnly matches a single test.

For example:

sbt testOnly *VerySpecificSuite

if however, I run testOnly with a slightly broader search as as:

sbt testOnly *SomeCommonPrefixSuite

then I can see that the shared resource used across these Suites is instantiated multiple times.

I have a small sample repo that highlights the problem.

I am not sure if I am using this feature incorrectly or whether this is a bug/feature.

Thanks!

[Baccata]

First of all, thank you for writing such a great issue, with a repro, this is great 😄

I'm sorry to say it's a user error. We have a note in the docs you linked :

pass your GlobalResource implementations to the testOnly command, alongside the suite you really want to run

So you need

sbt testOnly *SharingSuite SharedResource

When you do

sbt testOnly *SharingSuite

the SharedResource class is not matched by the glob pattern, so it doesn't get passed to weaver by SBT, which means that you always hit the case None => baseResources here, which means that the resource gets recreated by the suite.

The thing with shared resources objects in weaver is that they are essentially considered as a test suite by the build tool, so when you call testOnly, you need to ensure they are passed, otherwise weaver has no way of knowing that they exist.

[ssahayam-zd]

First of all, thank you for writing such a great issue, with a repro, this is great 😄

Thanks! 😄

Also glad this is not a bug! 😅

It looks like you need the full package path to the shared resource when running it through testOnly:

testOnly *SharingSuite acme.weaverissue.SharedResources

I'm happy to submit a PR updating the docs with a simple example as above.

[keynmol]

This seems like it can be closed, reopen if I'm misreading it :)