Just an update on this. This doesn't look to be an Arquillian issue per se. It's related to the fact that I'm jaring up the tests in a jar which goes against the production code in other jars. With JBoss 7's classloader, you get this error if you access a protected method in another jar ( see https://issues.jboss.org/browse/AS7-3305 ) even if your test class is in the same package.
With that said, I'm not sure how to deploy my tests to allow them to access protected methods.
Hmm.. interesting. Was not aware of this little hick up.
Thanks for the heads up
I have this problem too. I changed them form protected due to that error to default and the error disappeared (the methods are actually meant to be private, however for various reasons I want to test them). NOW though, @Injection fails when those methods are called. When a public method is run IN THE SAME TEST RUN the Injection works. So it appears that Arquillian Injects at each method. Here is what I'm using:
<dependency> <groupId>org.jboss.arquillian.junit</groupId> <artifactId>arquillian-junit-container</artifactId> <version>1.1.1.Final</version> </dependency> <dependency> <groupId>org.glassfish.main.extras</groupId> <artifactId>glassfish-embedded-all</artifactId> <version>4.0</version> </dependency> <dependency> <groupId>org.jboss.arquillian.container</groupId> <artifactId>arquillian-glassfish-embedded-3.1</artifactId> <version>1.0.0.CR4</version> </dependency>
There is no error message indicating any problems.
Fortunately once I've developed and tested the methods I can revert them to private and kill the tests on them. However it would be nice to keep the tests running.
It'd be great if the Arquillian team could have a look at this.
Just a general thought - why would you really like to test protected/private methods? Aren't they used by some public functionalities anyway? If so there is always coverage path to test the overall behaviour (which I think is more beneficial than focusing on small implementation details anyway).
Good question and I'd generally agree.
I am contracted to rewrite a medium-sized monolithic J2EE application to be fully unit and integrated testing and the time I have on this is quite short. They'd also like new functionality!
Specifically in this case I'm discussing I am rewriting a complex single 200 line method. I started by breaking it down into sub-methods and I wrote tests in order to understand what each of these does and to prove they do it. Once complete I can finish the test for the original (public) method.
Because the methods are fairly complex it is possible they will be 'tweaked' and so I'd like to keep the tests.
Any idea as to if Arquillian will be ever (soon) be able to handle protected or default methods?
Well to answer the "why test protected methods" question. In our case we have an abstract template where the implementation has many protected methods. These methods must be tested individually as they actually are units of work and contain complex logic on their own. Certainly you could test those methods through the public interface, but that would be a "step back" from the level of testing that was originally implemented.
Also, as stated before this isn't an Arquillian issue. It's an artifact of JBoss 7's class loading. The only way you can test protected methods is to add the tests to the actual jar the production code is in which is what I ended up doing with the Arquillian deployment.
> The only way you can test protected methods is to add the tests to the actual jar the production code is in which is what I ended up doing with the Arquillian deployment.
Well I've learnt something. That default and protected methods can't be used across jars. Its not just a Web App Server issue but a Java one.
So I moved the unit tests I had on default methods (that were public) into the same project and changed the methods back to being default. I dropped the use of Arquillian and rearranged the tests so they didn't need what I was using Arquillian for (eg. Injection and persistence). So now it works as required and I just need to be able to live with the fact that all the testing code is not just in -test projects.
Thanks all for helping me work this out.