JUnit integration tests are too slow.

[mshima]

Overview of the issue

JUnit integration tests are too slow.
Application context is restarted for every class test suit.
Our implementation doesn't allow context reuse.

• use of DirtiesContext
• use of Mock
• some context customizers

Backend test step in ng-default is taking ~5min. It can be reduced to 2min-3min.
The JUnit integration test duration can be reduce by at least 60%.

Motivation for or Use Case

Improve user experience for Tests.

Suggest a Fix

Cleanup tests context.

JHipster Version(s)

main

JHipster configuration

Entity configuration(s) entityName.json files generated in the .jhipster directory

Browsers and Operating System

• Checking this box is mandatory (this is just to show you read everything)

[dwarakaprasad]

@mshima, I am willing to contribute to this issue and have been doing some reading,
context-reload-sof
github issue related to this

Based on spring.io, contexts are cached and re-used as long as context configuration remains unique. I am trying to figure out what this really means from jhipter's backend implementation.

Let me know if you like me to move forward, I see you have made some changes too...

[mshima]

@dwarakaprasad great.
I would say that #21853 is the start point.
We use ContextCustomizerFactory which is not compatible with context reuse.

[dwarakaprasad]

We use ContextCustomizerFactory which is not compatible with context reuse.

Yup exactly, was having some fun looking at spring docs and sprint-test context cache implementation. The lambda that is being returned from SqlTestContainersSpringContextCustomizerFactory seem to be throwing the hashcode which is causing the context recreation.

I am trying to replace the lambda with an object and see how the cache reacts...
Will keep you posted...

[mshima]

That's interesting, we should calculate the hashcode in customizers then.

[dwarakaprasad]

@mshima ng-default with h2 dev has got about 20 - 30 sec faster (from 13 to 5 re-loads). See reference.

You can drop the DirtiesContext from AuthenticationIntegrationTest.java as well.

For some reason your changes does not seem to show any loading optimization.

[dwarakaprasad]

For some reason your changes does not seem to show any loading optimization

got it, the returned ContextCustomizer needs the overridden hashCode method, your impl seems to be adding it to the ContextCustomizerfactory rather. See my reference impl.

[mshima]

With the ContextCustomizer hashCode in place the hash conflict is happing in ImportsContextCustomizer.
ImportsContextCustomizer is quite complex and hard to debug.
I give up for now.

[mshima]

Maybe it's related on how the TestContainerCustomizer is implemented.

[dwarakaprasad]

Maybe it's related on how the TestContainerCustomizer is implemented.

I was able to get the non-testContainer based test ("devDatabaseType": "h2Memory") to be loaded optimally (see this), but not for the one using testContainers. I am getting 'liquibase' bean creation error as the spring.dataSource.url seems to be going in as null from TestContainerCustomizer, i.e. the DatasourceProperties object in the LiquibaseConfiguration.java is empty and nothing from the Customizer is propagated.