Test
-
HOW TO CREATE A TEST FIXTURE
A test fixture is used to:● Make the code less brittle. We isolate the construction from all the tests and only do it in one place, so when we add a new parameter in the future, we only have to change the test code in one place.● Makes the job of writing tests easier, we write less code because we only call a function that creates the instance, instead of writing the entire construction with all the parameters in every test.● Make the code DRY (Don’t Repeat Yourself). We only do the construction, the newing up, in one place. The code Moq is used in this example. Obviously, there’s nothing…
-
DOES UNIT TESTS IMPROVE THE ARCHITECTURE OF MY CODE?
This might sound like a silly question, but what do you use unit-test for? It is not as obvious as it sounds, given that the word “test” is in the name. It makes us believe that they are used only for testing, doesn’t it? And to some extent, that’s true. But that is not the full story. They are giving you so much more value than just that. For instance, it changes the way you write code, it changes the architecture. Writing unit tests forces you to write testable code. That makes it easier to read and understand, it tells you what it does instead of hiding things in gigantic…
-
SOFTWARE IS ORGANIC, ALMOST ALIVE, AND THE TEST SUITE IS ITS IMMUNE SYSTEM
Contrary to things made in a factory, software is never finished and put into mass production. We never stop adding features and evolving it. It reminds of a living thing. And living things needs an immune system to survive. That is what the tests suite is! Your defence against the continuous deterioration that constant tinkering brings. Software is never finished. The idea of industrial production, when we construct a thing, and then make loads of copies of it, does not apply to software. The industrial way of thinking is that when we have a need, we make a thing. If we have another need, we made another thing. For instance,…
-
UNIT TESTS ARE ACTUALLY TESTING REQUIREMENTS, NOT CODE
A unit test sees the code it tests as a black box. Its only concern is to verifies functionality. It really doesn’t care about how the functionality is realized. It actually has a much tighter coupling to the requirements, because if they don’t match, your out of luck. We test functionality, not implementation details When we write a unit test, we are testing functionality. I’ve said it many times before, but it is important to understand. We do not test code. The test doesn’t care about how the functionality is implemented. But what do I mean by that? This is my definition. When we test the code, the test-code is…
-
WHAT ARE NEGATIVE UNIT TEST, AND SHOULD I BOTHER WITH THEM?
I don’t thing anybody has missed the fact that unit tests increase the quality of the code. But then someone starts talking about negative unit tests. What the heck is that? A unit test verifies that the functionality in the code works as expected, but don’t forget the other side of the coin. Errors. And negative tests verify that your code doesn’t get stumped when an error occurs. Here are a few things that helps you write them. Stable code doesn’t break because of errors Code, like life, never works out the way you intended. There is always a lot of stuff happening outside of our control. For software, we…
-
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…