desenvolvimento orientado a testes - Quem deve escrever os testes?

Originalmente, é dever do desenvolvedor escrever o teste, mas notei que em muitos casos / desenvolvedores maduros, esses casos não oferecem cobertura de nem 80%.
Que tal eu ter uma pessoa de controle de qualidade dedicada a escrever TODOS os testes para um determinado projeto em vez do desenvolvedor?
Existe algum contras nisso?

No Desenvolvimento Orientado a Testes, os testes devem ser escritos pelo desenvolvedor. Caso contrário, alguém que não seja o desenvolvedor está conduzindo o desenvolvimento.

Portanto, assim que você dá a tarefa de escrever testes para um não desenvolvedor, essa pessoa se torna um desenvolvedor.

Minha experiência no TDD é que escrever o código de teste geralmente é tão difícil ou mais difícil do que escrever o código de produção. Portanto, se você possui recursos capazes de escrever um bom código de teste de unidade / integração, eles devem escrever o código de produção que faz esses testes passarem.

O trabalho do controle de qualidade é realizar um tipo de teste totalmente diferente (ou seja, testes de usabilidade / integração). Eles realmente não precisam conhecer as tecnologias usadas no código.

Se você está preocupado com a baixa cobertura de código, precisa disciplinar seus desenvolvedores. Por exemplo, interromper o trabalho em novos recursos, até que a cobertura do código aumente. Algumas organizações chegam a ter um gancho de pré-confirmação em seu repositório que não permitirá o check-in de código descoberto.

Por último, mas não menos importante, no TTD 'puro', não deve haver código descoberto (desde que você escreva os testes primeiro). No entanto, existem casos (embora as pessoas discutam sobre isso) em que uma cobertura mais baixa do código é aceitável. Alguns argumentam, por exemplo, que escrever testes para getters / setters de POJOs é uma perda de tempo.

esses casos não dão nem 80% de cobertura

Isso pode ser um problema de gerenciamento.

Ou pode ser irrelevante.

Primeiro, a diferença entre 80% e 100% de cobertura é provavelmente muito cara para pouquíssimo benefício.

"Cobertura" pode significar qualquer coisa. Linhas de código, caminhos lógicos, etc. Acho que você quer dizer linhas de código (não caminhos lógicos).

Alguns caminhos lógicos são muito bem testados "por inspeção". O código é óbvio, não possui instruções if, possui uma complexidade muito, muito baixa e provavelmente não precisa de um teste adicional.

20% a mais de testes nem sempre são 20% a mais de qualidade.

Segundo. É um problema de gerenciamento. Se a gerência deseja 100% de cobertura, eles precisam implementar um sistema de recompensa que recompensa 100% de cobertura em vez de "bom o suficiente para liberar" 80% de cobertura.

Adicionar pessoal de controle de qualidade para escrever mais testes não ajudará muito.

É necessário adicionar desenvolvedores para escrever mais testes para obter 100% de cobertura de teste.

O teste de unidade IMHO não é um processo de controle de qualidade. É mais uma questão de acelerar o desenvolvimento (diminuindo o ciclo de feedback dos desenvolvedores). Isso deve ser feito pela pessoa que está escrevendo o componente (também conhecido como unidade), com foco no uso dos componentes (por outro desenvolvedor).

O teste funcional é um processo de controle de qualidade que pode e deve ser realizado por uma equipe de controle de qualidade. Isso pode ser feito pelo desenvolvedor, mas um não desenvolvedor seria melhor, pois o desenvolvedor pode não conhecer todas as maneiras pelas quais um usuário pode usar o aplicativo.

Ambos podem ser feitos de forma TDD.

TDD não é apenas sobre testes, mas também sobre design. Escrever código apenas para passar nos testes geralmente leva a um código menor e de manutenção. Se você delegar qualquer outra pessoa para escrever os testes, também estará delegando a responsabilidade de criar um bom código.

Você também deve observar que a cobertura não informará sobre a qualidade do código e não informará se as regras de domínio estão sendo cobertas.

Se você precisar de pelo menos 80% de cobertura, precisará fazer algumas coisas:

• Forneça aos desenvolvedores as ferramentas necessárias para determinar qual o nível de cobertura que eles têm - e certifique-se de que são maçãs com maçãs. Há mais de uma maneira de medir a cobertura.
• Forneça uma recompensa / incentivo para realizar essa façanha. Os programadores só farão o que acham que valerá a pena. Se a cobertura de 50% for boa o suficiente para garantir a qualidade e realizar todo o trabalho, é isso que eles farão.

Por fim, entenda que existe uma diferença entre os caminhos de execução pretendidos e os caminhos de execução não intencionais . No processo de escrever código orientado a teste, você pode ter provado que precisa de um par de instruções if independentes. Como resultado, existem testes para dois dos quatro possíveis caminhos de execução disponíveis. Adicione mais uma instrução if independente e você terá oito caminhos de execução (ou seja, está subindo exponencialmente).

Entenda que o TDD não prediz necessariamente todos os possíveis caminhos de execução; portanto, há vários testes que podem precisar ser gravados para serem concluídos, mas não são gravados porque não havia necessidade de testar esse caminho. Em resumo, o TDD não garante cobertura, mas garante que exista pelo menos um teste para provar o motivo do código que existe.