Recently, I spoke to an Engineering Manager about some work I’ve done:
I had to implement a micro-service to a third party API contract (that they will call). Part of the requirement is to immediately acknowledge the HTTP request, and then do stuff and call a callback endpoint via OAuth. The callback (and OAuth) endpoint(s) are configured in the Java Spring config – we don’t receive it at runtime. This API will be published in an internal API platform through which it will be called by the third party.
The Engineering Manager said the following was not best practice:
For automated testing, to avoid having ‘test’ deployments vs non-test deployments, I added an optional parameter (
callbackConfig) that can be used to override the callback (+ OAuth) endpoints. This way, I can redirect the callback to a mock server and retrieve the results to assert on. This parameter is secured by a special role not accessible via the API platform – only accessible from the development environment and automated tests.
Example code:
@RestController
@RequiredArgsConstructor
public class MyController {
private final MyService myService;
@PreAuthorize("hasRole('TEST') or #myRequest.callbackConfig() == null && hasRole('STANDARD')")
@PostMapping
public void processRequest(@RequestBody final Request myRequest) {
// Request is a Java Record. CallbackConfig is a POJO. This call here is pseudocode for clarity
myService.useConfig(myRequest.callbackConfig())
myService.process(myRequest);
}
}
What would be the best practice alternative to this?
5
There is no such thing as a “best practice” when it comes to software design. However, your design does appear to be unnecessarily complex.
The biggest problem that I have is that, based on what I see here, callbackConfig() exists only for testability. In other words, you have written and will deliver code as part of your build that is only for testing. I consider this a poor practice, and there are often (but not always) better alternatives).
It’s unclear from your description why you cannot use a mocking framework to mock calls in a test environment. If you wanted a broader test, you could write a mock server that listens to requests and responds to various types, with responses ranging from valid responses to error states for the server, and your application configuration would provide a way to specify the URL and port for this server application.
8