test: consider arquillian

[hohwille]

We want to evaluate and consider arquillian: http://arquillian.org/ It might be a complex beast but:

• we could solve all kind of component testing with one approach then no matter if spring and tomcat or full fledged JEE app server.
• we currently have problems with more integrative tests where arquillian might be more reliable - see #124

We should give it a try and collect the experience and see if this should become our best practice.

[abuwipp]

GEMAESS MAIL VON JÖRG VON EBEN ALS EINSTIEG DER BEITRAG VON SIMON:

From: Spielmann, Simon Sent: Freitag, 27. März 2015 07:51 To: Sobkowiak, Krzysztof Cc: Hohwiller, Jörg; Matczak, Marek; Rose, Marco Subject: Re: Build failed in Jenkins: oasp4j-dev-nb #301

Hallo zusammen,

hab nicht die gesamte Diskussion verfolgt. Warum brauchen wir überhaupt diese Plugins? In der RF deployen wir die Anwendung einfach in einen installierten Tomcat (automatisiert per Ant/Maven). Damit haben wir genau null Probleme. Es ist auch anders als zB bei Arquillian kein besonderes Deployment zu konfigurieren, sondern es wird das spätere Prod Deployment per RPM verwendet.

Viele Grüsse, Simon

[abuwipp]

Arquillian ist gut, um Teile der Anwendung, die notwendigerweise Container-Funktionalität benutzen (Module, DAOs, Web-UI, ...), in kleinen Tests ähnlich Unit Tests abzusichern - unter Verwendung genau der Container-Funktionalität.

Für White Box Tests ist, wie Simon oben schreibt, ein produktionsnahes Deployment der Anwendung besser geeignet. Ein produktionsnahes Deployment wird durch eine produktionsnahe Umgebung begünstigt.

Das Cargo-Deployment liegt irgendwo dazwischen: Es vereinfacht vielleicht das Deployment per Maven, entspricht aber sicher nicht dem produktiven Deployment. Gegenüber Arquillian fehlt mir Cargo die Möglichkeit, gezielt den den Testee, z.B. das zu testende DAO, zu deployen.

Auf unser Problem bezogen:

• Für die betroffenen Tests benötigen wir einen Tomcat, in dem die Anwendung zwecks Tests komplett deployed wird. Wenn der eine Tomcat belegt ist, kann man überlegen, einen zweiten Tomcat daneben zu setzen.
• Arquillian könnte aufgrund der größeren Flexibilität ("Mikro-Deployments") ein globales Cargo-Deployment ersetzen.

[hohwille]

I am proposing to revet the dependency on arquillian in oasp4j-test. Nobody should be forced to use it and many wont use it. Those who like it shall be free to add the dependency themselves (and pick the version of their choice). Arquillian itself also has tons of transitive dependencies what causes a really lot of clutter if you simply do not use it. This is different for assertJ because here we propose to stop using regular assertEquals and instead use assertJ in EVERY test as it is way better (also better than hamcrest). So in the next release the dependency should be dropped. If we want to write test-cases for our sample application based on arquillian we can add the dependency to the sample. However, after going to spring boot and writing subsystem tests with JUnit that run smoothly within the same maven build I would perosnally not consider arquillian what is quite heavy-wheight. It is fine and good to use if you are forced to build of an JEE app-server dinosaur.

[maihacke]

I personally think arquillian is a nice tool if you deploy to an app server. If you are using spring boot there is to small benefit (if any) compared to the complexity it introduces. I vote for removing arquillian from oasp-sample, too. We could give a hint in the documentation for app server users.

[amarinso]

I think that we have to think on our primary deploy scenario. I think that for now applications are still deployed on traditional app servers. It is fine if development is speed up with Spring Boot but testing on some kind of container can be a proof that things are running fine.

Also if we want to explore other options for OASP like a Java EE implementation Arquillian could be useful.

But I think it is fine to have them only on the sample and not on the test module. Giving a hint on the documentation can be also an acceptable solution.

[maihacke]

I think our primary deployment scenario is Tomcat, not a full featured JEE server. So you do not need arquillian. If our primary deployment would be a full featured JEE server we should have done things different (e.g. put the example into jboss).

[amarinso]

Maybe this is something to discuss about. I've always thought that using Tomcat was only because of the convenience. In our real engagements (in Spain) we only see Tomcat being used in very small projects and the norm for our clients is still to use "JEE app-server dinosaur" as @hohwille coined them :-)

In fact we are still working on making an OASP application running on top of weblogic and websphere... which is a nightmare because of the dinosaurs including older versions of the libraries and class loading issues.

[maihacke]

So were working here on very large systems, which are deployed in tomcat. Its hard to say what the majority does. But we should decide what is our target platform and act accordingly. If it is JEE app server we should provide an example for that. If it is not we should not put arquillian into the example.

[hohwille]

I did not wanted to say that we should not consider or recommend arquillian or wireshark. Nor do I want to remove them from dependency-management. However having these dependencies in oasp4j-test is IMHO simply wrong. It is simply getting more in the way than it is helpful. If you want to use it then add the dependency manually in your project and you also have control over it. You should not be forced to use something like this. When using spring-boot then arquillian is IMHO total overkill and the dependecy is driving me nuts. I could add an exclusion but I already have this in multiple places.

[sobkowiak]

As long as we don't have any code in oasp4j-test which depends on arquillian we should have no dependencies to arquillian in oasp4j-test.

[hohwille]

I will also remove the BOM import of arquillian from oasp4j-test/pom.xml as this now does not make sense anymore. Also I would remove wiremock that we are not using either. As compensation we will add this to the testing-guide (add dependency as XMLs to copy) and give some hints.

[hohwille]

I also added links to the documentation. For 1.5.0 we are IMHO complete. My question is how do we proceed with this issue at all? Should be move it to backlock-indiscussion? And then consider if we want to create a separate OASP4J JEE sample with Arquillian tests that runs in the most relevant JEE servers?

[hohwille]

I personally think that it will cause big trouble to put all scenarios in one sample:

• spring-boot vs. JEE
• recent technology vs. legacy compatibility
• leightweight subsystem testing vs. full-blown tests with Arquillian
• KISS and clean vs. all features, scenarios and possibilities.

I do not automatically propose to duplicate the entire code. A JEE sample could be smaller or concentrate on the outstanding JMS showcase that is more JEE centry with message driven beans that then would propbably not go to the spring sample.

WDYT?

[hohwille]

Would someone support both spring-boot and JEE application server in the same customer project? To be honest: no, never. So why should we do here? This will only make things complex and get in the way.

[hohwille]

We shall keep the general discussion about JEE out of such issues. Conclusion:

• We recommend arquillian for subsystem and system tests in JEE environments
• We state this recommendation in our documentation and link to the instructions on arquillan site
• However, we do not want to overload oasp4j-test users with tons of dependencies he will not need in many cases and that can even conflict with other dependencies
• Also we do not use arquillian in our spring based scenario as we have more lightweight and efficient options.
• I vote for a JEE sample and that should use arquillian for testing. But that is out of the scope for this issue.