Developers should not write tests for their own code. At least not alone. The first time I heard about TDD I thought it was the most lunatic idea I had ever heard but since then we’ve gotten pair programming and that takes the gold trophy for lunacy.
The reason is as simple and obvious as could be: blind spots. The same blind spots we had in development e.g. nonstandard cases we didn’t consider, will show up in our tests as well.
I’ve had the experience many times in my work; I finish a feature, test it, and it seems unbreakable. Ask a coworker, who hasn’t looked at my implementation, to give it a roll and he manages to break it in less than a minute.
Sorry, people, but this is so self-evident that I wrote one of my first Medium articles on this very notion: Test-Driven Development is Fundamentally Wrong
As for unit tests there is an unmistakable fanaticism at work here, a purity-cult that does us no good. If I do write unit tests they are for public entrypoints only, I think writing a unit test for a function so small and simple that it couldn’t be broken before the Throne of God is obsessive. Yet I have had a dev lead who insisted that we should do exactly that (the same lead added capital letter and periods to all my tracelogging text; do the math here).