I have a use case where i want to segregate the test cases and for that, i want to use 2 test classes, each with #SpringBootTest annotation to start up the server as required.
I have tried doing so, but looks like this doesn't work.
I am unable to find it in the docs to confirm that it is really not supported.
Related
I have an integration test that's using #SpringBootTest to spin up a Spring application context that's testing a simple Spring Boot app. I'm using Spock for writing the tests, my build tool is Maven.
I'm looking for a way to run the same test class multiple times with different configurations for the test (I have a set of config options and I need to ensure consistent behavior for a certain permutation of config options). The first idea I had was to use profiles to define the exact permutation, maybe it could also work by using #TestPropertySource in some way. However, I don't see any way to run a test class multiple times, using different configurations each time.
I know that I could run all tests with a given profile, but in my case I want to only apply the different configs to certain test classes.
I can also use a where block to repeat spock tests as described here, but that doesn't allow me to switch spring configurations for each run
The easiest way is to use simple subclasses, i.e., you define all your tests in an abstract base class and then subclass it for every variation and add the necessary annotations to the subclasses. This approach works well if you only have a limited set of variations, and provides good reporting feedback as every variation is reported as its own specification.
How to write a proper test case for controller, service and Dao in spring boot using junit 5 with clear explanation
Spring Boot has a concept of test slices. This type of test configuration will setup only a part of your application and thus making tests:
less likely to break on not-related change,
faster in comparison to configuring all application services (using #SpringBootTest annotation).
For example #JsonTest slice will configure ObjectMapper (and some test utilities for JSON) in the same way as it would happen on production.
Anyway, to your mentioned types:
DAO - use #DataJpaTest slice - it will configure Hibernate with in-memory database and load all your entities and repositories.
Controllers - use #WebMvcTest(YourController.class) slice - it will load only configuration for Spring MVC, advices and your controller. You will be responsible to deal with dependencies of that controller.
Services - pretty much depends on what is your service doing. I prefer using slices also for services depending on Spring-configured beans but your test can also be a very simple standard [j]unit test with all dependencies mocked away. - Depending on the compromise you want to make.
This does not change with the fifth version of junit. The only difference is that you no longer need to annotate your tests with #RunWith(SpringRunner.class).
I'm trying to do a simple spring-cloud-stream unit test to verify the wiring between streams; basically that a handler can read from one stream and write to another. This part is working fine. The problem is that other parts of the app are being started as well; namely, a rabbitMQ listener. There is a method in another class (besides the one I'm testing) which has #RabbitListener. This is the method being called. And I do have rabbit running locally on my machine, for local dev testing. But I don't want this invoked within the test scope.
The spring-cloud-stream test docs here example has
#RunWith(SpringRunner.class)
#SpringBootTest(webEnvironment= SpringBootTest.WebEnvironment.RANDOM_PORT)
I think it's the #SpringBootTest which is starting up the entire configuration, including the RabbitMQ listeners. I've removed the webEnvironment parameter, but that didn't make a difference.
For now, the workaround is to put spring.rabbitmq.listener.simple.auto-startup: false in application.yml, but that's not something I want to continue for various reasons, one of which is that I probably want to unit test that rabbitlistener at one point, albeit in a properly-limited test context.
We're using version 2.0.1 of spring-cloud-stream and spring-cloud-stream-test-support, although this seems to be a more fundamental spring configuration issue that I don't understand how to limit the context.
You can use a property placeholder in the autoStartup property
spring.rabbitmq.listener.simple.auto-startup: ${auto.start:true}
and then use a #TestPropertySource in the test case to set it to false.
I am using Javers 3.11.2 with Spring Boot 1.5.17. When I am trying to run integration tests on an embedded database I still see that Javers tables are getting created each time.
Is there a way I can disable Javers during these tests so that these tables will not be created each time?
There is the easy way, put:
javers:
sqlSchemaManagementEnabled: false
in your application-test.yml. See https://javers.org/documentation/spring-boot-integration/
Disclaimer: I've never used Javers.
In general, disabling something in "integration tests" means that you don't want to load some beans (of Javers in this case).
This means in turn that you have to exclude them from the list of configurations spring boot works with.
If you're using javers autoconfiguration module, it has to provide in its own "spring.factories" file (can be found inside the jar) a file for autoconfiguration.
Find its java code and see whether it has some "#Conditional on something (property beans, etc.)" If it has than create a profile for integration test that will configure the beans in a way that conditional in javers won't pass and the bean won't be created as a consequence
If it doesn't have a conditional on something like this, you'll have to exclude the whole configuration. Its usually can be done by annotation #SpringBootApplication(exclude=<JaversAutoconfiguration goes here>
This will, however, turn it off also for production usage, which is obviously not something that you want. So for "production" profile, you'll have to import it as a regular configuration (not an autoconfiguration), for integration test profile you won't need this.
what's the easiest way to get the spring boot goodness but not try to autoconfigure all the things? For instance, to only run flyway with our already configured properties (some loaded via Consul + Spring Cloud), I was hoping I could do something like:
#Configuration
#Import({DataSourceAutoConfiguration.class, FlywayAutoConfiguration.class})
public class FlywaySetup {}
and have the main method just call SpringApplication.run(FlywaySetup.class)
The problem with this is it picks up all the Component Scan / crazy long list of other dependencies. Any way to specifically configure the dependencies (but still get the nicities of the framework)
If you run this app, it shouldn't use component scan at all. There's nothing that triggers component scan in spring boot besides #ComponentScan (that's available on #SpringBootApplication).
It would help if you could provide more accurate details rather than "crazy long list of other dependencies.". Running that FlywaySetup should only load those two configuration classes (important: these are not handled as auto-configuration anymore). If you have component scan, there's something else you're not showing.
You can exclude auto-configurations you don't need.
You may want to take a look at this SO answer to explore mechanism how to do that.