Como motivar os colegas de trabalho a escrever testes unitários? [fechadas]

Eu notei que falar sobre o TDD dificilmente funciona. As pessoas gostam de ver resultados brutos . Dizer que "escrever testes irá reduzir o tempo de desenvolvimento" é provavelmente verdade, mas pode não ser suficiente para convencer ninguém.

Eu estava em posição similar (bem, não tão ruim quanto a sua), e meio que se resolveu quando as pessoas começaram a trabalhar no meu código (nota: meu código foi testado na unidade, outros nem tanto). Quando algo parou de funcionar, o acompanhamento natural após a investigação local foi perguntar a qual poderia ser a razão . Depois nos sentamos, fizemos testes de unidade e vimos o que aconteceu. Se os testes estivessem passando, a maioria dos problemas de tempo estava no novo código não testado. Se não, os testes geralmente são capazes de identificar o problema (ou pelo menos nos apontar na direção certa). Corrigimos o bug, os testes aumentaram, todo mundo ficou feliz.

Para encurtar a história, algumas situações como essa ocorreram e mais dois desenvolvedores se tornaram entusiastas do TDD / teste (ainda há mais alguns para serem lançados, mas parece promissor).

Como para o conselho, você pode dar um passo com o kata TDD; Tarefa simples para implementar usando uma primeira abordagem de teste em oposição a nenhum teste . Dependendo da complexidade da tarefa, a abordagem sem teste geralmente deve ser mais lenta, especialmente com alterações incrementais necessárias:

• Calculadora de cordas de Roy
• Banco OCR

Editar : o comentário do OP me fez perceber que há um argumento ainda mais strong à sua disposição - regressão também conhecido como retorno de bugs . Esse tipo de situação é um exemplo perfeito demonstrando como os testes unitários podem ser benéficos. As pessoas gostam de números - como eu disse, dizendo que "o teste de unidade é bom" pode não ser convincente, mas organizar os dados abaixo pode certamente ser:

• tempo gasto para implementar o recurso (nenhum teste foi escrito; suponho que isso aconteceu com frequência, por isso deve ser relativamente fácil encontrar esse exemplo)
• tempo estimado para implementar o recurso com a abordagem TDD (ou mesmo testes após ; não importa - o que é importante é a presença de testes de unidade)
• tempo gasto resolvendo o bug no código testado e não testado

Uma coisa para avisá-lo (essa questão é óbvia, mas vale a pena notar): viés de resultado - certifique-se de não selecione o exemplo em que a única maneira de detectar bug com o teste foi escrever um teste para esse bug. Normalmente, ninguém sabe que o bug ocorrerá de antemão, mas é tentador dizer "cara, esse bug seria trivial se tivéssemos testado por X" - é fácil encontrar uma tática vencedora para uma guerra depois que ela terminou .

O resultado desses exemplos deve ser uma pergunta simples - se você pudesse gastar x-horas desenvolvendo o recurso Y, por que insistiria em fazê-lo em 2x ?

Primeiro, você precisa saber por que eles não estão escrevendo testes.

Horários de desenvolvimento apertados geralmente são o motivo, mas você diz que não tem isso.

A próxima razão é que, com uma grande base de código não testada existente, os testes de escrita provavelmente parecem esmagadores - um trabalho sem fim (como a lavanderia e o mais excitante). Então, a natureza humana é pensar que é demais para enfrentar, então vou pular isso.

Outra strong possibilidade é que eles realmente não vêem nenhum valor para mais trabalho, mesmo que estejam de boca aberta com a ideia.

Então, como você lida com as diferentes razões?

O motivo é simples, mostre um exemplo de como ele economiza tempo de desenvolvimento.

Motivo dois - mostre quantos testes você escreveu em um ano e qual porcentagem da base de código ele abrange. Faça as contas para mostrar quantos mais testes eles poderiam ter no ano que vem, se eles fizerem isso. Uma vez que eles vêem que pequenos progressos no dia a dia realmente aumentam, toda a idéia não é tão esmagadora. Se você conseguir extrair os dados do sistema, mostre a eles quantos bugs foram repetidos bugs nas partes não testadas do código e quantos bugs repetidos aparecem no código com testes unitários.

