We'll respond shortly.
I recently published the article There is no Agile, in which I stated that the principles of ‘Agile’ are nothing more than “a collection of good ideas, based on years of collective experience, for improving how we do our jobs.” As an example, consider testing. Thorough testing is a ubiquitous principle of ‘Agile;’ thus, by logical extension, writing tests is a fundamentally important part of writing software well.
In short, if you write software, and you’re not writing tests, then you’re not doing your job.
I don’t mean not doing your job like a waiter who doesn’t take your order quickly enough; I mean not doing your job like a surgeon who operates without washing his or her hands. As in completely unacceptable performance.
As a corollary, if you’re not writing high quality tests, then you’re doing your job poorly. If you don’t achieve appropriate test coverage then you’re doing your job poorly. If you focus excessively on verification, and ignore the other benefits that tests can provide, then you’re doing your job poorly.
Several authors and accomplished software writers have cataloged the ways that thorough testing will lead to better design, the ability to refactor, improved resilience in the face of changing requirements, fewer defects, etc. In order to justify not writing tests the costs would have to overshadow these advantages.
I can’t think of a valid argument for not writing tests, although I’ve heard many attempts:
In my experience, people who denounce the value of tests are nearly always people with little experience writing tested code. It’s time we stop allowing ourselves to determine how we do our job based on who has the biggest ego, who can shout the loudest, or who is the most resistant to change.
All this leads to the question that every single person reading this should be asking: writing high quality tests can be very difficult; how do we teach that?