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.