What's correct unit testing?
In codebase I am working on some devs are writing unit tests that test Controller level - tests if endpoint returns 200 for example. They mock repository/DAL layer and ignore service layer.
Wouldn't the correct thing to do be just mock the service layer and then test service layer functions separately and mock repo layer in that test?
15 Replies
You'll find a lot of opinions on this topic. For an aspnet core project my goal is to leverage the web application factory as much as possible, see examples at https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-8.0.
From an isolated unit test perspective, I only want to test critical business logic. The things that are both provable, and represent a market advantage.
Integration tests in ASP.NET Core
Learn how integration tests ensure that an app's components function correctly at the infrastructure level, including the database, file system, and network.
there is nothing inherently wrong with testing the controller, when it is tested isolated (not testing the service at the same time). Only counter-argument is that the controller ideally should contain VERY little business-logic, which makes it less of a candidate for the more important metric: cover as much of your business (and I'm not talking 💲, but what the software is actually supposed to do) as possible.
If your controller contains a lot of business, then its also a bad sign for the structure of your code.
One other point is: the more you test, the more drag you put on development. If you need to change your test every time you touch your app, it will slow you down. So more is not always better. Put more effort in testing the right things, rather than testing ALL the things is beneficial.
In the end I decided to do integration testing on controller and mocking the repo layer. Mostly checking for http status responses based on inputs - showing what is the endpoint intended for essentially.
Then doing additional unit tests for service (business) layer only in case if there is some business logic validation or additional logic that isn't tested in controller e2e tests.
Then unit tests on DAL - if migrations went through correctly.
I felt that doing unit tests on controller layer and mocking service layer was kind of pointless as I wouldn't really be testing anything, would just be adding lines of code and exactly as you said - it would put more drag on the development.
@Nox 🌺 ^^ look at this dude winning it right here.
Not necessarily true about the controller containing no business logic.
The controller is usually the orchestrator of all of the service calls and data access and data manipulation needed to complete the endpoint.
None of those things should depend on one another; the controller is the glue that holds it together
I mean about testing
@Nox 🌺 we'll never change hearts and minds about the other.
there are definitly architectures that work like this. doesnt mean i have to like them 😄
all im saying is: test your important logic. when it is in the controller, you have to test the controller!
think that the controller can be aptly tested with e2e/integrationThat's a deep rabbit hole.
<a:pocky_d_rabbit_hide:788223919139979264>
@Nox 🌺 okay that's the last one I'll say
<a:pocky_d_bunnipatpat:734603029369585756>
Today
wait till one hour is passed, then "today" has changed for somebody
it can*