Is it dead?

[marwin1991]

Is it dead ?

[bartoszmajsak]

Hi, the creator here. I am not actively involved in it, but I can help with PRs if needed.

[abregar]

Hi, @bartoszmajsak, hijacking this last issue opened under your project and kind-a-fits the question of mine.

I see that this wonderful project is now not maintained anymore, but .. it is still very useful, even 5yrs later. Or, it was useful until a project of mine was decided to upgrade to latest frameworks (wildfly27, jakarta10, java17, arquillian1.7, junit5).

Then things started to behave as started in discussion here wildfly/wildfly-arquillian#278 (comment)

I am posting a follow-up under this ticket as you have written that you might help with PR if needed. It is needed now :).
I am particularly interested in there mentioned

<groupId>org.arquillian.ape</groupId>
<artifactId>arquillian-ape-sql-container-dbunit</artifactId>
<version>2.0.0-alpha.7</version>

dependency, but probably there would be some adjustments required in core ape project. I am willing to put some effort into solving this, for starter at least this sql-dbunit part. But would be really glad if you are able to give some debug runs and hint me some guidance in this broad problem space.

Meantime - side-question -> is dbunit project used now tracked here https://sourceforge.net/p/dbunit/ or is there any other fork around? This particular one still seems kind'a alive, at least this ticket is promising https://sourceforge.net/p/dbunit/feature-requests/222/ (junit5 compatibility)

Thank you in advance, a lot!

[bartoszmajsak]

Hi @abregar. Thanks for your interest in the project. I'm more than happy to help you with anything needed, so by all means open PR (even as a draft) and I will make sure to find some time so we can work on this together.

I don't think there's any superior fork for DBUnit that is actively maintained, but I wouldn't have a lot of hopes for this feature to arrive if we don't help (see comments from maintainers). @rmpestano (apologies for calling you out of the blue) perhaps you have some more insights about JUnit5/DBUnit combo considering that it works with https://github.com/database-rider/database-rider

[abregar]

Glad to hear from you, dear Sir. Did put some effort today into this project, and truly have some draft with upgraded deps to desired ones. It builds, is usable to run, but tests are failing many places <- will try some more, and prepare some better 'draft' PR.

Meantime, while I was able to put together all updated artifacts (long story short), my IT test started to execute (probably over with the issue noted here wildfly-arquillian/discussions/278). But it seems I hit some variation of this issue arquillian/arquillian-extension-transaction#31, meaning that simple test as bellow:

    @Test
    @UsingDataSet("arquillianTest.xml")
    @Transactional(TransactionMode.ROLLBACK)
    public void test() {
        System.out.println("nothing, just initialize the db and rollback");
    }

does not do the rollback under junit5. (Meantime2, I have also some small updates on arquillian-extension-transaction project to make it compatible with jakarta 10 and wildfly 27, maybe a PR there too - really draft again ?)

May I ask if you are willing to put some small amount of time and try to give some hints on the transaction issue #31 and how to properly debug it?

[bartoszmajsak]

@abregar could share a little reproducer project?

[abregar]

@bartoszmajsak here, the two reproducible cases
https://github.com/abregar/arquillian-ape-wf26-case195
https://github.com/abregar/arquillian-ape-wf27-case195
please see the readme for details, and let me know if I need to update something to clarify more.

Sub-note - for the wf27 case, there are two explicit dependency requirements (ape-transaction and ape-persistence). I have forked both and committed the fixes in specific branches. Please take a look, as ape-persistence is really huge project and as written in commit log, I have commented out some modules where I was unable to fix the source and make the tests run. As far as I got, issues are when upgrading some deps versions to latest (supporting jakarta) there are significant changes in their code (i.e. flyway 6 removed callbacks ..). And it seems that sql-*ftest modules are failing on dependent project https://github.com/arquillian/arquillian-cube. I did demystify some concepts on all those mentioned projects, seems interesting .. but it will take some time (and help from you) to complete as whole.

So, by knowing this, can we please keep focus only in this particular case with dbunit for start, and then eventually bring complete project back to life?

[abregar]

