Some of the best programmers seem to do the least testing. Rather than criticise them, we should learn from them.
I have a guilty secret. Many years ago I told my manager I had tested a system when I had not.
It was not a large system -- it was an interface between mainframe systems and telex and fax software. I had been programming it for a few months. My manager asked me to do some testing. I was not really sure what he wanted, so I went away for a couple of weeks and did nothing. Then I told him it was all tested and we put it live. Thankfully, it all worked fine.
A few years ago I discussed my guilty secret with a colleague. He was a freelance contractor who was constantly in demand by my employer for the speed and quality of his work. He admitted he had the same problem too -- he felt guilty that he hardly seemed to do testing. And I found the same with another skilled contractor we used.
These programmers consistently produce high quality work. How come they do not seem to test, and get away with it?
There are a number of things that are going on.
First, these programmers are experts. They deeply understand the technology, tools and techniques that they use. Their effort is focused on meeting the real business requirements, not on the "how to" of programming.
Second, the programmers have a disambiguating mind. If the specification does not make sense, they clarify it. If more detailed design is required, they identify it and they complete it. They are mindful of edge conditions -- what goes in and out of their programs -- and make sure that these are clearly defined.
Third, and most important, they test as they go. They build test harnesses to exercise their code as part of writing their code. They do not think of testing as separate from coding.
Last, they continually integrate. They do not wait until they have finished a group of programs to put them together.
Of course the programs produced by these good programmers do need some high level testing. But they do not need more unit testing. The programs demonstrably meet their (clarified) specifications, and fit well with the programs around them.
These programmers have produced some of the best code I have seen. If you are a project manager, there are a few things that you can do to encourage this way of working.
Real programmers don't test. They don't have to. They already have.