O colega não está disposto a usar testes de unidade ", pois é mais um código"

Um colega não está disposto a usar testes de unidade e, em vez disso, optar por um teste rápido, passa-o aos usuários e, se estiver tudo bem, é publicado ao vivo. Escusado será dizer que alguns bugs passam.

Eu mencionei que deveríamos pensar em usar testes de unidade - mas ela foi contra, uma vez que se percebeu que mais código teria que ser escrito. Isso me deixa na posição de modificar algo e não ter certeza de que a saída é a mesma, especialmente porque o código dela é espaguete e eu tento refatorá-lo quando tiver uma chance.

Então, qual é o melhor caminho a seguir para mim?

Ela não está ciente dos benefícios do teste de unidade e é isso que você precisa alterar:

• A consciência dela.

Você terá que provar a ela que isso irá melhorar o trabalho dela, não apenas o seu. Isso será difícil, ela provavelmente tentará se concentrar em todos os aspectos negativos que encontrar, se tiver medo de mudar.

Você pode tentar discutir com ela sobre todos os benefícios e ouvir todos os seus contra-argumentos. Espere até que ela termine de falar antes de começar a conversar.

Para se preparar, procure no P.SE ou no Google todas as coisas em que os gerentes ou desenvolvedores estão preocupados com o teste de unidade e compile as respostas que você usará durante as discussões com seu colega.

Apenas ouvi-la e fornecer provas de que isso irá melhorar o trabalho dela ajudará muito. Você prova que está preocupado com a opinião dela e fornece a ela todos os dados necessários para analisar a situação e, eventualmente, mudar de idéia.

Faça um teste de unidade (não conte a ela)

Espere até que a coisa pare, deixe-a fazer testes manuais por dois dias, depois faça os testes de unidade e encontre o erro em três segundos.

Proteja-se...

A automação de tarefas manuais deve atrair qualquer programador.

Então ela não está "escrevendo mais código", está fazendo menos manualmente.

(Um) dos pontos dos testes automatizados é a repetibilidade . Se você fizer um teste rápido manualmente, poderá fazê-lo mais rapidamente do que escrever o mesmo que um teste de unidade (pelo menos para um iniciante em testes de unidade - qualquer pessoa com experiência em testes de unidade pode realizar testes muito rapidamente).

Mas e quando amanhã ou na próxima semana uma pequena (ou grande ...) alteração for feita no código? Seu colega repetiria alegremente os mesmos testes manuais repetidamente após cada alteração, para garantir que nada seja quebrado? Ou ela prefere "codificar e orar"?

Quanto mais o código é alterado, mais os testes de unidade pagam seu investimento inicial . Não demora muito para chegar ao lado positivo, mesmo sem os testes realmente detectando bugs. Mas eles fazem isso regularmente também - nesse ponto, eles se tornam inestimáveis. E uma vez que alguém experimenta esse sentimento de segurança e confiança no código que um teste de unidade bem-sucedido dá, geralmente não há como voltar atrás.

Se ela está convencida, mas com medo de se aventurar na nova área, ofereça a ela uma sessão de programação em pares para escrever seus primeiros testes de unidade juntos . Escolha uma classe que não seja muito difícil de testar, mas suficientemente complexa para que valha a pena testar.

No entanto, se ela não estiver convencida, talvez seja necessário coletar fatos concretos . Tais fatos podem ser

• taxas de defeitos no código escrito por você vs dela
• escrevendo um conjunto de testes de unidade contra o código dela e documentando os erros encontrados.

Colete alguns desses dados e mostre educadamente os resultados. Se isso ainda não for suficiente para convencê-la, talvez seja necessário discutir o problema e compartilhar as evidências coletadas com a gerência. Esse deve ser apenas o seu último recurso, mas às vezes não há outro caminho.

Escreva uma cobertura de teste básica para os piores bits do código dela, atribua-a com base nesses testes e, em seguida, defenda a gerência de que o teste de unidade em builds contínuos aumentará a produtividade. As mudanças são mais fáceis quando mandatadas por um empregador do que evangelizadas por um único desenvolvedor.

Não sei como expressar isso corretamente, mas: se você está refatorando o código "quando tiver uma chance" ... bem, ela provavelmente acha que você é um idiota por se envolver nos "negócios dela" , é menos provável que você o ouça com a mente aberta. Na minha experiência, as pessoas se apegam ao que fizeram - mesmo quando não é muito bom.

Interpretar o advogado do diabo: ela tem razão. Eu costumo colocá-lo como:

Os testes automáticos resolvem os problemas de muito código com ainda mais código.

Fundamentação da petição:

• estudo sobre a correlação da taxa de falhas e das métricas OO , resultado do manchete: "Após controlar o tamanho [da classe], nenhuma das métricas estudadas estava mais associada à propensão a falhas" . (O estudo discute o tamanho da turma. Esse efeito se estende ao tamanho da base de código? Provavelmente. Na minha opinião )
• Empiricamente, grandes projetos tendem a avançar lentamente. "5K linhas durante a noite em um novo projeto" vs. "10 linhas / dia em um projeto grande". Isso indica uma "resistência" à mudança aumentando com o tamanho da base de código?
• Sempre proclamamos "não há melhor linguagem, depende do problema". Um requisito essencial é modelar entidades e operações com problemas facilmente no idioma de sua escolha. Isso não sugere que escolher um idioma em que expressar seu problema seja mais elaborado seja pior , e isso não se correlaciona novamente com o tamanho final da base de código?

Agora, existem alguns argumentos para disparar contra isso facilmente. Deixe-me abordar os que eu consigo pensar:

