Editorial note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there have a look at their offerings, Prefix and Retrace.
If you enjoy the subject of human cognitive biases, you should check out the curse of knowledge. When dealing with others, we tend to assume they know what we know. And we do this when no justification for the assumption exists.
Do you fancy a more concrete example? Take a new job and count how many people bombard you with company jargon and acronyms, knowing full well you just started a few hours ago. This happens because these folks cannot imagine not knowing these things without expending considerable mental effort.
Why do I lead with this in a post about unit test frameworks? Well, it seems entirely appropriate to me. I earn my living as an IT management and strategy consultant, causing me to spend time at many companies helping them improve software development practice. Because of this, I have occasion to see an awful lot of introductions to unit testing. And these introductions usually subconsciously assume knowledge of unit testing.
“It’s easy! Just pick a unit test runner and a coverage tool, and get those setup. Oh, you’ll also probably want to pick a mocking framework, and here are some helpful Nuget packages. Anyway, now just write a test. We’ll start with a calculator class…”
Today, I will do my best to spare you that. I have some practice with this, since I write a lot, publish courses, and train developers. So let’s take a look at test frameworks.
What Are Unit Tests?
Thought you’d caught me there, didn’t you? Don’t worry. I won’t just assume you know these things.
Let’s start with unit testing in its most basic form, leaving all other subjects aside. You want to focus on a piece of functionality in your code and test it in isolation. For example, let’s say that we had the aforementioned Calculator class and that it contained an Add(int, int) method. Let’s say that you want to write some code to test that method.
public class CalculatorTester
public void TestAdd()
var calculator = new Calculator();
if (calculator.Add(2, 2) == 4)
No magic there. I just create a test called “CalculatorTester” and then write a method that instantiates and exercises Calculator.Add(). You could write this knowing nothing about unit testing practice at all. And, if someone had told you to automate the testing of Calculator.Add(), you may have done this exact thing.
Congratulations. You have written a unit test. I say this because it focuses on a method and tests it in isolation.