JUnit integration tests are too slow. about generator-jhipster HOT 9 CLOSED

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...

from generator-jhipster.

@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...

from generator-jhipster.

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

from generator-jhipster.

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

from generator-jhipster.

@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.

from generator-jhipster.

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.

from generator-jhipster.

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.

from generator-jhipster.

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

from generator-jhipster.

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.

from generator-jhipster.