This post was originally published at kais.blog.
As a software developer, there is one topic that always leads to controversial discussions. Should one write tests or not? While there are always questionable experts who argue FOR writing tests, I have the definitive answer. Don't.
Many terrible things happen once you start testing your code. So I prepared a small, incomplete list to show you why you should never, ever, write tests:
You would start to question your code
What audacity. If you wrote tests, which of course you won't, your code would be questioned. Does it work as expected? Of course it does. Besides, there's no point in catching catastrophic bugs early, after all, they only ever happen in someone else's projects.
Your code would be clearly defined and well designed
You're not an art student, are you? Then what do you care about design? If you ever test parts of your code, you would be forced to clearly define what the code is responsible for. So you would focus on what is essential. With that you take away the possibility to sneak in code that nobody needs and nobody uses.
You would have to write less code
Testing can lead you to write less code. After all, you only ever implement so far that the tests pass. And less code means fewer lines of code. Who can brag about having worked on gigantic projects when there aren't that many lines of code? Besides, we're still in the 2000s, somehow, and we're billed on the basis of lines of code (LOC). Never reduce the lines of code. Ever.
You would save countless hours that you could normally waste on debugging or maintenance
This point is really critical. If, strangely enough, you are not paid by lines of code, then at least by the hour. With testing you would save many hours. How awful is the idea that you suddenly have time for other things and on top of that the certainty that the code behaves as expected. Scary.
You would enable others to understand your code and collaborate with you
I don't really need to write that much about it. Why would you even want to do that? With tests, your code is suddenly documented and much easier to refactor. Not good. If you are no longer the only one who can work on a project, then you will definitely be replaced immediately.
Final Thoughts
There you have it. My list of reasons why you should definitely not write tests. In summary, tests have only drawbacks and you should definitely follow me on Twitter if you want to learn even more about how to avoid being a good software developer.
If you want to convince other software developers why they shouldn't write tests, feel free to share this post with them.
Seriously though, write tests.
This post was originally published at kais.blog.
Top comments (29)
For prototyping and testing stuff I would say yes, tests slow you down. For real development it's the contrary. They might slow you down at points, though in the big scheme of things it will make you work faster and safer.
A point that is often brought up in testing, and fits quite well this thread, is that, it slows you down a bit. And slowing down makes us think a bit more, preventing fast and hacky solutions just to get it done. Though it's a bit controversial this
I agree, though I've had some nasty bugs pass unnoticed by 3 people in a review, that could've easily been prevented with proper tests (I say proper, as there were tests, but not testing the correct things though)
I'd say that the "best" solution would be a healthy combination of good practices, tests, reviews, and any other mechanisms we see fit for the project. And good management of course ;)
Many different people, many different projects, many different circumstances. There is no one-size-fits-all solution. Therefore, there are many different approaches and not only one of them is successful. I tend to think that testing is useful, but testing alone is not the key success factor.
I'm not a big fan of TDD, I believe you should at least know what you are coding and be able to run the code and verify the outputs by yourself prior to merging it. TDD somehow takes away this responsibility from the programmer in my opinion. However, I do advocate for E2E tests, as they are more broad and written from the point of view of the application user, and probably will be written by someone else rather than the one who actually coded that piece of software that's being tested.
Having them both in a project would be ideal, but if I have to choose - and more often than not I have to, because deadlines - I believe E2E produces more results at a lower time investment. But that's just a feeling, I have no numbers unfortunatelly. What do you think?
It always depends a little bit on what you're actually doing. I generally tend to prefer TDD. However, you can also distinguish between the inside-out or outside-in approach. In the outside-in approach, you would - similar to what you describe - first write the E2E tests and then implement the functionality with the help of unit tests. You have a two-level loop, so to speak:
I can understand how this might seem to slow you down. It certainly will in the beginning. In the long run, however, the added security ensures that you can make changes with confidence. In addition, you think a bit more about the design before you implement something. This can also have many advantages.
It depends. Partly it is a hindrance in an experimental phase, yes. However, I wouldn't go so far as to say that tests first is generally a bad idea. Rather the opposite. But as always, there are exceptions.
In all seriousness, I've barely ever used automated testing in 25 years as a developer. Still don't
I hope this doesn't come out to harshly, I'm just kind of courious, as I've seen many "older" or oldschool developers if you will, ignore or discredit tests, even though they've proven quite effective if done correctly.
So as you feel like an experienced dev, from what I've seen from you. What are your reasons behind not testing? Is it habit? or are there valid reasons behind it?
Cheers! And hope it did not come out to harsh!
Not sure really. Probably a combination of habit and a belief that you should try to fully understand the code you're working on before you change it. I think I trust my gut more readily than assuming someone got the tests right and didn't miss anything. Almost all of the time I understand the implications of what I've changed, and know exactly what few little things I need to check still work - and I usually have devised my own ways of checking those. The times when I don't fully understand the implications, I use as opportunity to further my understanding of the system by looking into it in more detail - or discussing it (if possible) with whoever wrote it.
The extra layer of automated testing just feels like extra work for no real benefit. Development over the time I've been doing it seems to have added many layers of tooling to make things 'easier' for developers, whilst at the same time distancing them more and more from a direct "hand's on" approach to working with, and understanding the code.
My take on this probably also stems from mainly having worked solo or in very small teams throughout my professional development experience. I'm also entirely self taught, and have probably gotten used to figuring out my own way of doing things. To this day, I still much prefer writing the code for as many things as possible - deferring to libraries only when absolutely necessary. Slower maybe, but a massive sense that you've actually built something rather than just joined together some pieces of other people's work. Yes, I know if you take that to it's logical conclusion I should be building my own hardware, writing my own OS etc.... and I obviously don't do that, but I prefer to feel like an architect rather than a bricklayer where possible
That makes sense, thanks for taking the time to explain it! I find these conversations fascinating.
I totally get your points, and have felt that way for many years. I've just started using tests over the last 2 years or so. And I still only use them at work (mostly), on personal projects I don't usually use them. I prefer your approach, as it feels more fun, and allows me to focus on the tasks at hand. This, as you say, makes you have a really good understanding of the project and the consequences of changing something.
That's a really good point, tests can sometimes be deceiving, they make you feel so safe you might not even think about the consequences of performing a change (just because there are tests).
Again, thanks for the response!
I wouldn't say that you should definitely write tests in 100% of the cases. Besides, it always depends on what you're doing in the first place. However, I tend to test almost everything and can only recommend it. :)
:D
I did enjoy that! Though you where serious for a moment lol
Thank you! At what point did it become too obvious? :D
I'm not ashamed on saying I got to this point:
Just kidding, I think in the second point I kinda realized xD
The subject is definitely opiniated and these are good points but saying, "You're not an art student, are you? Then what do you care about design?"
If only It there was a way to teach the difference between design and art which was as simple as knowing the difference between Science and Arts... Oh wait.
I hope it was understandable that the whole post is a joke and not to be taken seriously. :)
Definitely my man, but the statement that I pointed out is one a lot of people get wrong, and can continue to do so. Just pointing it out for this sake, you write amazing! :)
I agree with you there. Testing alone cannot make up for everything. And if you test wrong, it will make things worse. I'm not a total hardliner on this either. The post was just meant to be a bit funny :)
A major disadvantage of Class-Oriented programming is that the actual execution path is not known until runtime, therefore the only way to check for correct behaviour is to test for it, after the fact. Hence the obsession with testing has grown as our oo systems have grown in their unpredictability.
If you have a system that is developed by specifying the desired behaviour, in a simple sequence, then the test and the code are virtually the same. The predicable execution path would result in a code walkthrough being sufficient to cover all the options, and a basic sanity check "did it run" would be all you would need to test.