>>> Face the "evil" (whatever that means) side like a man.
What? It's not a battle or a problem. Sometimes you need to get something out, or you're writing a little throwaway bit of code. Sometimes that involves a tradeoff in future maintainability/pain. It shouldn't justify never testing, but I think it's a valid reason to not religiously follow TDD.
But the article isn't about not religiously following TDD. It's about why "I don’t write any unit tests or specs". Testing isn't discontinuously one or the other. There's a huge, continuous spectrum in between the two extremes.
He said that integration tests cover the tests he needs and that unit tests don't add much, while being time consuming. And he never said one word about "spec".
The article has been edited since I wrote my comment. That was an exact quote from the article at the time. (And I'm pretty sure there was no mention of integration testing at that point, either.)
>>> “Examples” of unit tests suck donkey balls every time.
So lack of good examples imply that the whole system is useless? Yes, an example of "assert True" is useless, but just download any of the thousands of open source projects that use unit tests and look at the code.
>>> They seem to be a great way to spend some extra time doing time consuming, not very hard work.
It's not that time consuming, really. And it being easy work is a good thing. A lot of benefit for easy work!
>>> You have to think about the “evil” business side too.
Running away from your problems is never a good idea. Face the "evil" (whatever that means) side like a man.
>>> Unit tests=more code
OK, there is a difference between useless code and good code. Unit tests doesn't make your system any more complicated or harder to read. In fact, it makes your system more stable and easier to read.
>>> That is mostly because I’m a lazy-ass bastard.
Ah, so we get to the bottom of the problem.