Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mutationCoverage not working with @Testcontainers - example attached #827

Closed
jaguado-arima opened this issue Nov 30, 2020 · 7 comments
Closed

Comments

@jaguado-arima
Copy link

Hi!
I have implemented my integration tests using @testcontainers. They pass successfully but when running mutationCoverage they don't.

When running mutationCoverage, a container is started, the context is loaded (setting up datasource properties) and tests are successfully run. Afterwards in the "Gathering coverage for test Description" phase another container is started but the datasource configuration is already loaded with the previous container info.... so I keep having an error with database connection: "HikariPool-2 - Connection is not available"

I don't manage to understand what is happening.
Is it that Pit is not compatible with @testcontainers? Am I doing something wrong?
Any ideas?

Thanks in advance!

@jaguado-arima
Copy link
Author

Hi! I have made it work!
I have added @DirtiesContext to the test class (https://github.com/jaguado-arima/pitTestcontainers/blob/master/src/test/java/com/example/pitTestcontainers/pets/PetServiceWorkingWithPitestTest.java) this way the database properties are set every time a container is created.

Nevertheless when using the singleton container approach there is no need for "tricks". So as using singleton container would be best for many cases, I think that this is what I will use (https://github.com/jaguado-arima/pitTestcontainers/blob/master/src/test/java/com/example/pitTestcontainers/pets/PetService1SingletonContainerWorkingWithPitestTest.java)

Thanks!

@hcoles
Copy link
Owner

hcoles commented Dec 1, 2020

Hi @jaguado-arima, thanks for the update. Sorry I wasn't able to provide any help with the issue.

I'm glad it is working for you, but a word of caution. If you are using tests that hit a containerised database you are likely to hit further issues. As the database instance will persist between indivual test runs, the mutation results may not be accurate. If one mutation results in data in the database being put into an "impossible" state, this may result in tests failing for subsequent mutaitons. This is one of the reasons (along with performance) that mutation testing with integration tests is not usually reccomended.

@jaguado-arima
Copy link
Author

Hi! Thank you very much for your reply.

But with the tests having @transactional annotation all changes will be rolled back and that problem will not exist? (Am I wrong?)
About the performance... you are right! But I find it useful to use mutation, at least locally, when I am developing.

Thank you again! Have a nice week.

@hcoles
Copy link
Owner

hcoles commented Dec 1, 2020

Yes, if you have something in place that robustly rolls back data between tests you should be fine.

@jaguado-arima
Copy link
Author

Thank you very much!

@StefanPenndorf
Copy link
Contributor

I've already answered on the mailing list and used my findings to create spring-projects/spring-framework#26196 which contains detailed results (for users only reading github).

@jaguado-arima
Copy link
Author

Yeah! Thank you!:ok_hand:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants