Escrever testes de unidade no meio

O teste de unidade é 100% ou não é de todo tipo de negócio?

Eu estava navegando em meus projetos antigos e comecei a adicionar recursos, desta vez com testes de unidade. No entanto, isso é inútil se vou reutilizar componentes antigos que não têm testes de unidade?

Preciso escrever testes de unidade para todas as classes anteriores e não me incomodo, ou tudo bem apenas escrever testes de unidade para as novas coisas que estou adicionando?

Qualquer teste de unidade é melhor que nenhum. Portanto, não é um acordo do tipo tudo ou nada.

No seu caso, como o Desenvolvimento Orientado a Testes não é a norma - você se perguntará como os testes têm alguma utilidade.

Você deseja garantir que qualquer código futuro que você escreve não interrompa nenhuma funcionalidade (atual) - e é aí que seus sub-casos são úteis. Se os testes bem escritos passarem, você provavelmente não danificou nada. O próximo desenvolvedor que aparecer irá agradecer pelos testes e documentação.

O que você pode começar é se você possui uma arquitetura em camadas bem dividida, escolhe as camadas de acesso a dados e trabalha para cima (na camada da interface do usuário) com os testes. Se o projeto tiver um modelo de domínio, é o candidato mais provável para TDD, pois provavelmente terá a maior parte da lógica. Se a camada de serviço (ou lógica de negócios) estiver apenas fazendo uma chamada para a camada de Acesso a Domínios / Dados, não há sentido em fazer a camada de Serviço da maneira TDD. Esses são testes fofos e sem muito valor.

Adicionado a uma ferramenta de cobertura de código como Emma - e você pode monitorar constantemente a melhoria na cobertura geral do teste.

Eu trabalhei em uma base de código muito grande que inicialmente não tinha testes de unidade. Seguindo algumas práticas, agora (após vários anos) temos a maior parte da base de código coberta por testes.

Todo novo código deve ter testes de unidade.

Todo código alterado deve ter testes de unidade adicionados a ele.

A maneira pela qual adicionamos testes com segurança ao código antigo sem quebrá-lo é principalmente usando a seguinte abordagem básica:

Escolha uma pequena seção de código da qual você precisa alterar a funcionalidade.

1. Tente criar testes de integração no nível do sistema para envolver o código. Devido à complexidade combinatória dos testes nesse nível, esses testes formarão apenas um teste de "fumaça" para detectar os principais erros.

2. Introduza as interfaces necessárias para poder testar o código que está sendo alterado. Use as técnicas de refatoração que consistem em sequências de alterações muito pequenas que você tem alta confiança e que estão corretas. Tente usar o suporte da ferramenta sempre que possível. Você pode fazer isso, por exemplo, movendo / extraindo o método que está mudando para seu próprio objeto. Verifique suas alterações regularmente para poder reverter. Revise regularmente seus pares como você fez as alterações, percorrendo o histórico de controle de revisões.

   Tente minimizar ao máximo as alterações necessárias para interromper as dependências que estão impedindo a adição de testes.

3. Escreva testes para, na medida do possível, abranger a funcionalidade do código que você vai alterar. Faça check-in regularmente e analise todas as alterações por pares.
4. Escreva testes para a nova funcionalidade / alteração de funcionalidade.
5. Implemente a funcionalidade (este é o seu ciclo TDD normal)
6. Certifique-se de refatorar as áreas cobertas pelos testes (refator vermelho-verde).

Descobrimos que quanto mais fizemos isso, mais fácil ficou. Como toda vez que você volta para a base de código, é um pouco melhor.

Vimos uma queda maciça no número de bugs chegando aos nossos testadores de controle de qualidade. Com as regressões de funcionalidade agora quase inéditas, acho que valeu a pena o esforço para nós.

(por falta de habilidade para comentar) Eu acho que é melhor do que não testar. Nem todo trecho precisa ser testado, mas apenas o que será usado pelo programador eventualmente. Testar as funções utilitárias que você usa internamente é bom, mas não é necessário se você acessar tudo por meio de uma API limpa posteriormente.

Se o material antigo estiver funcionando bem há anos, criar os testes de unidade agora não é obrigatório, a menos que você altere algo no material antigo. De qualquer forma, escrever testes de unidade para as novas peças não é de todo inútil. As novas partes são as que têm mais probabilidade de conter erros e também são as que têm mais chances de serem alteradas ou refatoradas.

Você pode começar a cobrir seu código atual e, se tiver algum tempo para gastar, começar a cobrir a funcionalidade principal do código antigo. Além disso, você pode pedir ao seu PM um tempo extra para isso =)

O teste de unidade é 100% ou não é de todo tipo de negócio?

Absolutamente não! Comece a testar o novo código que você está adicionando. Você verá imensos benefícios fazendo isso, mesmo que alguns dos componentes mais antigos não tenham testes. Como você precisa lidar com um desses componentes ou encontrar um bug, escreva um teste. Com o tempo, você obterá mais do código antigo em teste.