[URP-306] create a framework for running tests on services and api

[JacobSilasBentley]

Summary

Creates an approach for being able to run the same test suite on both the Application and Presentation layer to avoid testing logic duplication
Implemented HTTP related authorisation code, retrieving user info from the claims of the user.

Update

This has been updated to remove the integration testing until it can be agreed how this should be approached.

Risks and follow-up

• Only implemented for organization service for this task.

Checklist

• Tests added or updated where appropriate
• Linting and formatting pass
• Accessibility considered for UI changes
• Security/privacy impact considered
• Documentation updated where needed

[jack-burt-is]

I can see that this framework avoids duplicating the test implementation: the setup, inputs and assertions are written once and then executed against both the application service and the API.

But my concern is the maintenance required to make the API behave like the application interface. OrganisationController maps application results to HTTP responses, while OrganisationHttpClient then implements the reverse mapping from those responses back into application result types. e.g,, NotFound → 404 in the controller is recreated as 404 → NotFound in the test driver. Every new operation or result requires both mappings to remain aligned. It also means the complete set of business rules, persistence behaviour and DTO assertions runs twice against the same underlying service and database. The HTTP execution adds some useful confidence, but much of that coverage belongs to the service rather than the controller.

Wondering if a more focused testing split be simpler to maintain?

• We keep comprehensive service tests for authorisation rules, persistence and returned data, - We test controllers with IOrganisationService mocked, covering each service-result-to-HTTP-response mapping.
• Keep a small number of full-stack API tests to verify routing, model binding, serialisation, dependency injection and database wiring.

This would still test each layer’s responsibilities and retain some end-to-end confidence, without needing to maintain an HTTP implementation of every application service interface or execute the complete behavioural suite at both boundaries.

Absolutely up for being talked round to doing this just a bit worried that it feels like a reasonable long-term maintenance commitment for limited additional coverage over just mocking the services for our controller tests.

@SmithR-IS it would be good to get your thoughts also.

[JacobSilasBentley]

Hi @jack-burt-is, thanks for the comment. I appreciate the concern about maintaining the driver for running the integration test. I have two thoughts on this.

• Firstly, I think maintaining unit tests for the controller + mocking of the service represents a higher maintenance burden than maintaining these drivers.

• Secondly, I think it's going to be challenging to select a small number of full-stack API tests that fully verify everything that we want to verify (serialisation, model binding, mapping, etc.). It will always end up being a case of personal judgement. The safe thing to do imo, is just just run the same tests we use to verify the functionality of the services.

Issues about speed of tests can be mitigated later by marking integration tests with a Trait and only running these as part of CI or on a schedule.

Appreciate it's important to get this decision right. I'll happily have a chat about it in person.

[JacobSilasBentley]

To document the decision here. I have removed the web api level testing until it can be agreed the correct approach to this.