Can't @Deployment methods be optional?
smmousavi1 Aug 29, 2011 9:30 PMI know that static @Deployment methods are necessary for Arquillian to find following information:
- Archive file type declaration (JAR? WAR?..)
- Archive file name
- Archive file contents (classes, property files, ...)
- Deployment setting definition (multi-server support, ...)
- Deployment order definition
. and so on
And, currently, for test case classes, it is REQUIRED to have such static @Deployment methods.
But, I want to ask to re-think whether isn't it possible to make these methods optional???
Please consider the typical test situation.
Basically, with regards to test, there are 2 categories of code:
- Code to be tested (target web appliction to be tested).
- Test code.
Since, the Arquillian is "In-Container Test Tool", in typical situation, we can consider that "code to be tested" is already deployed/running inside the web container. So, in typical situation, Arquillian don't need to archive the "code to be tested" and Arquillian only need to archive/deploy/undeploy "Test Code". In normal test cases, each test case is single self-containing test class, it don't have any relation with other test classes. The result of this matter is that for many situations only one JAR file (with any default name) that contains the test class itself is enough.
In my Java projects, I have many test cases using Arquillian. However, the result is that in all of them I am copying following un-useful code again and again:
@Deployment
public static JavaArchive createTestArchive(){
return ShrinkWrap.create(JavaArchive.class,"test.jar");
}
So, my suggestion is that Arquillian be smarter, and make such kind of static @Deployment methods optional, and have a defualt behavior, whenever the @Deployment method doesn't exist (instead of making it error).
Please don't tell me that defining one super class and adding the above method to super class can solve it. For sure, I know that solution, and users of Arquillian can use this approach. But, for Arquillian as a test framework, that want to have minimum code addition (related to Arquillian), I think it is not good design pattern.