“Is it worth writing test code for application logic (as opposed to business logic)?”
- Yes.
- Not all of it.
- Not always.
Test what yields business value.
Making the development effort more efficient may yield business value.
If application logic is directly related to business value, it needs automated tests.
If lack of tests for application logic delays development efforts (including manual testing), then it’s worth writing tests.
An example…
As a developer, I like being able to take an API contract designed by the team (the URI to the endpoint and the shape of the input and output) and write a quick test for it that we can use to make sure the endpoint works as expected.
This is what such tests look like:
On the left, we see the test. On the right, we see the expected payload and response.
This integration test verifies that:
- The route exists
- The json payload can be handled
- The response gets serialized into the expected json
But not only that, it also verifies any middleware that exists between the route and the controller, so things like authorization, model binders, dependency registrations, etc.
We either find a test harness, or build one, to make such tests easy to write, so there’s no reason not to.
The example above:
- Does not need any special tool
- Is written in plain C# and xUnit.net
In summary, when deciding what we should write tests for, “application logic” also comes into consideration.
Claudio Lassala's Blog 