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.
Related
I am working on a large project and need to offer users the ability to optionally enable or disable local integration test cases ( For pipeline, test cases must be enforced).
First of all, welcome to the community.
Next, you can modify the test task inside the build.gradle file or maybe add a new task called integrationTest and implement your custom logic there.
As an instance, you can check this gist on Github: Separating tests from integration tests with Gradle
You can also use #Profile annotation to your integration test classes and run your tests with different profiles. You can read more about profiles using the following link: Spring Profiles
I was reading through the guide for using Spring Boot Test and there was a paragraph that got me confused.
“As our profiles get richer, it's tempting to swap every now and then in our integration tests. There are convenient tools to do so, like #ActiveProfiles. However, every time we pull a test with a new profile, a new ApplicationContext gets created.”
https://www.baeldung.com/spring-tests
So it assumes that if all tests are run under the same profile, there is only one ApplicationContext created — but how is it possible? I thought that all the objects are recreated for each test suite anyway. Am I missing something?
The official reference says that it's cached.
https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/testing.html#testing-ctx-management
But how does it get loaded into the JUnit runner or Spock one across multiple test suites?
What was missing in my understanding is the fact that all the test suites are run as a part of a single program, so it's easy to cache any objects that are required by all of them, including Spring context.
I'm new to integration tests, and currently doing it with SpringBootTest.
Roughly what I'm gathering from examples is that each method would be one integration test (corresponds to one REST call).
But what if I want to test a scenario where it's a sequence of steps? Like Create User->Update User->Delete User.
Maybe that's not called an integration test? And if so, how do I chain these inside SpringBootTest?
Well, it is okay to have a testing order at that level of testing, what I mean with level is this:
Unit Testing -> Component Testing -> Integration Testing -> end to end testing.
As you move to the right, the tests are more complex to set up and execute.
In my opinion, the tests you describe are Integration Test, so, having order is fine, but, you should try to avoid adding complexity, for instance, using a mock in-memory database like H2, and populate it when you are testing, helps a lot.
As the database is in memory, you won't need to take care of cleaning or restoring the state of that database, the data just will be gone after the testing finishes.
Now, you need to take care of the order of the test methods. JUnit5 uses a new annotation #TestMethodOrder and JUnit4 uses #FixMethodOrder that is not pretty customizable, you can find more information here
And finally, I suggest using something more BDD related like Cucumber for that kind of tests
I want to accomplish this - Run a background process (a Solr instance actually) that all the tests in my JUnit Suite will use.
To do this - Created a JUnit class annotated with #RunWith(Suites.class). And added a ClassRule on the Suite to start the server and stop it. Individual tests in the suite were annotated with #SpringApplicationConfiguration and #RunWith(SpringJunit4ClassRunner.class). And I also require access to some of the Beans in the Suite itself (like a spring managed settings bean). What's the best way to do this. What I tried.
Annotated individual tests with #SpringApplicationConfiguration
Had the Suite create an ApplicationContext via
SpringApplication.run and access any bean that it wants (a spring
managed Settings bean for example and use it one of ClassRules of
this Suite).
What I observed is that the ApplicationContext context gets created everytime, One for the Suite because I called SpringApplication.run and one for every test. I obviously want to avoid this and caching of the ApplicationContext between test runs also does not seem to work in this case.
So what are the best practices to handle this case.
Any suggestions/recommendations will be highly appreciated.
This is a long forgotten question, but it shown up on my google search, so I am assuming it still somehow relevant :)
I was going down on the same path but I hit so many road blocks that I decided to change my approach:
Create a JUnit runner as described here.
Change #1 to inherit SpringJUnit4ClassRunner here is an example.
Finally, annotate your Test classes with #RunWith(MyCustomRunner.class)
There you go. You can add whatever logic you need inside your runner.
I have a large spring project, using xml configuration. I'm looking for a quick way to verify changes to the xml configuration.
I can load the whole project locally - the problem is this takes more than 5 minutes, loads a huge amount of data.
My XML editor catches XML formatting errors.
I'm looking for something intermediate - to catch obvious problems like references to beans that aren't defined, or calling constructors with the wrong arguments. Is there a quick way to do this, without having to actually invoke all the constructors and bring up the whole environment?
I'm building with Maven and editing with Eclipse, although my question isn't specific to either.
Since you already use Eclipse, you could try Spring Tool Suite (comes either standalone or as an add-on). It's essentially Eclipse with extra Spring-specific features, like Beans Validator. I'm not sure how thorough the validation is, but it should catch most configuration problems.
It's maintained by SpringSource so its integration with Spring "just works" and it's guaranteed not be more or less in sync with Spring Framework's release cycle.
Beanoh :
http://beanoh.org/overview.html#Verify
this project does exactly what I'm looking for. Verify obvious problems with spring config, but without the overhead of initializing everything.
You can use a Spring testing support to integration test your Spring configuration. However if the loading of the context is taking 5 mins, then the tests will also take the same amount of time. Spring does cache the context so if you have multiple tests using the same set of Spring contexts, then once cached the tests should be very quick.
I can suggest a few ways to more efficiently test your configuration:
Organize your project in modules, with each module being responsible for its own Spring configuration - this way, each module can be independently developed and tested.
If you have a modular structure, the testing can be more localized by mocking out the dependent modules, again this is for speed.