A equipe de teste de novatos precisa testar a unidade

35

Estou trabalhando com uma nova equipe que historicamente não fez QUALQUER teste unitário. Meu objetivo é que a equipe eventualmente empregue o TDD (Test Driven Development) como seu processo natural. Mas como o TDD é uma mudança de mentalidade tão radical para uma equipe de testes que não seja de unidade, pensei em começar a escrever testes de unidade após a codificação.

Alguém já esteve em uma situação semelhante? Qual é uma maneira eficaz de fazer com que uma equipe se sinta confortável com o TDD quando não realizou nenhum teste de unidade? Faz sentido fazer isso em alguns passos? Ou devemos mergulhar e enfrentar todas as dores do crescimento de uma só vez?

EDITAR

Apenas para esclarecimentos, não há ninguém na equipe (além de mim) que tenha QUALQUER unidade testando exposição / experiência. E estamos planejando usar a funcionalidade de teste de unidade incorporada no Visual Studio.

    
por Walter 10.10.2010 / 16:42
fonte

7 respostas

35

Pratique bugs / defeitos existentes.

Esta é uma situação realmente difícil. Eu nunca fui até o TDD a partir de nada antes, mas na minha experiência, fazer com que uma equipe vá de nenhum teste unitário para escrever de forma proativa foi uma abordagem muito "um passo de cada vez".

Primeiro, deixe-os confortáveis escrevendo testes de unidade e sabendo realmente o que são e seus benefícios. Para as minhas equipes, é melhor escrever testes de unidade para os erros existentes. Os bugs atuais nos sistemas têm duas coisas que você precisa para ensinar as pessoas a escrever bem os testes de unidade:

  1. uma precondição e uma pós-condição esperadas
  2. um resultado que atualmente não é o esperado e viola essa pré-condição / pós-condição

Isso dá aos membros exemplos de prática muito concretos. Eles podem escrever um teste antes de corrigir o bug, para que ele falhe. Então, eles podem corrigir o código para que ele passe e conserte o bug. Uma vez que eles estão confortáveis com isso, então você pode pegá-los o resto do caminho para que eles possam escrever testes de unidade sem código inicial e, em seguida, escrever um novo código para fazer seus testes passarem.

Eu acho que o truque é dar a eles algo para praticar onde há um método claro pré / pós-condições. Se os requisitos para os métodos são confusos, é difícil até mesmo para as pessoas experientes do TDD saber exatamente por onde começar. Dê um passo e você chegará lá. Boa sorte!

    
por 10.10.2010 / 17:04
fonte
30

Consegui convencer toda a minha empresa a mudar para o TDD. Não foi fácil, mas valeu a pena: a qualidade do código aumentou após a transição, e agora ninguém imagina voltar aos horríveis tempos de codificação do cowboy.

  1. Explique, explique, explique. Você não quer que sua equipe escreva testes. Você quer que sua equipe queira que escreva testes. Isso significa que eles devem entender completamente por que eles deveriam estar fazendo isso, quais são os benefícios e como isso facilitará muito o trabalho deles. Red, Green, Refactor , escrevendo um teste de regressão como prova de que um bug foi corrigido, etc. Você tem que convencê-los de que a coisa toda faz sentido antes de pedir que escrevam qualquer código.

  2. Escolha a coisa real (primeiros testes, depois código). Escrever testes após o código dificilmente faz sentido, já que você nunca saberá se eles realmente funcionam (e as pessoas escrevem casos de teste de bugs). Minha intuição é que a quantidade de esforço que você precisa para passar de nenhum teste para testes primeiro é muito menor do que o que você precisa para passar sem testes através do código primeiro para testes primeiro , então você pode pular a etapa intermediária.

  3. Comece com os testes de regressão. Estes são bastante simples de entender e dão gratificação instantânea. Obviamente, isso pressupõe que o código seja adequadamente modularizado e facilmente testável. Se não, pule esta etapa.

  4. Dê pequenos passos. TDD leva algum tempo para se acostumar e pode ser frustrante no começo. Tente introduzir testes em um novo projeto ou componente, idealmente: algo não muito importante. Você quer evitar a todo custo a situação em que há algo realmente importante a ser feito muito rapidamente e os programadores sentem que o TDD está atrapalhando.

  5. Quando a equipe começar a se sentir confortável, tenha todas as novas funcionalidades escritas de maneira TDD. Isso depende do tamanho do seu projeto, mas depois de algum tempo você deve obter uma boa cobertura, com apenas algumas partes legadas do seu projeto escritas da maneira antiga.

  6. A essa altura, a equipe já deve entender e adotar o TDD, e o material legado (não TDD) deve ser considerado difícil e irritante de se trabalhar. Seja refatorado: a maioria das pessoas fará isso com prazer.

