The Secret of Unit Testing I Learned by Failing

Download source code ► / zoranhorvat
Join Discord server with topics on C# ► codinghelmet.com/go/discord
Enroll course Beginning Object-Oriented Programming with C# ► codinghelmet.com/go/beginning...
Subscribe ► / @zoran-horvat
Here is the riddle for you to solve: Suppose there is a method that creates and populates a collection. There are two possibilities before you:
(1) Assert that the collection has the exact expected content, or
(2) Only assert that its size is as expected.
Which of the two unit tests is better at testing that method?
I will argue that checking the size of the resulting collection is, by all means, sufficient. Whatever you add to the unit test will not improve your chances of isolating bugs. If you disagree, then I will kindly invite you to watch this video and learn about one of the most frequent fallacies in unit testing.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️COPYRIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
#csharp #dotnet #unittesting

[@coderider3022]

My last company has a terrible fixation with verbose, brittle and superfluous tests that added no value. 1 small change to the code, disaster strikes the test projects! Users story.. 1 pt to change code, 2pts to update unit tests. Crazy.

[@sunnypatel1045]

Great video. What your thoughts on test doubles vs mocks and which one would you choose when working with ef?

[@marcosborunda7607]

Mocks are a type of double, maybe you meant mocks vs stubs? Anyway if possible you should try to substitute the whole layer that uses EF and test only the logic that doesn't touch your DB. Don't try to mock DbContext and neither try to test against a memory database they simply won't behave the same and you'll get false positives.
Of course the queries and logic that you add to your EF layer is important and prompt to errors, so you'll likely want to test it too, so I would recommend to add "integration" tests that interact with a real database.

[@sunnypatel1045]

@@marcosborunda7607 exactly. I love using mocks with nsubsitute. However fakes suppose to be better and brings more benefits than a mock. blog.ploeh.dk/2023/08/14/replacing-mock-and-stub-with-a-fake/
The only issue I see is you adding to many files and maintaining. As for mocks you dont

[@fifty-plus]

Using fixture data, as opposed to hard coded values, is a valuable approach to add entropy to your test assertion context.

[@zoran-horvat]

That is not entirely true.

[@ghevisartor6005]

this reminds me of your video Kill Anemic Domain Models with Encapsulation: The Hard Part, there is no point in ordering the authors inside the Book.CreateNew method, it should be the Book.Authors property getter doing the ordering

[@zoran-horvat]

That is correct.

[@chaitanyapramodh16]

Please suggest me how to make test cases cover for store procedures of context.fromsqlraw(string) in repository layer

[@Rick104547]

Testcontainers are your friend here. Don't fall into the trap of trying to use mocs or fakes when testing such functionality.

[@sunnypatel1045]

Trust me do not go for in memory shit. Rick right test containers is the way

[@elraito]

Man. I wish there was better resources about testing. Stuff you covered in this video just flew over my head.

[@zoran-horvat]

I'm not following. Is that good?

[@elraito]

@@zoran-horvat video is good. I just lack the foundational knowledge to do any testing well

[@zoran-horvat]

@@elraito Testing is harder than application development, though many teams see it as a side activity. The consequence is that they produce tests of low quality which often act as an impediment in further application development - a double damage.

[@adambickford8720]

@@zoran-horvat Living this now. We have so many mocks that changing an implementation almost certainly requires updating the mocks.

[@zoran-horvat]

@@adambickford8720 I've been there and seen it all. In my case, I figured (through a lot of pain) that I was literally micromanaging my classes with mocks and needlessly precise tests.
I cannot say if that is the case in your project, but in time I reduced the use of mocks by a factor of 10 by only seeing where I overused them.

[@lettuceturnipthebeets790]

I've heard people say that unit tests are overrated and integration tests should be dominant in a project, what are your thoughts?

[@zoran-horvat]

I agree that integration tests are essential. Nobody will use a class, but the whole, integrated application, and so you should be able to assess its quality with integration tests.
On the other hand, I don't see unit tests as overrated. I rather see them as too stringent, too tightly bound to implementation, and overly detailed. They often impede further development because of these properties they often have.

[@Rick104547]

Really depends on the context but generally in my experience (mostly rest api's) there's way too much unit tests (with extensive mocking) and not enough integration tests.
I believe covering every endpoint with a couple integration test saves you so much trouble, best thing is you write them once and they only break when functionality actually changes. Unit test can then be used to zoom into complex parts of your app.
Webapplicationfactory and Testcontainers makes it really easy to write integration tests btw. They can be pretty speedy as well, almost approaching unit tests (order of 100ms).

[@zoran-horvat]

@@Rick104547 Your comment is summarizing that very well.

[@sanglin9387]

you create a record but it is return the primary key ? what if you update the record and fail?

[@Rick104547]

​@@sanglin9387 then there should be a test that fails since there should be atleast a test covering your update endpoint (assuming we have an web api here)

[@SCHCOMM]

can a new developer who is not yet familiar with the domain be considered an enemy?))

[@zoran-horvat]

Technically, yes. That is why you should never let a newly onboarded member roam the code base and make unattended changes.
Pun aside, that is a very important aspect of software development. I tried to pass this between the lines in the video: unit tests will not save you from developers who write random code. You must address that problem at its root, rather than try to cover up for it using such tools as automated tests.

[@SirBenJamin_]

The code here seemed a bit tied to EF here. In general, you wouldn't have a authors collection that was an ienumerable, it would be a readonly collection, so comparing for sequence equality makes sense to me. If I saw a unit test where people were just testing count, that would suggest to me something isn't right. I would expect the collection I pass in to be copied and remain in the same order.

[@Bleppacus]

This is not unit testing, as it seems to not test anything.

[@zoran-horvat]

So, you didn't get the point...

[@sashbot9707]

Terrible advice for me. I have learned the hard way that testing for the size is not sufficient.

[@zoran-horvat]

Fine. Then come the questions about your process.
The first question: how would the implementer guess how many items to put in to satisfy the test?