-
Notifications
You must be signed in to change notification settings - Fork 132
#29 - Use TestContainers for integration tests #51
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
Conversation
… found. Postgres integration tests now run either with a locally installed and started database or if no such database can be found an instance gets started in a Docker container via Testcontainers.
Formatting for improved readability. Fixed cut'n'paste JavaDoc. Copying over the port from configuration to `ConnectionFactory`.
return local(); | ||
|
||
ExternalDatabase local = local(); | ||
if (local.checkValidity()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest inverting the condition. "If Docker is available, otherwise".
Some users might have an important state in their local database, or an outdated version of it, or many other reasons.
FYI you can check Docker's availability with:
return DockerClientFactory.instance().client() != null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand and somewhat agree with the concern.
My idea behind making it in this order was that one might want to use a specially configured database, e.g. for reproducing an issue that only appears with a special configuration.
I'm not at all sure if that is a relevant use case but we would lose it if we reverse the preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. What about something like Boolean.getProperty("spring.data.r2dbc.test.forceLocalDB")
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall and testcontainers integrate nicely with the existing code. Do we want to wait for the SQL Server change or do we want to proceed and merge this PR?
@mp911de I vote for going forward with the PR without waiting for Ms-SQL. To freely quote Winnie the Pooh: "You never know about legal". What is your opinion on the little discussion I had with @bsideup? I'd currently say: let's just invert the order of things and add more flexibility to it once we need it. |
I guess I'm the only one with a strong local-running database preference. Let's call the property |
We now prefer a database based on TestContainers. Only if this can't be obtained do we try to access a local database for Postgres. This minimizes the risk of accessing a database during tests that is not intended for that purpose. If the system property `spring.data.r2dbc.test.preferLocalDatabase` is set to "true" the local database is preferred.
I added a commit making the preferred order configurable and defaulting on TestContainers first. Will you take it from here, @mp911de ? |
Going to merge this one now. |
Postgres integration tests now run either with a locally installed and started database or if no such database can be found an instance gets started in a Docker container via Testcontainers. We prefer a database based on TestContainers. Only if this can't be obtained do we try to access a local database for Postgres. This minimizes the risk of accessing a database during tests that is not intended for that purpose. If the system property `spring.data.r2dbc.test.preferLocalDatabase` is set to "true" the local database is preferred. Original pull request: #51.
Add author tags. Add static factory method to create an unavailable database object instance. Simplify database selection. Javadoc. Original pull request: #51.
That's merged and polished now. Thank you. |
This change only provides the change for postgresql since for MS-SQL im still waiting for advice from legal.