3 ms·

> At least when the controllers are all classes I can unit test them. There is normally not such a big benefit in unit testing them, as controllers should only

by andix 5y ago

> At least when the controllers are all classes I can unit test them. There is normally not such a big benefit in unit testing them, as controllers should only call some service behind. This service you can test. Controllers are better integration tested, with a mock service behind. So you actually test if your routing and response codes are picked up correctly by the framework. There is TestServer for asp.net core. It gives you a very easy solution for integration testing, if set up correctly they are nearly as fast as plain unit tests.

jameshart 5y ago
If it has a mock service behind it, how is that an integration test?
- andix 5y ago
  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.
  - jameshart 5y ago
    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’.

by andix 5y ago

jameshart 5y ago

If it has a mock service behind it, how is that an integration test?

andix 5y ago
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.
- jameshart 5y ago
  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’.