Me parece que vocês entenderam mal o que o Dieval falou.
Eu li e reli o que ele escreveu e sou obrigado a concordar com quase tudo.
E muito do que ele falou não cai em contradição com o que vocês falaram.
Se testes unitários servem como documentação e são importantes no ciclo de desenvolvimento, então eles devem ser tratados como artefatos importantes. Ele criticava justamente a postura de várias empresas de jogar os testes para os estagiários, acabarem com uma pilha de testes que não testam nada e não documentam nada. Pior do que isso, a empresa ainda usa esse teste praticamente inútil como “critério de qualidade”, na boa e velha filosofia de “passou no teste está ok”.
Nesse caso, escrever testes desse jeito não só é inútil como também uma perda de tempo. Se o trabalho desses estagiários estivesse sendo gasto em uma atividade mais útil (como até mesmo preparar café), a empresa já lucraria mais.
Um ciclo de desenvolvimento sério deve tratar o teste unitário de maneira séria. Deve se preocupar se ele realmente reflete os requisitos de negócios (quando esses requisitos podem ser testados de maneira unitária). Deve garantir que o desenvolvedor entre em contato com o teste e corrija o código (ou muitas vezes o teste). O time também deve ter a preocupação de, em caso de um erro descoberto, corrigir o teste antes do código.
E em parte eu também concordo com o fato de que numa equipe experiente a validade do teste unitário cai um pouco. A equipe experiente refatora bem, modula bem, costuma a testar asserções, exceções e preocupa-se com diversas situações de erro naturalmente. Entretanto, a equipe experiente valoriza o teste unitário e sabe seu valor antes uma refatoração.
Em resumo, não adianta fazer teste para inglês ver. Mas também não adianta cair no conto da carochinha dos vendedores de JUnit e começar a achar que o teste unitário é a solução dos problemas, que ele vai mudar a forma dos seus programadores pensarem e que basta te-los para se ter qualidade. Eles são bons? Sem dúvida? Importantes? Muito. Mas são só mais uma das partes do ciclo de desenvolvimento, que tem várias.
O que eu discordo do Dieval é que acho que numa equipe experiente a importância do teste unitário cai um pouco, mas não muito. Seria o suficiente para arriscar um módulo do sistema sem eles em caso de pressa, e faze-los depois, só depois da release sair. Eu não reduziria ele a percentuais tão baixos. Agora, não dá para só bater em cima dessa tecla, sem levar em conta todo o resto que ele falou, que achei extremamente válido.
E até me ajuda quando eu precisar defender os principios do Agile assim como você e o CV estão fazendo muito bem. 