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?
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.
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).
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. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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. :)