Escrevendo testes unitários no meio

14

A unidade está testando 100% ou não em 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 acaba sendo inútil se eu estiver reutilizando componentes antigos que não possuem testes unitários?

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

    
por Lionel 17.12.2010 / 10:25
fonte

6 respostas

14

Qualquer teste de unidade é melhor que nenhum. Então não é um negócio de tudo ou nada.

No seu caso, como o Test Driven Development não tem sido a norma, você vai se perguntar como os testes são úteis.

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

O que você pode começar é se você tem uma arquitetura bem dividida em camadas, pegue os níveis de acesso a dados e trabalhe para cima (em direção à camada de interface do usuário) com os testes. Se o projeto tiver um modelo de domínio, é o candidato mais provável para o 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 nível de Acesso a Domínio / Dados, não há motivo para fazer a camada de Serviço na forma de TDD. Esses testes são fofos e não têm muito valor.

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

    
por 17.12.2010 / 10:29
fonte
3

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

Todo o novo código deve ter testes de unidade.

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

A forma como adicionamos testes com segurança a códigos antigos sem quebrá-los é principalmente usar a seguinte abordagem básica:

Escolha uma pequena parte do código que você precisa para alterar a funcionalidade de.

  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 só formarão um teste de "fumaça" para detectar grandes erros.
  2. Introduza as interfaces que você precisa para poder testar o código que você está alterando. Use técnicas de Refatoração que consistem em sequências de mudanças muito pequenas que você tem alta confiança 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 periodicamente como você fez as alterações, passando pelo histórico de controle de revisão.

    Tente minimizar as alterações necessárias para quebrar as dependências que impedem a adição de testes.

  3. Escreva testes para cobrir, na medida do possível, a funcionalidade do código que você irá alterar. Check-in regularmente e peer rever todas as alterações.
  4. Escreva testes para a nova alteração de funcionalidade / funcionalidade.
  5. Implemente a funcionalidade (esse é seu ciclo normal de TDD)
  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.

Temos visto uma queda enorme no número de bugs recebidos pelos nossos testadores de QA. Com as regressões de funcionalidade sendo agora quase inéditas, acho que valeu a pena o esforço para nós.

    
por 17.12.2010 / 19:09
fonte
2

(pela falta de capacidade de comentar), acho melhor não testar. Nem todo snippet 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 através de uma API limpa depois.

    
por 17.12.2010 / 10:30
fonte
2

Se o material antigo estiver funcionando bem por 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 partes não é de todo inútil. As novas partes são as mais propensas a conter bugs, e são também as partes com maior probabilidade de serem alteradas ou refatoradas.

    
por 17.12.2010 / 10:35
fonte
1

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

    
por 17.12.2010 / 10:35
fonte
0

Is unit testing a 100% or not at all kind of deal?

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

    
por 17.12.2010 / 15:37
fonte