DEV Community

Cover image for 5 Reasons Why You Should Never, Ever Write Tests
Kai
Kai

Posted on • Originally published at kais.blog

5 Reasons Why You Should Never, Ever Write Tests

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.

Discussion (33)

Collapse
leouofa profile image
Leonid Medovyy

Testing is important, but the question is when and how much.

IMO writing tests first is a terrible idea in practice. A lot of times Im experimenting and trying to get an idea out. I like writing tests afterwards, once the idea is flushed out and I’ve decided that the code is actually worth testing.

Collapse
nombrekeff profile image
Keff

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

Collapse
jfbrennan profile image
Jordan Brennan

I do “real development” every day and writing tests first is rarely worth my time.

If you are one of the relatively few who are working off a precise functional spec, then yeah TDD makes sense, but most tasks by their nature do not have that level of clarity. Devs are creating something from ambiguity and iterating with stakeholders. Things change within the week, sometimes even within the hour. I’d like more reliable requirements upfront, but they're sometimes hard to get so writing tests first is a bit of a guessing game that ends up as wasted time.

Thread Thread
nombrekeff profile image
Keff

I totally agree.

Thread Thread
kais_blog profile image
Kai Author

It also depends a bit on what we are talking about here.

There is not one type of development and there is not one type of testing. As a freelancer doing frontend development you will work differently than as an employee improving internal software. As an indie maker who primarily builds and offers complete products themselves, you'll work differently again. And I could list many more ways to work...

Therefore, I would not say that you absolutely MUST test everything and always. It depends on the circumstances. And if it doesn't suit your work, then that's okay.

Collapse
leouofa profile image
Leonid Medovyy

I agree, testing is obv an important aspect of building a reliable application. It can save time, if used properly. Testing is a tool in a toolbox, not a religion. Healthy development culture, and code reviews can prevent hacky solutions better than any test could.

Thread Thread
nombrekeff profile image
Keff

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 ;)

Thread Thread
kais_blog profile image
Kai Author

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.

Thread Thread
leouofa profile image
Leonid Medovyy

Agreed 😎

Collapse
kais_blog profile image
Kai Author

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.

Collapse
leouofa profile image
Leonid Medovyy

At the end of the day it comes down to the problem, the programmer and how we like to solve problems.

I've seen thoroughly tested software with the code that's complete and utter crap. I've seen untested code bases that work phenomenally well, because the code provides a creative solution to the problem that is being solved.

Testing is not a silver bullet for mediocre programming.

Thread Thread
kais_blog profile image
Kai Author

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 :)

Collapse
honatas profile image
Jonatas de Moraes Junior

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?

Collapse
kais_blog profile image
Kai Author

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:

  • Write E2E test. Watch it FAIL.
  • Step down to a Red-Green-Refactor cycle with unit tests to implement necessary functionality.
  • Step back up and rerun E2E test. Watch it PASS (hopefully).

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.

Collapse
jonrandy profile image
Jon Randy

In all seriousness, I've barely ever used automated testing in 25 years as a developer. Still don't

Collapse
nombrekeff profile image
Keff

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!

Collapse
jonrandy profile image
Jon Randy • Edited

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

Thread Thread
nombrekeff profile image
Keff

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.

I think I trust my gut more readily than assuming someone got the tests right and didn't miss anything

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!

Collapse
kais_blog profile image
Kai Author

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. :)

Collapse
kracodes2325 profile image
Asad Anwer • Edited

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.

Collapse
kais_blog profile image
Kai Author

I hope it was understandable that the whole post is a joke and not to be taken seriously. :)

Collapse
kracodes2325 profile image
Asad Anwer

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! :)

Collapse
sznroe profile image
Sujan Rai

:D

Collapse
nombrekeff profile image
Keff

I did enjoy that! Though you where serious for a moment lol

Collapse
kais_blog profile image
Kai Author

Thank you! At what point did it become too obvious? :D

Collapse
nombrekeff profile image
Keff

I'm not ashamed on saying I got to this point:

Seriously though, write tests.

Just kidding, I think in the second point I kinda realized xD

Collapse
muhammadaadil50 profile image
BADSHAH

I am not fond of writing tests, but sometime if I need it eagerly then write poorest test code ever... Although I agree 100% with you..

Collapse
emil profile image
Emil

If it compiles it’s automatically correct. Always

Collapse
kais_blog profile image
Kai Author

And otherwise the compiler is buggy.

Collapse
cswalker21 profile image
cswalker21

Ah ha ha hah, ok. You got me. 😂

Collapse
inhuofficial profile image
InHuOfficial

You're silly, and I love it! 😋🤣

Collapse
kais_blog profile image
Kai Author

Thanks :D

Collapse
siddharthshyniben profile image
Siddharth

I've seen a lot of satire this week, and I'm loving it! I should write some too...