In my opinion, if you feel you are not getting value from your tests, then you might not be utilising them correctly.
I used to not write tests, and it sucked. I would test by hand, and then find out that I had missed some obvious checks.
Writing tests forced me to think of all possible scenarios beforehand, and actually discover issues early on before deployment. In addition, when I change some code, I can very easily confirm its impact with the click of a button, without affecting the environment.
It makes life so much easier on the long run, but requires long term vision.
I tend to ignore most of the talk about how one should test, and write tests which are most likely to catch bugs caused by seemingly innocent code changes.
I try to base my starting point not on some cultist ritual, but purely on utilitarian value: "Will any test go red if I purposefully add bugs?"
Sometimes I neatly use TDD, sometimes I write code first.
For every method, I try to simply think "If some lumbering oaf in the future (probably me) were to quickly adjust any of the methods I'm calling here, what could go wrong?"
In practise, that means I often write in a semi-TDD-style for the method I'm currently adding, while trying to solidify the methods it depends on with some extra weird edge case tests.
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 my opinion, if you feel you are not getting value from your tests, then you might not be utilising them correctly.
I used to not write tests, and it sucked. I would test by hand, and then find out that I had missed some obvious checks.
Writing tests forced me to think of all possible scenarios beforehand, and actually discover issues early on before deployment. In addition, when I change some code, I can very easily confirm its impact with the click of a button, without affecting the environment.
It makes life so much easier on the long run, but requires long term vision.
I tend to ignore most of the talk about how one should test, and write tests which are most likely to catch bugs caused by seemingly innocent code changes.
I try to base my starting point not on some cultist ritual, but purely on utilitarian value: "Will any test go red if I purposefully add bugs?"
Sometimes I neatly use TDD, sometimes I write code first.
For every method, I try to simply think "If some lumbering oaf in the future (probably me) were to quickly adjust any of the methods I'm calling here, what could go wrong?"
In practise, that means I often write in a semi-TDD-style for the method I'm currently adding, while trying to solidify the methods it depends on with some extra weird edge case tests.