Hacker News Reader

> 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.

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

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’.

> At least when the controllers are all classes I can unit test them.

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.

But why? generally you don't test controllers directly.

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...

If there's any critical behavior you're reliant on the controller (and, in frameworks like this, its attribute-driven configuration) to provide for you - throwing exceptions for bad requests, authentication or authorization, returning particular cache headers for particular response cases... I'd recommend looking for some way to write tests that, in isolation, go some way to let you assert those behaviors.

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.

For Selenium tests I've been setting up an actual instance of application in test with different Startup (e.g sqlite instead of real database) and running at different port

This way you can test those fancy things, but I agree it's kinda "hard" to get it working for the first time

and wasteful. Starting up selenium et al is painfully slow compared to tests that run in <seconds.

While I do agree, then you don't have to run Selenium tests on your PC, but let it be done by e.g ci/cd

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.

Relying on CI server to run tests is even slower :) Note I am not stating "don't use CI" as that is still an invaluable tool.

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.

Controllers still control, believe it or not.

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"

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));

Is just one line of c#. Doesn't meant it's going to run any quicker.

TestServer is great. And if you use Alba[1], it gets even better.

[1]: https://jasperfx.github.io/alba/guide/hosting.html

In ASP.NET Core the HttpContext is very mockable.

And is very much appreciated.

> At least when the controllers are all classes I can unit test them.

So I've literally just jumped into this world, having never touched asp.net or similar before.

I looked into how to test the controller side of things, and came across this[1] post arguing that unit testing controllers weren't as useful as integration testing them.

Integration testing would definitely be useful, and something I will do, but I assume also a lot more time-consuming so perhaps not something we could do on a per-commit basis.

Would highly appreciate views on this topic.

[1]: https://andrewlock.net/should-you-unit-test-controllers-in-a...

Unit tests are valuable if you are doing some sort of "computation". If all code in question is doing is plugging x into y, then unit tests are useless and integration tests are where the payoff is.

If you have code that does both plug and compute you should refactor them so that computing and plugging don't happen in the same place. Doing so will reduce instances of hard to test code.

In general controllers are plugging code not computing code, so integration tests tend to be the more appropriate choice.

Integration testing as im used to it takes less time to write than unittests since you need to spend less time mocking things (mainly just mock external requests). Of course the initial setup requires more time but there are many readymade examples you can copy from. For example the official documentation.

https://docs.microsoft.com/en-us/aspnet/core/test/integratio...

> At least when the controllers are all classes I can unit test them.

You can usually very easily transform lambas in function, so testing shouldn't be a problem.

But if I'm not writing my controllers using inline lambda syntax, but as functions in classes in a controllers directory,, what's the value of this minimal route declaration syntax over a 'heavierweight' solution that... also puts my controller declarations in methods of classes in a controllers directory?

Lambas, the famous Elvish mathbread?

>At least when the controllers are all classes I can unit test them.

Do what on "controllers"???

heresy