Como você convenceu seu gerente a deixar seu teste de unidade?

Por "uso", quero dizer que estou autorizado a desenvolver, fazer check-in para o controle de origem e manter os testes de unidade ao longo do tempo, etc.

As objeções típicas de gerenciamento são:

1. O cliente não pagou pelos testes de unidade
2. O projeto não permite tempo para testes de unidade
3. Dívida técnica? Que dívida técnica?

Você conhece outras objeções? Quais foram as suas respostas?

Desde já, obrigado!

Eu me deparei com esse problema recentemente quando um cliente estava de acordo com nossa metodologia, mas a gerência superior percebeu que os desenvolvedores estavam gastando seu tempo testando em vez de desenvolvendo e estavam preocupados com isso - afinal, eles tinham pessoal de controle de qualidade para fazer o teste! Eu escrevi sobre como eu lidei com isso aqui:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Para resumir, comparei nossas horas estimadas com as horas reais do projeto e, em seguida, comparei nossa taxa de defeitos com a taxa de defeitos de outras equipes. No nosso caso, esses números se compararam favoravelmente e não houve mais preocupações.

Minha conclusão com base nessa experiência é:

... a melhor maneira de convencer alguém de que sua abordagem para fazer algo é prática e pragmática, é fazê-lo e compará-lo com outras abordagens. As pessoas não se importam com dogmas, ou por que você acha que algo deve ser o melhor caminho. Somente mostrando às pessoas os números e medindo a eficácia de sua abordagem, você pode realmente mostrar que suas práticas são eficazes.

Em outros projetos, trabalhamos com desenvolvedores de clientes que não criaram testes de unidade ou fizeram TDD e tivemos que manter os testes que eles quebram. No entanto, fica muito fácil vender a abordagem TDD para esses desenvolvedores de clientes quando você pode dizer a eles o que eles quebraram no código antes que eles percebam!

Portanto, no seu caso, eu faria isso furtivamente, se necessário (talvez exista uma pequena área do código que você possa começar a testar que muda frequentemente ou da qual você é responsável), mas acompanhe seus números - qual é o esforço para criar seus testes? Qual é a taxa de defeitos? Como isso se compara com outros projetos / membros da equipe?

Na minha opinião, ninguém precisa pedir permissão ou pedir desculpas por querer fazer seu trabalho corretamente e qualquer desenvolvedor profissional deve tentar testar seu código com testes automatizados sempre que possível e prático. Espero que seja essas duas coisas no seu caso. Boa sorte!

Mostrar o retorno do investimento (ROI)

Escrever testes automatizados leva tempo. Uma vez. A execução de testes automatizados leva tempo zero, porque você pode fazer outra coisa enquanto eles estão em execução.

Exemplo: O teste manual do recurso X leva 30 minutos. Escrever um teste automatizado levaria 1 hora. Mesmo se não tivermos bugs, teremos que testar o recurso X dez vezes durante o curso do projeto, à medida que suas camadas e componentes dependentes forem modificados. Portanto, automatizar o teste do recurso X nos poupará 4 horas ao longo da vida do projeto.

Na realidade, é quando você tem um bug que os testes automatizados realmente valem a pena - Primeiro, eles encontram erros mais cedo e mais barato, o que economiza tempo e vergonha. Segundo, se você tiver um bug difícil e passar por muitos ciclos de teste de construção de código para descobrir isso, o tempo economizado no teste manual aumenta extraordinariamente rápido.

As empresas entendem economizar tempo e dinheiro. É assim que se vende.

Se você já os enfrentou e eles não concordam, mas você não se sente à vontade para escrever código sem eles ... então não pergunte novamente. Basta escrever e não fazer check-in.

A gerência não contará linhas de código, mas eles verão que todos os seus check-ins têm taxas de aprovação mais altas do controle de qualidade (ou clientes) e, eventualmente, perguntarão o porquê ... então você pode ser como "BAM! TDD ! "

Você não está mexendo no projeto, processo ou fonte ... então não vejo uma razão negativa. Honestamente, não vejo uma razão pela qual seja diferente em termos de tempo do que executar todos os seus testes de execução manual + entrada + verificação de resultados.

1) O cliente não pagou pelos testes de unidade

O cliente (pensou que) pagou por uma solução funcional. Dependendo dos contratos, a correção de defeitos pode ser realmente lucrativa para sua empresa. Se houver bloqueio suficiente. Voltemos a pagar por uma solução que funcione. O TDD deve ajudar nesse objetivo.

2) O projeto não permite tempo para TDD

TDD não demora mais. Deve reduzir a quantidade de código estranho ou supérfluo e concentrar a base de código no que faz os testes passarem. Todos os testes aprovados, sujeitos à qualidade e adequação do teste, significam que o código está pronto.

3) Dívida técnica? Que dívida técnica?

Tenho a impressão de que você pode estar argumentando por adicionar retrospectivamente testes ao código existente. Este é um pesadelo vendido na melhor das hipóteses e não traz os benefícios que você pode esperar. No entanto, adicionar testes à medida que você corrige bugs deve ser aceitável e ajudar a longo prazo.

Eu não recomendo escrever os testes de qualquer maneira, como sugeriu Snorfus. Soa bom na teoria, mas testes de unidade pode e fazer a mudança ao longo do tempo. À medida que os requisitos mudam, novos recursos são adicionados, os testes de unidade precisam ser atualizados. Se você estiver trabalhando como parte de uma equipe, seus testes de unidade ficarão desatualizados à medida que outros adicionam recursos / correções.

Estou abordando os pontos específicos que você mencionou em vez de criar novos, porque há margem de manobra para progredir ou entender por que está sendo bloqueado.

Para cada cliente que enfrenta problemas de produção,

1. Escreva um teste de unidade e envie um email ao gerente dizendo que você adicionou um teste de unidade para cobrir o cenário.

2. Diga a ele que esse problema não ocorrerá novamente na produção, porque nosso teste de unidade está sendo executado todas as noites e saberemos antes que o código entre em produção, observando essa falha no teste de unidade.

3. Diga a ele que se já tivéssemos esse teste de unidade em vigor antes do código ser produzido, esse problema de produção nunca teria acontecido.

Faça isso de forma consistente e persistente e em breve ele ficará convencido. Os gerentes não gostam do cliente enfrentando problemas de produção e ele comprará a ideia de teste da unidade. Boa sorte.