You test the integration of your code with the web framework. An integration test doesn't have to be end-to-end. It tests the integration between multiple components. In this case it would be your code with the integration of asp.net core.
A controller usually doesn't contain any business logic, it does the HTTP part. So you test serialization, model binding, return codes, etc.
So you use a mock to check, if the framework does the expected model binding. If the values you post via JSON end up in the right properties for the service call.
a typical controller method would look like that:
IActionResult StoreProduct(Product p) {
var success = service.Store(p);
return success
? Ok("Stored")
: BadRequest("Product doesn't contain all necessary fields");
}
There is no reason to unit test this controller, because the code is trivial. But it makes sense to integration test it, and verify the serialization and binding of Product works, if the correct status codes and content types are returned. Because that could go wrong.
It is often easier to do that with a mocked service, but you can also use the real service for that. Often this would hit the database and make those tests much slower and harder to set up.
Interesting. I would still consider that a unit test (I don’t insist that a unit test must directly call the method it’s testing - it could be it needs to put it in some sort of test harness to get it executed)
Much how if a piece of code uses a regex, I wouldn’t mock the regex library when unit testing it, nor consider a test that uses the real regex library as an integration test that tests my code’s integration with the regex library, I wouldn’t consider my controller code’s interactions with a web framework as ‘integrations’ to test. They are part of how the unit is implemented.
But this is just a naming debate - I’m in agreement that that is a useful kind of test to write.
I just reserve ‘integration test’ for contexts where I am testing that multiple individually tested components of my own work together as they’re supposed to when combined - not that they integrate together correctly with something else I didn’t build.
There’s a danger if you go down that path of ‘testing the framework’.
A controller usually doesn't contain any business logic, it does the HTTP part. So you test serialization, model binding, return codes, etc.
So you use a mock to check, if the framework does the expected model binding. If the values you post via JSON end up in the right properties for the service call.
a typical controller method would look like that:
There is no reason to unit test this controller, because the code is trivial. But it makes sense to integration test it, and verify the serialization and binding of Product works, if the correct status codes and content types are returned. Because that could go wrong.It is often easier to do that with a mocked service, but you can also use the real service for that. Often this would hit the database and make those tests much slower and harder to set up.