2

Is there a way to configure the H2 Compatibility Mode for the H2 Database that Spring Boot can auto configure to replace your regular database without just replacing it?

There are documented ways of disabling the autoconfiguration test database replacement: https://stackoverflow.com/a/43557541/141042

I don't mind doing something like this, but most of the alternatives come with other complexities:

  • if you add a application.properties in your test classpath, this replaces your main application.properties during test runs, so then you're stuck maintaining two files (e.g. https://github.com/spring-projects/spring-boot/issues/10271)
  • if you set up a profile for test runs, then you have to make sure that any test needing the test database is marked with the profile

Is there a better way of doing this? I like the simplicity of the Spring Boot auto configured test database, but it seems like I have to force it into MySQL compatibility mode now to continue to work with my existing migrations.

So is there:

  1. a way to configure the compatibility mode of h2 when spring autoconfigures the test database without disabling that mechanism?
  2. a way of specifying the jdbc url for all tests without having to modify each test (e.g. to include a profile) or maintaining two application property files (e.g. a new application.properties in src/test/resources)
Geoffrey Wiseman
  • 5,459
  • 3
  • 34
  • 52

1 Answers1

0

There isn't an option to set a custom URL for the embedded datasource that Spring Boot replaces in your tests. We offer a way to specify which connection type you want but that doesn't include the URL itself. I have no idea how easy we could add that but it's worth looking at least, I've created issue #19038

As for specifying the URL, you shouldn't add an application.properties in your test classpath for the reason you've mentioned. The SO thread you've referenced already has an answer that refers to application-test.properties.

Stephane Nicoll
  • 31,977
  • 9
  • 97
  • 89
  • Sure, the `application-test.properties` works fine, except that it requires you to annotate each test with the profile, which is easy to miss. So if I create a test and I don't annotate it (or inherit from a class that does), I'm back to getting a migration error. If that's the best path, it's the best path, but it's still higher-friction than I want. Thanks for the advice anyhow, it's nice to have a confirmation that there isn't an option that I'm missing. – Geoffrey Wiseman Nov 19 '19 at 15:59
  • No worries. This comment confuses me a bit considering your description has "I don't mind doing something like this". Have I missed another way? – Stephane Nicoll Nov 21 '19 at 12:18
  • No, I was just hoping I'd missed another way. What I don't like about using a profile for test configuration is, as I said in the question, "if you set up a profile for test runs, then you have to make sure that any test needing the test database is marked with the profile". The autoconfiguration I'd be replacing is automatically used for all tests, so if there was a way to modify/configure that, rather than adding a new kind of configuration that I have to remember to apply, that appeals to me more. But if that's not an option (it seems like it isn't), then using a test profile will suffice. – Geoffrey Wiseman Nov 21 '19 at 19:04