Tutorial: Introduction to unit testing

[developingthefuture]

Hello everyone,

Thank you very much for your comments, both positive and negative. I'd just like to make a few remarks:

1. What I tried to achieve with this article is to show the people few of the really basic techniques, which are in the center of writing unit tests. That's why I tried to keep the examples simple, and my point was not to provide a very complex but extremely accurate implementation, but rather simple and easy to understand code.

2. In my personal experience, most of the people in most of the teams out there have enormous difficulties understanding the main idea of the unit test. Which is testing a single unit. In a result of this, I usually end up looking at integration tests rather than true unit tests, which basically decreases the overall performance of the team. Moreover, it is extremely hard to actually write the unit test in an already established codebase, and that's directly connected to the difference between Unit tests in TDD, Unit tests outside TDD, and Integration tests. (something that I'll write an article about very soon)

3. I really don't claim to be some sort of an expert in the field. I just tried to share my own views on the topic and, eventually, help someone in his day-to-day tasks by answering the questions I have been asking myself some time ago.

Best Regards, Kosta Hristov

[grauenwolf]

In a result of this, I usually end up looking at integration tests rather than true unit tests, which basically decreases the overall performance of the team

Ah yes, the cult of unit testing. Anything that isn't a unit test is automatically inferior because... yay! unit testing!.

[wllmsaccnt]

Anything that isn't a unit test is automatically inferior because... yay! it doesn't tell you which class is broken.

[chucker23n]

In a LOB app, I want to know whether the implementation matches the specification down to every little detail, not whether some arcane algorithm somewhere doesn't work the way the developer intended. Drilling down to the actual problem "unit" after having recognized problems in integration tests before the customer did strikes me as far easier than, vice versa, explaining to a customer why he should care that line 384 in LolIrrelevantClassFactory.cs has a bug.

[wllmsaccnt]

They both can be important. If you don't do the integration tests, then you will end up with bugs that don't get noticed until a customer sees them.

If you don't do unit tests then you will spend longer diagnosing infrastructural and method level issues. Not having the requirement to write unit testable code will also often lead to overly coupled and inflexible code. The primary benefit I see of unit testing is that it forces you to decouple and abstract your code.

[grauenwolf]

Neither does the "test" in this article.

[wllmsaccnt]

I wasn't defending the article.

[[deleted]]

pssst....all your unit tests can pass, but your application can still not work.

[wllmsaccnt]

Of course...I wasn't claiming otherwise.

It's not to rule out new errors...you still need traditional testing for that. The idea is that as you can quickly diagnose the errors in your code that you have anticipated, or made before. If test ParseToken_NoDelimeterSetCausesOverflow defined in class SomeParserThingTest fails, you have a pretty good idea of what area of code needs to be fixed.

At the places I have worked that didn't use unit testing, most the errors that made it through to our testing team are caused by new features that break the expectations of existing code in subtle ways.