Question
Can JHipster integration tests run without production database credentials?
Neel Nova
0 reputation · 04 Feb 2020, 20:51 UTC
127.1K views
Loading…
0 reputation · 04 Feb 2020, 20:51 UTC
A generated JHipster application should be able to exercise its Spring integration tests without relying on production datasource credentials. The unresolved point is which test-database behavior a particular generator release selects: an embedded database, a Testcontainers-managed service, or an explicitly configured external database.
Because the JHipster release, database choice, build tool, and blueprint are unspecified, no single default can be assumed. The test profile is typically located under src/main/resources/config, with additional test configuration under src/test/resources. Its presence alone does not establish that production secrets are inaccessible or that the datasource has been replaced.
For a specific generated project, can the effective test profile and build configuration establish which datasource integration tests use? Which generator options or test annotations control that selection, and what evidence would confirm that the tests start without production credentials?
35775 reputation · 05 Feb 2020, 05:19 UTC
Yes – a JHipster‑generated Spring Boot application can run its integration tests without accessing production database credentials, provided the test profile is correctly configured. The tests use either an embedded H2 instance or a Testcontainers‑managed database, both of which are defined in the generated src/test/resources/config/application.yml (or application-test.yml) and are independent of application-prod.yml or environment‑specific secrets.
jhipstertest profile is activated automatically by the Maven test goal or the Gradle test task.application.yml the test profile overrides spring.datasource.url with a value that starts with tc: (for Testcontainers) or h2:mem: (for an embedded H2 database).prod profile is active, e.g., via application-prod.yml or the -Dspring.profiles.active=prod system property.src/test/resources/config/application.yml (or application-test.yml) and locate the spring.datasource.url entry. It should look like tc:postgresql://… or jdbc:h2:mem:testdb.testImplementation 'org.testcontainers:junit-jupiter'
// or for Gradle
implementation 'org.testcontainers:junit-jupiter'
./mvnw test -DskipITs=false
# or for Gradle
./gradlew integrationTest
prod profile in a test class via @ActiveProfiles("prod").spring.profiles.active in CI configuration with prod.To give a definitive answer for your generated project, could you confirm the JHipster generator version and the database option selected for production (e.g., PostgreSQL, MySQL, H2)?
Use comments to ask for clarification. Post a solution as an answer.
7,130 reputation · 05 Feb 2020, 05:24 UTC
When a JHipster Spring project is generated, the integration‑test classes are executed in a Spring context that obeys the normal spring‑boot configuration ordering. Files in src/test/resources override those in src/main/resources, but only for the active profile. Therefore an application-test.yml will be ignored unless the test context is started with the test profile (e.g. @ActiveProfiles("test") or the JVM flag -Dspring.profiles.active=test).
JHipster’s default dev database is an embedded H2. The generator copies an H2‑only datasource block into application-test.yml, so the tests run against an in‑memory DB without external credentials. If the project was generated with a non‑H2 prod database, the test config can either point to a Testcontainers instance or to a separate test‑only service. The presence of a Testcontainers dependency in the pom.xml or build.gradle signals that a container will be spun up automatically.
@SpringBootTest
@ActiveProfiles("test")
class UserRepositoryIT {
@Autowired
DataSource ds;
@Test
void jdbcUrl() {
System.out.println(ds.getConnection().getMetaData().getURL());
}
}
Running the test with a clean environment and no prod credentials, then inspecting the printed JDBC URL, confirms that the datasource is isolated.