I'm trying to develop library and write integration tests using #SpringBootTest.
I'm supplying custom #SpringBootApplication class and when i trigger tests, testcase will start running, spring context loads(banner, hibernete logs) and stucks forever. it doesn't come back to test case code to run it. I've enabled debug logs but nothing useful found. not sure where it's going wrong
Related
Say I have 10 spring boot test class (annotated with #RunWith(SpringRunner.class) and #SpringBootTest)
Each test needs to launch spring container for like 10 seconds, although the container might do the same init.
So I may need 100 seconds for "mvn test".
Is there a way I can group my 10 test class into 1 suite, and let the container only start once.
So I can:
Only run the suite for "mvn test". (with proper naming for individual test class)
Optionally run individual test in IDE.
Spring uses Cache Management to cache the Application Context between tests:
By default, once loaded, the configured ApplicationContext is reused for each test. Thus, the setup cost is incurred only once per test suite, and subsequent test execution is much faster. In this context, the term “test suite” means all tests run in the same JVM — for example, all tests run from an Ant, Maven, or Gradle build for a given project or module. In the unlikely case that a test corrupts the application context and requires reloading (for example, by modifying a bean definition or the state of an application object) the TestContext framework can be configured to reload the configuration and rebuild the application context before executing the next test. (https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/testing.html#integration-testing)
So this mechanism tries to execute your integration tests on an already running Application Context if possible. As you see multiple Application Context launches, this indicates your tests somehow use a different setup e.g. different profiles active, test properties, MockBeans etc.
The Spring documentation provides an overview on which indicators it puts an Application Context in its cache: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/testing.html#testcontext-ctx-management-caching
If you e.g. don't change any test property for your integration tests, Spring can run all of them on only one Application Context and be extremely efficient.
Another indicator for your current behaviour might be the use of #DirtiesContext which leads to a fresh Application Context after your test executes.
All my tests share the same Spring configuration. It works effectively because context is started once and reused. Whole test suite completes in short time.
The problem is when Spring configuration is broken. In such case first test fails with
IllegalStateException: Failed to load ApplicationContext
and each next test the same. It last long, because for each test context is started and failed.
Usually I am satisfied when testing process is continued after failure. But in this case I prefer to stop testing process - if context is not started once, it will never start successfully.
Is is possible to break test process in such case in JUnit 4/5?
JUnit 4 has option to request stop tests, see https://stackoverflow.com/a/31397394/2365727
But using it is a bit difficult.
JUnit 5 seems do not have equivalent
I have a #Service class where i'm caching some table data. I don't want those queries to run while building mvn install. Is there a way to ignore the file while building and it only execute when i start the server ?
It's a spring-boot application.
Here is background of my issue. I have initialized the spring boot app from http://start.spring.io/ site, which actually adds dummy application test file with SpringBootTest annotation and default contextLoads() with Test annotation, with an intention to initialize and execute all test cases, which needs to initialize and execute all code base. In my opinion this is not required, as we can have respective Test classes per controller/manager, which will give more controlled environment to hook up your Test setups and executions.
I have removed the default application Test file and included respective test classes for code coverage and quality. This way my beans are not executed at server startup time rather build time.
I have some Spring Boot JUnit tests that require a somewhat lengthy server start up (I'm loading a complex domain in JPA). I've put them into a test suite, but each test kicks off a new server start up.
Is it possible to set them up in such a way that the server is only started once and each test is loaded onto it and run as if the server were started by the test itself?
Okay, so the solution here is actually built in to Spring testing. That is, it caches ApplicationContexts for tests, as described here, as long as the various things like properties are the same.
Ironically, I screwed this up by trying to speed up the tests by using test properties to limit what was loaded.
When I run an integration test of camel route processing as a standalone test, it passes. When I run all the tests, it fails with assertion errors of expected values. When I add #DirtiesContext to the abstract test class, they all pass ok.
I checked the docs and beyond the paragraph below, they do not say why #DirtiesContext is actually needed, and what goes wrong when not used.
Notice that we use #DirtiesContext on the test methods to force Spring Testing to automatically reload the CamelContext after each test method - this ensures that the tests don't clash with each other (e.g. one test method sending to an endpoint that is then reused in another test method).
The thing is that creating spring context again and again is quite time consuming. All our other non-camel integration tests pass without #DirtiesContext (using #Transactional) and we would like to continue with that.
Is there a way to put camel to pristine state without recreating the whole spring context so the test's MockEndpoints work as expected?