You test "service"/"handler" classes that handle those requests.
If you want to test controllers, then you write E2E tests that send HTTP requests
Here's some example of how it might look like
https://docs.microsoft.com/en-us/aspnet/core/test/integratio...
Don't bother writing the testcase that asserts that if the controller is called with a valid body, it calls the right service and passes on the request data. Write the testcase that asserts that if it's called with a body that's way too big that it throws the appropriate 400 exception, though.
One of the biggest problems with web frameworks which let you configure a lot of stuff like caching, auth and parameter validation using attributes, DI, or magic syntax, is that often the only way you can verify those behaviors are in place is with integration tests. And integration tests for failure modes are hard to write, so they don't get written. Which means it's easy to deploy a service which, say, is supposed to respond with stale cached data if a dependency is unavailable - but it actually doesn't because nobody was able to express a test case that verified that the controller caching attributes actually work the way they thought it did.
This way you can test those fancy things, but I agree it's kinda "hard" to get it working for the first time
Also depends how many pages do you want to test with Selenium - if you want to test e.g 5 pages, then it'll be fast enough I guess.
There are a few tricks/configurations that make Selenium significantly faster - https://stackoverflow.com/a/57720610
A lot of is also on how do you write your "testing infrastructure" - maybe you could reuse engine/browser instance? execute tests parallelly?
There's also alternative to Selenium by Microsoft: https://github.com/microsoft/playwright
AFAIK it's way more reliable than Selenium (false errors)
__________
Overall you can still start application inside tests with different startup, without Selenium and send http requests, so you'll have end-to-end tests done fast.
The waste I am referring to is time it takes to get that feedback whilst the work is being actively developed.
A simple feature of a controller (to borrow someone else's example) is to change the response based on an attribute's configuration. It is wholly astonishing that one needs a _web-server_ to test that.
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"
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.
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));
I was always having great difficulty testing ASP.NET MVC controllers given the use of completely closed off, cyclical dependency, sealed class, properties like HttpContext.
Helper libraries made it somewhat easier to set them up but they were always heavy tests as a direct result of the large object graph needed.