Fair enough, as long as you end up at the same spot- resonably bullet-proof code that’s easily debug-able.
I have spent the majority of my career as a “code janitor“ - retroactively adding tests to legacy code that was not built with TDD in mind. In my experience, this is an expensive, slow, short-sighted way to develop. If RGR isn’t for you, that’s totally fine! However, I do agree with Uncle Bob that your tests should cover happy/sad paths.
As the Ba’hai would say - “many lanterns - one light”. As long as we’re all moving towards the same light, I say use the lantern you’re with which you’re comfortable.
Does this apply to both backend and front-end development in your experience?
I would say it does, yes, if for no better reason then it provides documentation for the code which you have written.
That said, I agree with John’s sentiment that TDD can be sometimes be done simply to “make the numbers”. Tests should serve the code base and the developers, not the other way around.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.