HAI Remove @MockkBean and @SpykBean annotations

[corvidian]

Description

Configure the Spring Context in integration tests to use a mockk instance of CableReportService so the mock can be @Autowired. CableReportService was defined in several integration tests as a @MockkBean dependency. The actual implementation was only used in CableReportServiceITests, which constructs a custom instance.

The other class that was injected with @MockkBean was EmailSenderService. Since there's an easy-to-use extension for mocking an actual email server, it felt better to use that instead of mocking the service universally. Also, unlike CableReportServiceITests, EmailSenderServiceITest uses the Spring context, so a context with the actual implementation is needed anyway.

Each unique combination of @MockkBeans and @SpykBeans (or the Mockito equivalents) makes Spring create a new context for the test. While not a huge time sink, creating (and destroying) the contexts add up. We can see how many different contexts are created from the number of SQL connection pools that need to be shut down at the end of the tests.

There are situations when they have to be used, but using alternative approaches is usually better.

New contexts are also created whenever the configuration parameters are different between tests. This is sometimes unavoidable when we need to test how the application behaves with different configurations.

Ever since #397 we've been able to use application.test.properties to configure the test environment, so we don't need to use test-specific properties to diverge from the production configuration. There was a properties parameter remaining in TestDataServiceITest, so that was removed.

There's one more service test with custom properties (EmailSenderServicePropertiesITest), but in that test, we're interested in testing that the properties have the effect we want. The properties are different from how we generally want to configure EmailSenderService in tests. So the custom properties are unavoidable.

Controller tests are cheaper to create with varying configurations. Since only a very limited context is created for running them, recreating it is not very expensive. So testing things like feature flags on the controller level doesn't seem problematic.

Type of change

• Bug fix
• New feature
• Other

Instructions for testing

Run tests and check that the number of HikariPool shutdowns has decreased.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

88.9% Coverage
0.0% Duplication