>finally, we can stop creating an interface for every class just to mock it in tests
Is there more information available about this? Would be great to achieve this natively without requiring Fody and friends.
Is there more information available about this? Would be great to achieve this natively without requiring Fody and friends.
And Unit tests make especially little sense in the specific service I’ve been talking about because all the logic is in the Stored Procs it calls. The service itself simply forwards that data.
Swapping out interfaces to code-gened interceptors and keeping everything else the same, doesn't look like it would improve this underlying issue at all.
You fix until tests pass. How do you know you adjusted all tests when code changes and tests stay green?
A business case can be described in code as a test. Period.
A small unit of business functionality can be described in code as test that tests that "unit". A unit test, if you will.
I don't think that the way that you're dividing out "integration tests" is a useful one.
> Wouldn’t an integration test work in that case?
Wouldn’t a test work in that case? Well, yes.
It is nuanced subject.
But say you have class A,B,C,D with mocked dependencies E,F,G,H.
There could be bugs in how A interacts with E and F that are hidden even though you have tests for A,B,C,D integrated and even unit tests on E too.
In addition, if someone comes along and refactors A,B,C,D into A',B',C',D' that have different dependencies ("Hey we are moving to microservices!") then the new integration test is different. You change test and code at the same time.
This is a problem because confidence comes from having a stable test, then changing the code and getting the green circles.
The solution (I think) is to make sure you are mocking at the level of well established boundaries. For example mock PostgreSQL. Or mock your ORM if there is a decent mock, with an in-memory version.
Then you can test end-to-end scenarios. Add a TODO, add another TODO, assert that getTodos() returns 2 results, and so on.
Instead of assert getTodos() returns 2 results when the ITodoService.getTodos() returns 2 results, and the outer getTodos just defers to it.
Then I think that parent is wrong, or rather that "it depends on what you mean by integration test" an further, this definition of "integration test" is an extremely unhelpful one that I do not advise using. And it better fits what was originally intended as "unit test". The name "unit" is not a synonym for class or method, it is your choice what the "unit" is, and a lot of the time it is best done as a small chunk of business requirement.
mocking at the level of well established boundaries such as databases and http services, is all that's needed.
You can create integration and e2e tests that aren't as sensitive but I don't really understand what people are suggesting when they say mocking is bad in unit tests.
It is irrelevant and driven by some testing evangelists
Tests are either quick or slow and may touch external stuff, thats mostly it.
Whats wrong with mocks? If they lead to scenarios where your tests are green, but app doesnt work then it sucks. Ive witnessed projects with all green tests but app wasnt even waking.
I'd rather spend time trying to learn the business, and where it's going, and why my product is useful, than mocking out some dumb part I can test a few times manually. Unit tests are super valuable tool, but not everything needs a unit test.
"Unit test" does not necessarily mean "class test" or "method test"
and always treating it as such is counterproductive.
I have done it both ways. tests coupled to every public method with dozens of mocks would not be my preference.
At work, I have better things to do than waste time on this for PR, so I create those interfaces, thankfully there are VS tools to create them automatically.
The reason this is so common is probably because code examples (including MS) often have it, so it gets followed the first time and repeated.