Added integration tests for JUnit 5 lifecycle methods

[lprimak]

Short description of what this resolves:

Integration tests for lifecycle methods with JUnit 5
Relates to #310 #309 and #301

using @TempDir as a base for temporary directory
Could not use it 'as is' because it gets deleted for each test class,
but the files need to be kept throughout the test suite

[lprimak]

Tests will fail until App server tests are set up and #310 is merged

[bartoszmajsak]

I am not really convinced these tests should live in the core, as they are also dependent on the application server adapter which is a separated entity and can or cannot support particular feature for whatever reason.

My initial thinking is to resurrect arquillian-showcase project and set it up in a way that every PR in arquillian-core would run tests from it as a PR check. Showcase needs work now to be back to life, but I will work on it this week. The next step would be to think about what kind of useful extension example we could build so that JUnit 5 is used there. Alternatively, we can port one or more existing extensions to JUnit 5. On top of that, we could bring Arquillian Chameleon there to easily swap different container adapters and run those tests against them. WDYT?

[lprimak]

I think you are right about all of that. There can easily be some module that does integration testing with a container

[bartoszmajsak]

I think you are right about all of that. There can easily be some module that does integration testing with a container

Lemme get a bit deeper to it and we will definitely put your valuable to good use :)

[lprimak]

@bartoszmajsak I figured out how to do integration tests properly with app servers, so here is the fixed version of this PR.
It passes CI and works properly now. Ready to merge.

[lprimak]

@bartoszmajsak what do you think?

[lprimak]

@bartoszmajsak
@starksm64

Any chance of getting this merged?

[bartoszmajsak]

@lprimak As I mentioned in #314 (comment) I am reluctant to make this part of core as it tests against one specific application server and I would rather have core free of such dependency (even if we are only talking about test dependencies). As suggested in the aforementioned comment, I believe it would be more beneficial to have separated project with such tests and make it part of the verification process in the core module. The challenging bit here is that clearly I don't have capacity to work on this right now :(

[lprimak]

Do you think there is harm to merge this and then later when you have time, you can fix it to your liking?
I personally don't see the harm

[bartoszmajsak]

Do you think there is harm to merge this and then later when you have time, you can fix it to your liking?
I personally don't see the harm

If there's something I learned the hard way in my software engineering journey it can be summarized as

"There's nothing as permanent as a temporary solution"

I would rather start with something small and separate which can give us an answer "does Arqulian with XUnit work with P Container Adapter" rather than introducing another module to the core. Or maybe even make it part of the container adapter itself? After all, it's a Payara-specific test suite right now.

[lprimak]

"There's nothing as permanent as a temporary solution"

True true, however, there also "iterative development" argument here :)

[lprimak]

@bartoszmajsak I think this is still relevant, can we make some progress here?
thank you!