[netomi]

Why

ExtensionVersionJooqRepositoryTest and ExtensionJooqRepositoryTest test ExtensionVersionJooqRepository/ExtensionJooqRepository — plain @Component classes that talk to the database directly through jOOQ, not Spring Data JPA repositories. A bare @SpringBootTest still boots the entire RegistryApplication for them regardless, pulling in every auto-configuration the app has — most notably all ~30 Spring Data JPA repository interfaces, each one's derived/@Query methods individually parsed and validated against the Hibernate metamodel. That's the dominant cost of a full application context in this project: on the order of a minute, spent entirely between the QueryEnhancerFactories log line and whatever comes next, with nothing logged in between. On top of that: JobRunr's SQL storage provider, the full web/MVC layer, security, actuator — none of which either jOOQ repository needs.

What

Adds JooqOnlyTestConfig, a @SpringBootTest(classes = ...) root that imports only what these tests actually require:

• DataSourceAutoConfiguration — the DataSource
• FlywayAutoConfiguration — creates the schema
• HibernateJpaAutoConfiguration — the EntityManager/transaction management the tests use to set up fixtures
• TransactionAutoConfiguration — @Transactional rollback-per-test support
• JooqAutoConfiguration — jOOQ's DSLContext
• @Import({ExtensionVersionJooqRepository.class, ExtensionJooqRepository.class}) — the two repository beans themselves

Both test classes switch to it. Since it's the identical context configuration, Spring's test context cache shares one instance across both.

Verification

• Both test classes together (21 tests, including a cold Postgres container start, Flyway migration, and full context bootstrap): 35 seconds, down from well over a minute of context startup alone for either one individually before.
• Full suite: 1061/1061 passing, total runtime down from ~9-10 minutes to 8m1s.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR speeds up the server’s jOOQ repository integration tests by replacing full RegistryApplication bootstraps with a narrowly scoped Spring Boot test context that only includes the database, Flyway migrations, JPA/transactions for fixture setup, and jOOQ.

Changes:

• Added JooqOnlyTestConfig to import a minimal set of auto-configurations and explicitly register the two jOOQ repository beans under test.
• Updated ExtensionVersionJooqRepositoryTest and ExtensionJooqRepositoryTest to use the shared minimal context and disable the web environment.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
server/src/test/java/org/eclipse/openvsx/repositories/JooqOnlyTestConfig.java	New minimal Spring Boot test root configuration for jOOQ repository tests.
server/src/test/java/org/eclipse/openvsx/repositories/ExtensionVersionJooqRepositoryTest.java	Switched to JooqOnlyTestConfig and WebEnvironment.NONE.
server/src/test/java/org/eclipse/openvsx/repositories/ExtensionJooqRepositoryTest.java	Switched to JooqOnlyTestConfig and WebEnvironment.NONE.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[netomi]

Follow-up: two more tests narrowed the same way

Checked the rest of the @SpringBootTest-based test suite for the same opportunity. Most of it genuinely needs the full application (anything going through RepositoryService, the aggregate facade that injects all ~30 JPA repositories, or a real end-to-end HTTP test) — but two more classes clearly didn't:

• ExtensionScanJobRecoveryServiceTest: the service under test is constructed by hand from plain Mockito mocks; the only real Spring bean it touches is a DataSource, to exercise the actual Postgres advisory lock through real connections. Narrowed to DataSourceAutoConfiguration alone — no JPA, no jOOQ.
• NamespaceRepositoryTest: needs exactly one Spring Data JPA repository interface, NamespaceRepository. Worth noting: @EnableJpaRepositories scans every repository interface in its base package, and every repository interface in this project lives in the same org.eclipse.openvsx.repositories package — so just restricting basePackageClasses wouldn't have helped at all. An explicit includeFilters (FilterType.ASSIGNABLE_TYPE on NamespaceRepository.class) is what actually scopes it down to the one interface.

Measured: both together (10 tests, including a cold Postgres container start and two separate context bootstraps) run in 42.5s. Full suite: 1061/1061 passing.

---

🤖 Generated with Claude Code