• tamanho vs. simplicidade: é claro que é possível tornar o código mais curto e pior. No entanto, isso é apenas um problema ao comparar bases de código com diferentes proporções de brevidade versus simplicidade, para a discussão que se pode assumir que de alguma forma poderíamos controlar esse fator.

• Os testes de unidade pressionam você a reduzir dependências, e eu concordo empiricamente que a redução de dependências pode atenuar os problemas de tamanho de código (no sentido de que em duas bases de código de tamanho semelhante, a que possui mais interdependências é pior). No entanto , ao reduzir as dependências entre as unidades de código de produção, ele introduz o acoplamento entre o teste e a própria unidade.

TL; DR: Não discuto que os testes de unidade sejam ruins; Eu pergunto: existe um ponto de equilíbrio onde os testes prejudicam que estão correlacionados à quantidade de código?

Eu acho que você está em uma posição difícil. Eu estive em uma equipe onde as pessoas não escreviam testes de unidade ou, pior ainda, testes de unidade horríveis e insustentáveis. Mas todos estavam cientes do fato de que o teste de unidade é bom.

Portanto, obter uma boa qualidade do conjunto de testes de unidade da equipe foi um longo e difícil caminho. Sempre à procura de onde as coisas poderiam ser melhoradas, comunicando idéias, compartilhando experiências.

Por outro lado, você tem um desenvolvedor que nem percebeu o benefício. E então também codifica o código do espaguete. Eu acho que uma das razões mais importantes nesse caso em particular é o fato de que escrever bons testes de unidade força um design pouco acoplado. Portanto, fazer com que ela escrevesse o teste poderia, a longo prazo, também melhorar o código "real".

Mas acho que, no final, é uma decisão da equipe (não sei quantos vocês estão na equipe?). Se a equipe chegar a um consenso de que deve haver um conjunto de testes de unidade abrangente, todos devem se conformar, compartilhar experiências e deixar sua equipe crescer forte juntos.

Se a equipe, no entanto, não conseguir chegar a um consenso de que você deve escrever testes de unidade, sugiro que você encontre uma equipe de desenvolvimento diferente para trabalhar;)

Ela é a chefe?

Se assim for ... você está meio empacado, a menos que possa convencê-la dos benefícios que estão basicamente na linha de "uma grama de prevenção vale um quilo de cura". Erros são passados. O TDD ajuda a mitigar isso, criando resultados consistentes.

Ela não é o chefe?

Quais são os padrões de codificação onde você trabalha? Por que ela pode vomitar código de espaguete? Apresente um caso de negócios ao chefe dizendo: "Passaremos muito menos tempo com bugs se passarmos um pouco mais de tempo no TDD". Convença alguém que possa impor mudanças com um caso de negócios.

Documente os casos em que o TDD poderia economizar tempo e $$ DINHEIRO $$.

Este bug se apresentou. Teria sido capturado antes de ir ao ar. Passar 2 horas de prevenção nos salvaria 10 horas de cura. Isso aconteceu aqui e aqui e aqui. Essas 10 horas de trabalho que teriam economizado 30 minutos para a empresa. Isso é tanto dinheiro.

Isso me deixa na posição de modificar algo

Por quê?

Eles criaram o problema. Eles deveriam resolver isso.

Qual gerente está permitindo que isso aconteça? Por que o código de buggy de outra pessoa agora é seu problema?

Você tem um colega e um gerente que estão fazendo isso acontecer. E limpando a bagunça deles, você é um participante disposto e ativo.

Nada mudará se eles não sentirem a dor da má qualidade.

Ela está certa, os testes de unidade são "mais códigos".

No entanto, é simplesmente mais código que precisa ser escrito para garantir que o programa funcione como deveria (repetidamente). Não é tempo perdido. É tanto uma parte do sistema quanto seus componentes principais.

Desafie-a em:

1. O que acontece se alguém que não conhece o código altera alguma coisa.
2. O que acontece se alguém inexperiente muda alguma coisa.
3. O custo de manutenção de um sistema não é medido em quanto tempo leva para criar. É uma proposta de longo prazo. Pense no custo total de propriedade.
4. Sua estimativa (se isso foi necessária antes do início da codificação) deve incluir o requisito para escrever testes de unidade. As pessoas de negócios não criam requisitos que exigem testes de unidade diretamente, mas eles têm um requisito implícito de qualidade e exigem que mudanças futuras não sejam repletas de bugs ou que o mesmo programador altere sua fonte.

Falando como aquele que atualmente produz código de produção, seguido de testes de unidade em vez de TDD, o que não parece ser um bom ajuste no meu local atual (eu já fiz TDD em alguns projetos, mas o vejo apenas como outra ferramenta em o velho saco, não uma bala de prata) ...

Pode ser uma venda difícil. Ainda não consegui vender meus colegas de trabalho em testes de unidade. Sei que tendem a cometer mais erros no meu código de teste de unidade do que no meu código de produção. Portanto, é um pouco frustrante gastar tanto tempo corrigindo o código do teste de unidade ... No entanto, é um bom seguro quando o código é modificado. Ótima maneira de testar as condições da borda automaticamente.

Mostre a ela quanto os testes de unidade ajudam, criando você mesmo os testes de unidade.

Como São Francisco disse uma vez: "Pregue sempre. Quando necessário, use palavras".

Se ela perceber que seu código está usando testes de unidade e que você conseguirá solucionar bugs mais rapidamente com testes de unidade, isso poderá mudar de idéia. Mas, não pode.

Não importa o resultado, ela não vê você empurrando algo sobre ela que você não está disposto a fazer. É isso que você precisa mudar, a percepção de que não está liderando pelo exemplo.