But there are multiple ways to return a file type. There are also multiple ways to define a route. You can name the method item[] GetItem() or use attributes [HttpGet] item[] Items().
If you do integration testing, you verify what will be returned in the end to the caller over http. For that you don’t need selenium. Just use testserver, it’s just a few lines of c# Code.
Unit testing and integration testing are not mutually exclusive. I use both. I also want the feedback from tests/build of what I am developing to be as immediate as possible. Failing early with a test that takes a second to spool and run with a message like "expected File got Content" or whatever is more valuable than waiting for a much longer test for the same (or more obscure due to depth of stack that will need a debug session) message.
TL;DR: Running an entire webstack to test trivial things is waste.
> Just use testserver, it’s just a few lines of c# Code.
Orthoganol metric is orthoganol.
await Task.Delay(TimeSpan.FromHours(1));
TestServer is great. And if you use Alba[1], it gets even better.
I want tests to assert that I return a file type. Theres method on the base controller for doing that. It, too, is protected. So I need to wrap my controller in a test.
Need to assert that the response differs based on the content of a header, or a cookie? Need to use test the controller.
etc.
The basest of assertions I want tested is that the controller returns/uses the right view. That _should_ be trivial but no. Instead I must rely on a super heavy integration test, or worse, a selenium or other test that requires a user-agent and actual webserver, when all I want to is to assert that "View X" is returned for "Scenario Y"