Quero apresentar o conceito de testes de unidade (e testes em geral) aos meus colegas de trabalho; No momento, não há testes e as coisas são testadas executando as tarefas na interface do usuário para ver o resultado desejado. Como você pode imaginar, o código está muito acoplado à implementação exata - até mesmo resultando em código que deve estar em uma classe e reutilizado no sistema, sendo copiado e colado nos métodos.

Devido a requisitos alterados, fui solicitado a modificar um módulo que escrevi anteriormente e que é bastante flexível (não tanto quanto eu gostaria, mas da melhor forma possível, sem a necessidade de introduzir muitos outros conceitos). Decidi incluir um conjunto de testes de unidade com meu código revisado para "provar" que ele funciona conforme o esperado e demonstrar como o teste funciona; Não estou seguindo o TDD verdadeiro, pois parte do código já está gravado, mas espero seguir alguns conceitos do TDD para o novo código que precisarei criar.

Agora, inevitavelmente, tenho certeza de que me perguntarão por que estou demorando mais de um dia ou dois para escrever o código, já que partes do que eu vou interagir já existem no sistema (embora sem testes e com muita rigidez). acoplado) e, quando eu fizer o check-in do código, ser-lhe-á perguntado o que é esse projeto de "testes". Eu posso explicar o básico dos testes, mas não consigo explicar os benefícios reais da maneira que os outros entenderiam (porque eles acham que o teste exige que você execute o aplicativo por conta própria, pois muitas vezes a interface do usuário real é importante para determinar se o recurso "funciona"). " ou não). Eles não entendem a idéia de acoplamento flexível (claramente evidente pelo fato de que nada é fracamente acoplado; não há nenhuma interface fora do código que escrevi), então, tentar usar isso como um benefício provavelmente me daria um "Huh?" tipo de aparência, e novamente não posso ser tão frouxo quanto gostaria sem ter que refazer vários módulos existentes e provavelmente introduzir algum tipo de contêiner de IoC, que seria visto como perda de tempo e não como "programação".

Alguém tem alguma sugestão sobre como eu posso apontar para este código e dizer "Devemos começar a criar testes de unidade" sem parecer condescendente (por exemplo, "Escrever testes obriga a escrever um bom código".) O que provavelmente seria considerado código exceto que o meu é ruim ) ou sem parecer uma perda de tempo que não agrega nenhum valor real?

Quero introduzir o conceito de testes de unidade (e testes em geral) para meus colegas de trabalho

Acho que seria melhor começar do lado prático, não do lado conceitual. Obviamente, se você descobrir durante uma discussão casual que seus colegas de trabalho e / ou gerência estão interessados ​​em ouvir sobre os testes de unidade, tanto melhor - então você pode pesquisar algumas experiências / evidências concretas na web, montar um breve treinamento etc. No entanto, pelo que você descreve, parece que seus colegas de equipe não estão muito abertos a essa nova e estranha idéia.

Em tal situação, eu começaria a escrever meus pequenos testes de unidade sem tentar explicar muito a ninguém primeiro. Adicione alguns deles sempre que alterar o código, sem tentar abranger todo o código (o que levaria uma quantidade excessiva de tempo). Idealmente, se eu conseguir encontrar um bom equilíbrio, no momento em que eles perceberem que estou escrevendo testes de unidade, talvez eu já tenha um conjunto de testes substancial e alguns resultados concretos para mostrar (como "neste caso de teste, eu consegui detectar um bug introduzido pela mudança da semana passada, que de outra forma passaria para o controle de qualidade / produção "). Isso provará o valor dos testes para qualquer desenvolvedor sério.

Depois disso, estou em uma boa posição para começar a explicar os benefícios a longo prazo dos testes de unidade, como

• prova que o código funciona - a qualquer hora, em qualquer lugar, instantânea e automaticamente, o que por sua vez
• dá confiança ao refator, resultando em projeto aprimorado e melhor manutenção,
• e se algo quebrar, os testes de unidade fornecem feedback (quase) instantâneo, em oposição à latência de vários dias ou semanas, se o bug for detectado por um departamento de controle de qualidade separado. O que normalmente permite que você corrija o bug em segundos, em vez de depurar por horas / dias, em código que há muito caiu da memória de curto prazo.

Consulte também este tópico relacionado: Teste de unidade automatizado, teste de integração ou teste de aceitação .

E um anterior da SO: O que é teste de unidade?

Re-fator sem medo

Como um ângulo um pouco diferente, o TDD permite "re-fatorar sem medo", e este é um benefício importante que você pode vender à sua equipe. Isso impede que os desenvolvedores digam para si mesmos:

• "Eu não quero tocar nesse código porque tenho medo de quebrá-lo"
• "Não quero escrever novas funcionalidades para esse código porque não sei como ele funciona"
• "Secretamente, eu tenho medo desse código"

Eu poderia falar mais, mas esse é um terreno bem coberto, como o tio Bob no TDD e Martin Fowler no TDD .

Dependências

Ah, vou acrescentar mais uma coisa. Ele mostrará a eles como o TDD impõe um bom design, o que permite lidar de maneira limpa com as dependências.

Bob: "Oh, c% ^ p! Os chefes nos forçaram a usar o MS SQL Server 2008" Jane: "Tudo bem, o dano foi minimizado porque identificamos nossa fonte de dados e nossas classes DAO, estou tão feliz que o TDD tenha incentivado nós por esse caminho ".

Enquanto trabalhamos no código-fonte que não possui testes automatizados, precisamos trabalhar com muito cuidado e precisamos de mais revisões para manter a confiança de que o tipo de alterações que estamos fazendo não quebra nenhuma das funcionalidades existentes.

Quando tivermos bons casos de teste automatizados, as consequências serão um desenvolvimento mais rápido, confiante e sem medo (pode ser a correção, aprimoramento ou re-fatoração de erros).

Faça as contas

• t _mt = o tempo necessário para testar manualmente tudo o que você pode afetar
• t _wt = o tempo necessário para escrever os testes

• k = o número de vezes que você provavelmente terá que testar tudo antes de liberar o novo código

  se (t _wt <t _mt ) ou (t _wt <(k * t _mt )), então é óbvio: escrever os testes acelerará o desenvolvimento.

caso contrário, observe a razão (t _wt / (k * t _mt )). Se for um número muito grande, aguarde outra oportunidade; caso contrário, justifique com benefícios de teste de regressão.

Nota: Neste ponto, sugiro apenas testar recursos, não unidades - muito mais fácil de justificar e entender, e sem dúvida menos trabalho com valor mais alto do que meros testes de unidade ao refatorar.

Nota 2: o tempo necessário para executar os testes não importa , porque eles são automatizados. Você pode fazer algo mais produtivo enquanto os testes são executados, a menos que os testes demorem tanto para serem executados que eles farão com que você perca o prazo. O que é raro.

Uma sugestão se você é um Microsoft shop: encontre alguma documentação no MSDN que recomende testes de unidade ou frouxos como uma prática recomendada (tenho certeza de que existem várias instâncias disso ) e aponte-a se houver conflitos.

Pode parecer uma maneira grosseira de fazer as coisas, mas eu descobri que usar o termo "melhores práticas" o levará muito longe, especialmente com a gerência.

Como eu sempre recomendo, se você conhece uma ótima prática, a melhor maneira de introduzi-la suavemente em seu ambiente seria começar a fazê-lo você mesmo e, em algum momento do processo, alguns de seus colegas de trabalho verão os benefícios e pegar.

A palavra-chave aqui é evolução, não revolução.