[Maybe] Whitebox test fixtures

[xenoterracide]

So working on the mockito thing, I was hoping to wholesale move some code from one test package into a blackbox test. However it seems that much of their testing code is using their internal package which shouldn't be exported.

So what might be nice is a way to have test-fixtures that could access the unexported packages in the main module and then use those test fixtures in either whitebox/blackbox testing. so internal package wouldn't be available in the blackbox test, but would be available to the test fixtures.

[xenoterracide]

I've encountered this again, but the difference is that I'm looking at wanting to use package protected methods in my fixtures which would be the real world use case (they don't need to be public, and only are for testing), instead it has to reside in a different package and so I can't use these

[jjohannes]

I understand the idea, but I am not sure how that can be implemented. It sounds like it breaks the encapsulation the Module System wants to enforce on multiple levels. Therefore I wonder if it is the right approach.
Maybe instead things should be designed in a way that the functionality you want to access in the test fixtures are public in the traditional Java sense, but are located in an internal package that is only exported to the test fixtures.

[xenoterracide]

Some of the testing is handled reflectively, while other parts are done via classpath testing.

The issue arises when testing my JPA base module. I have an AbstractBaseClass with package-private getters/setters for fields like @Version, as I believe these should remain hidden, even from the subclass. My test fixtures create concrete @Entities, and the tests validate them while ensuring that properties like versioning are incremented properly. Unfortunately, there’s no way to export these getters/setters, and keeping the abstract base class in an internal package isn’t feasible.

Am I breaking encapsulation? Yes, but I think in certain cases, fixtures are meant to do just that.

[jjohannes]

Thank you for the clarification. I think I understand the use case better now.

We can consider this as an additional opt-in feature of this plugin. Something like

javaModuleTesting {
  whiteboxTestFixtures {
    requires.add("additional.requires.for.the.fixtures")
  }
}

I think this roughly would require the places that needs to be adjusted:

• compileTestFixturesJava task to be patched similar to now the compileTestJava task is patched for whitebox
• Test suites, no matter if whitebox or blackbox, need to use the patched module that combines main and testFixtures classes into a single module.

Note: These whitebox test fixtures are then only to be used inside the project they are defined in. If they are also used outside in another module, things get more tricky. One would have to patch things so that the two Jars (main+testFixtures) on the module path are patched together. This may require cross-project knowledge. I am not sure how to implement this. But maybe this cross-project support is not needed to solve the use case this issue is about (?).

I can't promise anything as this still sounds quite specific, but I am happy to consider/review contributions in this area.

[xenoterracide]

yeah, I thought of the "other module" case later, and I don't think that using this for that is appropriate. When I thought of that it made me conflicted. I need to test some sort of real class, and I prefer to stick that into fixtures... but fixtures is also used for making it easier to test things using the same classes in other modules. I don't think the other modules need access to package private things ever though.