Alguns outros pontos importantes:

  • Verifique se você está usando a melhor estrutura de teste disponível. Será muito mais difícil convencer as pessoas a fazer TDD se tiverem que interagir com uma biblioteca mal escrita.

  • Certifique-se de que os testes sejam fáceis de executar e não demorem muito para terminar (ou trapaceie, por exemplo, usando um banco de dados na memória para os testes).

  • Configure alguns softwares de integração contínua, para que os testes quebrados sejam encontrados imediatamente.

por 11.10.2010 / 00:17
fonte
16

Uma maneira de se sentir confortável com o TDD é escrever testes de integração primeiro. Introduzir costuras de teste e testes de unidade verdadeiros mais tarde.

O problema com a escrita de testes unitários após a codificação é que o código pode não ser necessariamente bem projetado para ser testável . Você pode precisar fazer alguma refatoração ou talvez redesenhar para introduzir as emendas de teste. Mas como você pode refatorar ou redesenhar com segurança se você não tem cobertura de teste de qualquer tipo?

Os testes de integração podem fornecer essa cobertura inicialmente. Toda vez que você tiver uma regressão ou um problema de produção, corrija-o no código e cubra esse código com um teste. Uma vez que você tenha uma rede de segurança suficiente fornecida por tais testes, você pode introduzir testes unitários de componentes isolados e / ou classes mais finos do seu sistema.

    
por 11.10.2010 / 03:56
fonte
3

O TDD é muito difícil de implementar e nem sempre é a melhor opção para todas as equipes de desenvolvimento. No meu trabalho anterior, a equipe estava strongmente focada em TDD. Nosso modelo de desenvolvimento foi inteiramente TDD usando a abordagem de desenvolvimento ágil. O teste foi feito através de testes unitários do Visual Studio.

Se um desenvolvedor não escrevesse nenhum teste de unidade para o seu recurso, estaria em apuros com o líder técnico. Além disso, se alguém fizer check-in em uma build quebrada ou em qualquer teste de unidade, o desenvolvedor precisará corrigir todos os problemas e adicionar $ 1 ao jar do dinheiro da equipe.

    
por 11.10.2010 / 06:37
fonte
3

Apenas uma coisa pequena para adicionar, visualize o processo. Faça a integração contínua executar testes automaticamente e verifique a cobertura de código. Liste os módulos testados mais completos em alguma página inicial que todos possam ver. Isso deve levar a competição da equipe.

    
por 11.10.2010 / 09:30
fonte
0

Eu estive em equipes que não fizeram nenhum teste unitário, mas ele foi introduzido e tornou-se quase comum ter alguns testes agora. Eu sugeriria explorar até que ponto sua equipe entende os fundamentos dos testes unitários, bem como quais ferramentas você deseja trazer para cá?

No meu caso, estava trazendo nUnit para algum código .Net que era uma mistura de lógica de negócios, interface de usuário e funcionalidade de back-end. Eu sugeriria ver se há algumas pessoas que têm mais vontade de querer mais do que outras, para que algumas pessoas da equipe consigam e possam se espalhar um pouco melhor do que o outro lado, onde você tenta fazer com que todos para entrar nisso. Ao fazer com que alguns o façam bem primeiro, isso possibilita um treinamento cruzado para que aqueles que o aprendam possam testá-lo quanto a como podem ensiná-lo a outra pessoa.

Outro ponto é considerar trazer aqueles que têm mais experiência para tentar mostrar isso até certo ponto. A Thoughtworks foi trazida onde eu trabalho para nos mostrar algumas coisas que algumas delas foram amplamente adotadas e outras partes não muito, mas acho que isso seria verdade na maioria dos lugares.

    
por 10.10.2010 / 17:27
fonte
0

Eu passei de nenhuma experiência JUnit diretamente para TDD, e a experiência fez com que o valor de TDD fosse inequivocamente aparente. Eu me tornei tão agradecido pelos testes de unidade que rapidamente me tornei um evangelista para a abordagem

    
por 24.02.2011 / 03:47
fonte