A razão 3 está treinando, não apenas mostrando. Faça-os escrever testes em uma aula de treinamento.

Razão 4, este é o cerne da questão. Primeiro, escolha um ponto de dor, um desses erros que retornou várias vezes. Quando isso acontece, é hora de sugerir à gerência que, se tivessem testes de unidade nesse item, não voltariam como um centavo ruim.

Outra maneira de abordar a razão 4 é fazer com que o gerenciamento faça parte do processo e o código não passe na revisão de código, a menos que os testes também passem na revisão de código. Melhor abordá-los com esta política logo após um desses pontos problemáticos ou, de preferência, logo depois de ter tido vários em questão de dias.

Todos nós gostamos de pensar que, como desenvolvedores, nós nos autogerenciamos (LOL), mas os ambiciosos se preocupam com o que a gerência enfatiza para eles que devem se preocupar e os profissionais que realmente se autogestionam já estão escrevendo os testes. Se eles não se importam em ser profissionais e fazer as melhores práticas, porque melhoram o produto ou se importam, que tal impressionar os gerentes para serem promovidos (ou não demitidos), então você pode considerar se este é o lugar certo para você. Se você não conseguir que a gerência se preocupe com as melhores práticas, você estará lutando uma batalha difícil e, novamente, poderá avaliar se essa é a cultura corporativa certa para você. Enquanto cada local de trabalho tem seus problemas (e fugir nem sempre é a resposta), este lugar não parece se encaixar no seu nível de profissionalismo.

Eu começo demonstrando os benefícios do TDD. Tente mostrar os benefícios do teste de unidade.

Como seres humanos normais, os desenvolvedores são motivados por benefícios. Eles não querem fazer coisas que apenas criem mais trabalho. Teste de unidade significa menos trabalho . Significa sair com os amigos mais. Isso significa ter mais diversão, porque você não tem que gastar todas as noites até às 11 da noite. Significa ir de férias mais com tranquilidade.

Um dos maiores benefícios do TDD é que você pode refatorar o seu programa para um design melhor ou apenas alterar o nome de algo ... e desde que esse design não quebre os testes , você pode ter 100% de confiança de que sua alteração não quebrou nada.

Outro excelente exemplo para o TDD é a criação de testes de unidade para o código legado . Isso representaria uma das melhores maneiras de começar a refatorar o mal. A longo prazo, isso servirá para melhorar seu conhecimento sobre a base de código, entender suas forças e falhas, identificar a lógica de negócios codificada no código e dar a você um bom começo para melhorar a qualidade no futuro!

Boas referências para leitura adicional:

• Por que você deve escrever testes unitários
• Visibilidade da motivação e testes unitários
• O arte de testes unitários, de acordo com Roy Osherove

link

Acho que marquei esse link de um artigo de Jeff Atwood há algum tempo [editar: sim, aqui está] . Velho mas relevante. Devido a esses benefícios e outros que, sem dúvida, serão descritos em outras respostas, seus programadores devem poder motivar-se ! Isso lhes permitirá trabalhar de forma mais eficiente e, assim, facilitar um pouco o seu trabalho. Quem não quer isso?

Em relação à sua segunda pergunta: seu senso de propriedade e orgulho em seus padrões de qualidade de código devem mantê-lo com eles . Pense no que você deseja alcançar tendo esses padrões e quem se beneficia deles. Meus padrões de código pessoal também podem ser frustrantes, mas eu sempre sinto que estou fazendo o favor do mundo / empresa / equipe implementando-os. Então eu não acho que você está tentando fazer muito - os resultados vão variar de lugar para lugar, mas pelo menos você está fazendo o esforço.

Este parece ser um grande caso de liderar pelo exemplo .

Existem dois aspectos inerentes da natureza humana que você está combatendo:

• As pessoas criativas não gostam de processos.
• A maioria das pessoas não gosta de julgamentos negativos externos sobre sua qualidade.

É muito difícil combater isso com palestras, declarações de gerenciamento ou até mesmo lógica. Você tem que ganhar aproveitando um aspecto alternativo da natureza humana.

• As pessoas imitam o comportamento dos melhores funcionários

