Writing 'minimally passing' tests?
The Microsoft documentation recommends writing minimally passing unit tests:
https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices#write-minimally-passing-tests
I was wondering about how this applies in the case of testing something like a controller.
For an example, our controller has an action method that calls a service, whose purpose is to call an external API, using the parameters I pass into the action method, without transforming them. And if we get a successful response from that service, then our controller returns OK.
I'd want to write a unit test for that action method, to check that the controller returns OK if we get a successful response from the service.
So for the test, I just set up a mock service, and the relevant method returns a successful response, indicated by a boolean property, for any parameter(using Moq's It.IsAny<>)
I'd be testing that we call the mock service correctly in another separate test, which is irrelevant here.
Would it be best to pass in the 'minimum' parameters for my test to pass? In this case, passing in null for everything including the request payload may be 'unrealistic', but if I don't need to set them up for the test to pass, is there any point setting up 'realistic data'? The only issue I can see is if we add null parameter handling to the controller action in the future, which would mean we would have to go back and update these tests to use non-null parameters, but that wouldn't be much work.
The service used in the controller would also return more than just if it was successful or not (such as a payload), but again the test doesn't use it, so I don't know if it would make sense to add it or not.
1 Reply
This is called an Integration Test, as you are testing the full stack from top to bottom.
Typically people use javascript frameworks like playwright / puppeteer/etc to perform full integration tests front to back.
For unit testing, you want to be testing just your service "business" layer, ideally "mocking" out anything on the "edge" that it interfaces with.
Which typically means implementing a mock http context provider, using an in memory database, and mocking your services that connect to 3rd party systems/apis