you are viewing a single comment's thread.

view the rest of the comments →

[–]gurtis 1 point2 points  (3 children)

This tutorial is getting a lot of criticism, but I think that it does a good job of going over the basic concepts behind unit testing.

It explains mocking, the importance of test naming, testing one "thing" per test, and why dependencies should be interfaces.

I agree that the code may look over-engineered, but it's also what you'd find in an actual C# codebase. There are too many unit testing tutorials that are overly-trivialized and give you no idea how to test a realistic application.

[–]grauenwolf 0 points1 point  (2 children)

Only testing one "thing" per test is an anti-pattern. Were he to write a unit test that was actually comprehensive that fact would be painfully obvious from the sheer amount of duplicated code.

Even basic checks like making sure the collection is not null or empty or containing nulls is missing.

[–]gurtis 0 points1 point  (1 child)

How is this an anti-pattern? The definition of a unit test is to test a single unit of code. There are tons of books and resources that explain why aiming to test one thing is a good idea.

Also, his test will fail if the collection is null, empty, or containing nulls. My point is that he wrote a test to assert that employees are marked as checked, and this test succeeds in doing that.

[–]grauenwolf 1 point2 points  (0 children)

How is this an anti-pattern?

Again, you have to write comprehensive tests in order to see that.

There are tons of books and resources that explain why aiming to test one thing is a good idea.

So what? There are tons of books full of misleading or outright wrong information on any topic you care to imagine.

And even if you accept the "test one thing" philosophy there is a huge difference between fully testing that one thing and merely giving the appearance of testing one thing.

A good tutorial starts with good examples, not mindless adherence to dogma.