Se os melhores funcionários usarem o TDD e ele funcionar, o processo será expandido. Se não, não vai. Se você precisa convencer alguém, é o primeiro ou dois funcionários.

Pergunte a eles.

Você diz que as pessoas foram avisadas e concordam que devem escrever mais testes. Por que eles não são?

Pode não ser (muitas vezes não é) uma questão de motivação simples. Eles podem esquecer deles. Eles podem se sentir sob pressão do tempo. Eles podem não saber escrever bons testes. Eles podem pensar que você é tão bom que eles não precisam fazer isso. Conhecer a causa raiz ajudará você a resolver melhor o problema.

Você poderia pensar que os testes de unidade seriam a venda por si mesmos. Não sei como sua empresa funciona, mas quando há um problema durante um lançamento de produção, trabalhamos até que seja corrigido. Não importa se acontece às 2 da manhã de domingo. Isso é muito raro para nós, mas quando isso acontece, é uma droga.

Gostaria de começar perguntando-lhes quantas vezes eles tiveram que se levantar no meio da noite para consertar algum problema importante que poderia ser facilmente encontrado em testes automatizados. Isso não quer dizer que o teste automatizado conserte tudo, mas deve ajudar a reduzir isso.

O segundo grande vendedor é o ciclo de controle de qualidade. Antes do início do TDD na minha empresa, nós enviamos novos lançamentos para o QA para testar toda semana. Eles criariam uma pilha de insetos, liberamos esses insetos e fazemos outro lançamento. Repita até terminar. O primeiro projeto que fizemos TDD não exigiu um push para o controle de qualidade até várias semanas depois. E o número de bugs encontrados foi muito, muito pequeno. 10% comparado a um projeto similar. Você tem alguma forma de compilar essas estatísticas para sua equipe?

O outro grande ponto de venda foi a forma como o código protegia o TDD, era mais fácil de ler, porque queríamos que fosse mais fácil testar. Mostre uma comparação entre o código escrito para testes de unidade e o código não gravado.

Por fim, mostre como eles poderão refatorar o código com confiança.

Tenha tudo isso em mente quando não tiver vontade de escrever testes. :)

Gostaria de expandir a resposta do HLGEM , especialmente esta seção:

Next reason is that with a large existing untested code base, writing tests probably seems overwhelming- a never ending job (like laundry and about as exciting). So human nature is to think that's too much to face, so I'll skip it.

Descobri que o código que escrevo com a intenção de escrever testes é um código significativamente melhor que o código que escrevo sem a intenção de escrever testes; me perguntando Como vou testar esta função? força um melhor design de cada função. (Menos dependência de dados globais ou semi-globais; I / O separado da computação; funções fazem apenas uma coisa; tratamento de erros consistente; e assim por diante).

Tentar colocar testes no código antigo que não foi escrito com o teste em mente pode ser muito frustrante.

Eu usei algumas técnicas:

a) configure uma compilação automatizada. Quando alguém quebra algo que você testou, mostre a eles como o teste detectou e quão ruim o bug teria sido.

b) Faça projetos complexos com testes (você dirige). Isso mostrará quantos bugs existem nesse projeto. Eu tive um projeto complexo de interação com o servidor que começou a funcionar perfeitamente. Ele nunca falhou no controle de qualidade e todos os testes de integração foram 100% sem problemas. Esse sistema ficou conhecido como altamente estável e a gerência geral ficou feliz com isso. O que você faz nessas situações está presente como o teste de unidade permitiu isso.

c) Puxe uma pessoa de cada vez. Aquele que te escuta. Enfrente erros e mostre como os testes expõem problemas profundos e difíceis. Isso ajuda. Nunca é uma coisa fácil. Mas quando você conseguir um fã, ele só ajudará. É um efeito dominó.

Teste da unidade de cozimento no processo. Se um bug aparecer em produção que é muito óbvio para pegar no teste de unidade, então esse cara leva a culpa. Designe pessoas para escreverem cada teste que fizerem. Escolher aleatoriamente os casos e assistir a execução de alguns casos a cada semana. Ao fazer testes de unidade, as pessoas perguntarão sobre os requisitos e, eventualmente, vincularão os requisitos ao desenvolvimento e, espera-se, desenvolverão um software que requer e funcionará:)