Check if integration test methods from ibm.com should be added

aguibert / openliberty-cheat-sheet

Concise tips and examples for using Open Liberty

https://aguibert.github.io/openliberty-cheat-sheet/

Apache License 2.0

19 stars 9 forks source link

Check if integration test methods from ibm.com should be added #3

Closed bmarwell closed 4 years ago

bmarwell commented 4 years ago

Hi,

I found out that https://developer.ibm.com/wasdev/docs/writing-functional-tests-liberty/ has some more methods of starting an integration test.

While the current cheat sheet contains microshed and arquillian, there seem to be other methods:

Starting Liberty from a Junit test directly.
Starting Liberty from a build script which is executed before the test phase starts.

The document is written by Iain Duncan and was written back in 2015. It is hosted on ibm.com (License?). If the Junit approach still might be reasonable today, maybe even create a new repo under https://github.com/OpenLiberty and host Junit4 rules/runners and Junit5 Extensions?

If this approach is not reasonable, maybe even document as well ("not recommended, because …").

I would also like to see the disadvantages and advantages listed for each method.

aguibert commented 4 years ago

hi @bmhm, the JUnit rule is essentially how MicroShed and Arquillian work, but they go about it in different ways:

MicroShed starts the app up as a Docker container
Arquillian starts the app using the wlp/bin/server script

Both of these frameworks provide JUnit rules/runners so that the user doesn't have to write/maintain them on their own.

I would not recommend using the com.ibm SPI shown in that article because of the following reasons:

starting a server is outside of the scope of a "unit test"
it is likely now how the app is deployed in production

bmarwell commented 4 years ago

Alright. Are there other possible solutions? I am thinking of environments which do not have docker available and arquillian might be hard to set up in a multi-module project. Imagine the .war module with tons of (transitive) dependencies.

aguibert commented 4 years ago

Docker is available in all public CI tools as far as I'm aware (TravisCI, Azure Pipelines, Jenkins, etc). Do you have some sort of custom environment that doesn't have Docker?

bmarwell commented 4 years ago

It is nice to see that public CI tools do have docker. Since your cheat sheet is targeted to those environment, I think this issue can be closed then. Thanks for looking into it!