-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
whitebox test fixtures #66
Comments
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 |
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. |
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 Am I breaking encapsulation? Yes, but I think in certain cases, fixtures are meant to do just that. |
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.
The text was updated successfully, but these errors were encountered: