-
ARE ALL BUGS CRITICAL?
Often when you listen to people that report bugs, it sounds as if the world is coming down if it isn’t fixed immediately. But are all bugs really that serious? Is it possible that some of them actually doesn’t have to be fixed right now? That we even could put them into the backlog? There are two kinds of bugs. The ones that has to be fixed right away or the world will burn. And the ones that are annoying, but you can live with them. The first category has to be fixed immediately, obviously. But the other one can safely be added to the backlog and handled like any…
-
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…