Just dropping some findings, after some deep dive in debug. Not finished yet, but would appreciate any hints, if rings any bells already. So, two things with latest combination (wf27).

One, seems that 'Observes' precedence is not taken into account somehow. I think the PersistenceTestTrigger observes

 public void afterTest(@Observes(precedence = -2) After afterTestEvent) {
      if (persistenceExtensionEnabler.get().shouldPersistenceExtensionBeActivated()) {
          afterPersistenceTestEvent.fire(new AfterPersistenceTest(afterTestEvent));
      }
  }

prior TransactionHandler observers the After context

  public void endTransactionAfterTest(@Observes(precedence = -1) EventContext<After> afterTestContext) {
      try {
          afterTestContext.proceed();
      } finally {
          endTransaction(afterTestContext.getEvent());
      }
  }

Consequently the database cleanup is triggered not after test but prior test ending.

Two, the check for required-rollback-due-to-failure in TransactionHandler, as in

private boolean testRequiresRollbackDueToFailure() {
    if (testResultInstance.get() != null) {
    ...

always return true due injected testResultInstance.get() returns null for unknown reason. This check returning true then messes up with previous point, and db cleanup (seems properly prepared) statement batch execution gets rollbacked.

Just side note, none of the above points can be seen in the combination with wf26 test case.

@bartoszmajsak can you please give opinion on those findings and what do you think to do, to correct them?

[abregar]

Discussing to myself here :), but still maybe someone may join .. did some digging around arquillian-* related github code and discussions, I see now that there is a longer story on junit5<->arquillian integration. Kudos to all involved, and for general public, please see the know-how around the issue arquillian/arquillian-core#137

Initial great work in the core arquillian is done, .. but seems that there is actually none of the current arquillian-extension-* with even a try to adopt that integration. So in the context of this issue ( #195), maybe it is not arquillian-extension-transaction issue but more arquillian-extension-persistence, but this is to be decided later by project owner(s).

How I see things now - there is new api in junit5 who manages test Lifecycle - and that is https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/extension/package-summary.html. Consequently no more events/observers as in junit4, but Invocation Interceptor(s) instead.

The idea I see above, is really drafted in commit abregar@9d8da17

But there seems I have some more missing pieces as this jupiter extension is not registered somehow. Did try the following pattern, as suggested in junit5 docs https://junit.org/junit5/docs/current/user-guide/#extensions-registration-automatic and patched the runner class in arquillian-core:

public class JUnitJupiterTestRunner implements TestRunner {

    @Override
    public TestResult execute(Class<?> testClass, String methodName) {
        TestResult testResult;
        ArquillianTestMethodExecutionListener listener = new ArquillianTestMethodExecutionListener();
        try {
            final AtomicInteger matchCounter = new AtomicInteger(0);
            Launcher launcher = LauncherFactory.create();
            launcher.registerTestExecutionListeners(listener);
            LauncherDiscoveryRequest request = LauncherDiscoveryRequestBuilder.request()
                    .selectors(DiscoverySelectors.selectClass(testClass))
                    .configurationParameter(ArquillianExtension.RUNNING_INSIDE_ARQUILLIAN, "true")
                    .configurationParameter("junit.jupiter.extensions.autodetection.enabled", "true")
            ...

but .. does not work .. so far.

The idea behind is - when test lifecycle is under control, Arquillian-core.JUnitJupiterTestRunner.execute will also properly return TestResult (already does actually, but no observer sees it currently ..)

So the question, dear important project owner/member @bartoszmajsak, how do you see this mentioned pattern above - is it right or wrong direction? If right, pretty please, give some opinions how to continue. Thank you.

[aminchegeni]

Hi every one
I'm happy to announce that after 2 days of debugging I finally found the problem.

The problem lies in 'insideArquillian' property when set to true in JUnitJupiterTestRunner class and it's execute method.

When I change this value manually in debug mode, the junit5 test cases pass.

Mr. @bartoszmajsak can you tell us how to change this property value and which side effect after change may be occurred?

[aminchegeni]

Result of running transactional-junit5.zip attached.