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