-
THE INS AND OUTS OF UNIT TESTING A BLACK BOX
A unit test sees the System Under Test (SUT) as a black box. That means that it doesn’t matter what the code inside the class or function looks like, it only matters how it manipulates the data. And the way you judge that is only by the data that goes in and out of the function. Never ever ever by looking at the code. There are four ways that you send and receive data with. 1. The in-parameters of the function you are testing. 2. The return value from the function you are testing. 3. The parameters that are used in internal calls to functions outside your SUT. The data…
-
TEST DRIVEN DEVELOPMENT
History We’ve all heard of waterfall development, you know, first we make plan, then we do the architecture, when that is done, we start coding, after that we test and fix bugs, and lastly, we deliver. And then the clients are not happy with what they got 🙂 The problem with this is that the users will have to wait until the entire project is finished before they can see if it is what they wanted. And the same goes for us developers. We have to wait until we’re finished, then the testers are finished, before we are told if there are any bugs. And even longer before the users…
-
TESTS ENABLE CHANGE!
Unit tests are about facilitating change! Yes, tests find errors in the code, and it is nice to know that your code is working when you have delivered. But that is just a fraction of the benefits you get from tests. The biggie is that you can change your code and still be certain that it does what it’s supposed to do. Code is always evolving. From the first line you write, and never stops. And I don’t just mean that you refactor your functions. That too, obviously, but all the way up to really changing the code, breaking it up and repurposing it totally by reusing what you have,…
-
HOW TO UNIT TEST WITHOUT TESTING EVERYTHING
This article is about how you verify only the behaviour of the function you are writing and not include all the other code that the function calls. To isolate the behaviour from the rest of the application, focusing on doing that right. Keeping it simple, clear and understandable. But how do you avoid executing the code that is called from your function? To explain that I have to show you another thing first:Dependency Injection. Have you ever heard of SOLID code? Principles that helps you write good code. It is an acronym that stands for: Single responsibility principle Open-closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle I…
-
HOW TO WRITE A UNIT TEST
Let’s start with making this one thing perfectly clear. Unit tests validate behaviour. NOT code. Sounds simple enough, but is it? To start with, the function you test is a black box. When you write the test, you don’t know what the code looks like. And that is important, because the reason unit tests exists is to tell you when your code stops doing what it is expected to do. It doesn’t matter how it does it, or how many times you change it, as long as it delivers the correct result. They are not a code review. Which means that you are free to refactor the s**t out of…
-
IT IS BORING TO TEST!
We’re developers. We want to be creative, we want to solve problems. That’s what we live for. But let’s face it, testing is the opposite of coding. It is just a big repetitive task. It is tedious. Unfulfilling. It. Is. Boring! Sure, you run the code that you are working on. Even single step it and verify that it works. But do you ever think of the rest of the code? What if you just move the counter in here, except that you forgot that it should be increased in that other leg of the if too. Or what about that other class that calls this one, that relies on…
-
ARE INTEGRATION TESTS REALLY THE BEST WAY?
Do you write integration tests? Do you enjoy doing it? No? Thought so, me neither. Integration tests are inherently more complex than unit tests. They have to be, they test so much more than just that single piece of functionality that a unit test does. Setup is more demanding because there are more execution paths to consider reaching the goal of the test. And that is also one of the major problems with them. To have confidence that they don’t let bugs through you need coverage. And that takes effort. As soon as you start combining things complexity rise and that means more tests. The thing is, combining objects gives…
