Our project has over 500 test suites. It takes up to 30 mins to run and I found a huge amount of time spending is on Liquibase when initializing Spring context for test suite.
Would like to know if there are any good approach to accelerate the process? E.g. Run Liquibase one time and do file copy (h2 database) to reset database for each test suite?
Related
I am writing some BDD tests using Cucumber for my Spring Boot application (v2.2.1), and it works OK.
However, I am facing some performance issue, because the application gets started/stopped for every scenario in the feature file : I am using in-memory DB with Liquibase, so for each scenario, this gets executed (takes a few seconds).
Sure, it's currently guaranteed that my scenarios are very well isolated.. Maybe in some cases I will want this behaviour, but right now, most of my feature files would benefit from a one time set up : since each scenario sets up different records (with no overlap) it needs in the in-memory DB, I could theoretically executed my scenarios in parallel on a single Spring Boot application running.
I saw https://blog.codecentric.de/en/2017/02/integration-testing-strategies-spring-boot-microservices-part-2/ , but it requires to have built the application first, then start it from the jar.
Isn't there a way to do the same, but with the application started once from the Cucumber runner ? any example somewhere ?
Thanks to #mpkorstanje link, I was able to find the issue : while trying to replicate the suggestion in my project, I discovered that one of the config that was scanned had a #DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS) annotation.. So that was the issue. Now I need to look at a workaround like what is suggested here : #DirtiesContext tears context down after every cucumber test scenario, not class
I've problem with spring boot integration test. I have aproximately 300 tests and during their execution more than 150 postgres connections are opened.
Tests are annotated almost everywhere by SpringRunner. Sometimes there is more annotations.
This also causes that the test are executing without the end probably.
In my opinion database is not removed with context change but have no idea how could I invoke this process.
I have a project with Spring which has integration tests with JUnit. When I run the tests, I can see the difference between execution time of the tests and real time. Real time (the time between I press "run test" and finished tests) is something like 1.5 times greater than "junit time".
Why does this difference exist? Is it induced by Spring context startup and shutdown?
Execution time is just the amount of time for the test case. The real time is everything else. Spring context startup and shutdown. And any before and/or after methods.
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.
Is it possible to write junit test that persist in mysql using hibernate / jpa?
If so any example available?
I'm using spring/hibernate for my application
When you have real database connection I would not call your test unit test, but more like integration test. To be honest this kind of tests is not a good idea in most cases. It requires some maintenance (every time you have changes in db), and in most cases just tests if it is possible to connect do database (and save some simple object).
Focus on writing good tests for domain level classes. Simple database integration tests will only give you illusion of high quality application.
If you want to write an integration test that looks like a unit test, you could try Arquillian.
What Arquillian does is basically start an application container (Glassfish I think is the default), then it deploys your server-side application in the container and runs the tests against the just-deployed application.
What you write in the unit tests is really client code, so that what you are effectively running is an integration test (with a real database and all the services you would have in a real environment), just in a junit-like way.
They also have a specific tutorial for persistence testing.