This post was originally published at kais.blog.
As a software developer, there is one topic that always leads to controversial discussions. Sh...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Ah ha ha hah, ok. You got me. 😂
If it compiles it’s automatically correct. Always
And otherwise the compiler is buggy.
You're silly, and I love it! 😋🤣
Thanks :D
I've seen a lot of satire this week, and I'm loving it! I should write some too...
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..
I totally agree.
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.