Como motivar os colegas de trabalho a escrever testes de unidade? [fechadas]

Estamos trabalhando em um grande produto que está em produção há cerca de 5 anos. A base de código está .. erm .. funcionando. Não está muito bem, mas está funcionando. Novos recursos são lançados em produção e testados com um pequeno controle de qualidade. Erros são corrigidos, etc. Mas ninguém, exceto eu, está escrevendo testes de unidade. Ninguém usa o poder de "rastrear" erros ao escrever testes de unidade para garantir que esse bug especial (caso de teste) nunca mais ocorra novamente.

Eu falei com a gerência. Eu conversei com desenvolvedores. Eu conversei com todo mundo em toda a empresa. Todo mundo diz: "Sim, precisamos escrever mais testes de unidade!" Isso foi há mais ou menos um ano atrás. Desde então, forcei a introdução da revisão de código pré-confirmação ( Gerrit ) e da integração contínua ( Jenkins ).

Realizei algumas reuniões sobre testes de unidade e também mostrei os benefícios de escrever testes de unidade. Mas ninguém parece estar interessado.

P1: Como motivo meus colegas de trabalho a escrever testes de unidade?

P2: Como fico motivado para seguir meus padrões de qualidade de código pessoal? (Às vezes é realmente frustrante!)

PS: Alguns fatos frustrantes (alcançados em 1 ano):

• Total de testes unitários: 1693
• Total de "exemplos de testes de unidade": cerca de 50
• Feito por mim: 1521

Edit: Estou esperando demais? É o meu primeiro local de trabalho e estou tentando fazer o meu melhor.

Editar 2: Com base em todas as respostas, fiz uma pequena lista de verificação para mim. Conversei com dois desenvolvedores em particular e tivemos uma conversa boa e honesta.

Um deles me disse, como Telastyn disse, que ele está realmente desconfortável com testes de unidade. Ele disse que gostaria de ser "mais profissional", mas precisa de um kickstart. Ele também disse que nossa reunião de teste de unidade com todos os desenvolvedores (em torno de 9 e 11) foi boa, mas foi muito movimentada. Meh. Alguns críticos para mim, mas vou aprender com isso. (veja as respostas abaixo sobre as reuniões do tdd kata!)

O outro disse que não está interessado em escrever testes de unidade. Ele acha que seu trabalho é bom o suficiente para o seu salário. Ele não quer se esforçar mais. Fiquei sem palavras. 9-5 "trabalhador" típico.

Na próxima semana vou falar com os outros desenvolvedores.

Obrigado por suas ótimas respostas (até agora!) E seu apoio. Eu realmente gostei disso! Eu aprendi muito, muito obrigado!

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

Eu estava em uma posição semelhante (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 em unidade, outros não tanto). Quando algo parou de funcionar, o acompanhamento natural após a investigação local foi me perguntar qual poderia ser o motivo . Então nos sentamos, fizemos testes de unidade e vimos o que aconteceu. Se os testes estavam passando, na maioria das vezes os problemas estavam no código novo e não testado. Caso contrário, os testes geralmente eram capazes de detectar o problema (ou pelo menos apontar-nos na direção certa). Corrigimos o erro, os testes voltaram a funcionar, todo mundo estava feliz.

Para encurtar a história, algumas situações como essa ocorreram e mais 2 desenvolvedores se tornaram entusiastas de testes / TDD (ainda há mais algumas a serem concluídas, mas parece promissor).

Quanto ao conselho, você pode experimentar o kata TDD; tarefa simples de implementar usando uma abordagem de teste em vez de nenhum teste . Dependendo de quão complexa é a tarefa, a abordagem sem teste geralmente deve ser mais lenta, especialmente com as alterações necessárias incrementais:

• Calculadora de cordas de Roy
• OCR do banco

Edit : O comentário do OP me fez perceber que há argumentos ainda mais fortes à sua disposição - regressão, também conhecida como retorno de bugs . Esse tipo de situação é um exemplo perfeito que demonstra como os testes de unidade podem ser benéficos. Pessoas como números - como eu disse, dizer "o teste de unidade é bom" podem não ser convincentes, mas organizar dados como os seguintes pode certamente ser:

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

Uma coisa para alertá-lo (essa migração é óbvia, mas vale a pena notar): viés de resultado - certifique-se de não selecionar um exemplo em que a única maneira de detectar um bug com teste fosse 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 o X" - é fácil encontrar uma tática vencedora para uma guerra depois que ela terminar.

O resultado desses exemplos deve ser uma pergunta simples - se você poderia 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.

Agendas apertadas de desenvolvedores costumam ser o motivo, mas você diz que não tem isso.

O próximo motivo é que, com uma grande base de códigos não testada, os testes de gravação provavelmente parecem esmagadores - um trabalho interminável (como lavar roupas e quase tão emocionante). Então a natureza humana é pensar que isso é demais para enfrentar, então eu vou pular isso.

Outra razão pode ser que, embora considerem os testes uma boa idéia, não estejam confiantes sobre como começar a escrevê-los, especialmente se nunca trabalharam em nenhum lugar que os escreveu.

Outra possibilidade forte é que eles realmente não vêem valor para mais trabalho, mesmo que estejam dando um tom de boca na idéia.

Então, como você lida com os diferentes motivos?

O motivo é simples: mostre a eles um exemplo de como economiza tempo de desenvolvimento.

Razão dois - mostre a eles quantos testes você escreveu em um ano e qual a porcentagem da base de código que ele cobre. Faça as contas para mostrar quantos outros testes eles poderiam fazer no próximo ano se fizerem isso. Uma vez que eles veem que pequenos pedaços de progresso diariamente realmente se somam, toda a idéia não é tão avassaladora. Se você pode extrair os dados do sistema, mostre a eles quantos erros foram repetidos nas partes não testadas do código e quantos erros repetidos aparecem no código com testes de unidade.

A razão 3 é o treinamento, não apenas a exibição. Faça-os escrever testes em uma aula de treinamento.

Razão 4, este é o cerne da questão. Primeiro, escolha um ponto problemático, um daqueles erros que retornaram várias vezes. Quando isso chegar, é hora de sugerir à gerência que, se eles tivessem testes de unidade nesse item, ele não voltaria como um centavo ruim.

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

Todos nós gostamos de pensar que, como desenvolvedores, nós autogerenciamos (LOL), mas os ambiciosos se importam com o que o gerenciamento enfatiza para eles que eles devem se preocupar e os profissionais que realmente se autogerenciam já estão escrevendo os testes. Se eles não se importam em ser profissionais e em praticar as melhores práticas, porque melhoram o produto ou se importam em impressionar os gerentes a serem promovidos (ou não demitidos), considere se este é o lugar certo para você. Se você não conseguir que a gerência se preocupe com as melhores práticas, estará travando uma batalha árdua o tempo todo e novamente, poderá avaliar se essa é a cultura corporativa certa para você. Embora todo local de trabalho tenha seus problemas (e fugir nem sempre é a resposta), esse local não parece se encaixar no seu nível de profissionalismo.

Eu começaria 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 criam mais trabalho. Teste de unidade significa menos trabalho . Significa sair mais com os amigos. Significa se divertir mais, porque você não precisa passar todas as noites codificando até 23h. Significa sair de férias mais com tranqüilidade.

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 interrompa os testes, você pode ter 100% de confiança de que sua alteração não quebrou nada.

Outro ótimo argumento para o TDD é a criação de testes de unidade para 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 da base de códigos, entender seus pontos fortes e fracos, identificar a lógica de negócios codificada no código e dar-lhe um bom começo para melhorar a qualidade no futuro!

Boas referências para leitura adicional:

• Por que você deve escrever testes de unidade
• Visibilidade da motivação e teste de unidade
• A arte do teste de unidade, de acordo com Roy Osherove

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Acho que marquei o link de um artigo de Jeff Atwood há algum tempo [editar: sim, aqui está] . Velho, mas relevante. Devido a esses benefícios e a outros que, sem dúvida, serão descritos em outras respostas, seus programadores devem ser capazes de se motivar ! Isso permitirá que eles trabalhem com mais eficiência e, assim, tornem seu trabalho um pouco mais fácil. Quem não quer isso?

Com relação à sua segunda pergunta: seu senso de propriedade e orgulho dos 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 sempre sinto que estou fazendo um favor ao mundo / empresa / equipe implementando-os. Portanto, acho que você não está tentando fazer demais - os resultados variam de um lugar para outro, mas pelo menos você está se esforçando.

Este parece ser um grande caso de liderança por exemplo .

Existem dois aspectos inerentes à natureza humana que você está enfrentando:

• 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 gerenciais ou 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 TDD e funcionarem, o processo será expandido. Se não, não vai. Se você precisa convencer alguém, são os 1 ou 2 principais funcionários.

Pergunte a eles.

Você diz que as pessoas foram informadas e concorda que elas deveriam escrever mais testes. Por que eles não são?

Pode não (muitas vezes não é) uma questão de simples motivação. Eles podem esquecê-los. 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 não precisa fazer isso. Conhecer a causa raiz o ajudará a resolver melhor o problema.

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

Eu começaria perguntando a eles quantas vezes eles precisaram acordar no meio da noite para corrigir algum problema importante que poderia facilmente ser encontrado nos 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 em minha empresa, enviaríamos novos lançamentos ao controle de qualidade para testar todas as semanas. Eles criariam uma pilha de bugs nesse lançamento, corrigimos esses bugs e lançamos outro lançamento. Repita até terminar. O primeiro projeto que fizemos no TDD não exigiu um envio para o controle de qualidade até várias semanas depois. E o número de bugs encontrados foi muito, muito pequeno. 10% em comparação com um projeto semelhante. Você tem alguma maneira de compilar essas estatísticas para seu time?

O outro grande ponto de venda foi como o código adotou o TDD, foi mais fácil de ler, porque queríamos facilitar o teste. Mostrar uma comparação entre o código gravado para testes de unidade e o código não gravado.

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

Lembre-se disso quando não desejar escrever testes. :)

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

O próximo motivo é que, com uma grande base de códigos não testada, os testes de gravação provavelmente parecem esmagadores - um trabalho interminável (como lavar roupas e quase tão emocionante). Então a natureza humana é pensar que isso é demais para enfrentar, então eu vou pular isso.

Descobri que o código que eu escrevo com a intenção de escrever testes é um código significativamente melhor do que o código que eu 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. (Menor dependência de dados globais ou semi-globais; E / S separadas da computação; funções fazem apenas uma coisa; tratamento consistente de erros; e assim por diante.)

Tentar colocar testes em códigos antigos que não foram escritos com o teste em mente pode ser mais do que frustrante.

Eu usei algumas técnicas:

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

b) Faça projetos complexos com testes (você dirige). Isso mostrará como existem poucos erros nesse projeto. Eu tinha 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 o gerenciamento geral ficou satisfeito com ele. 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 ouve você. Assuma erros e mostre como os testes expõem problemas profundos e difíceis. Isso ajuda. Nunca é uma coisa fácil. Mas uma vez que você tenha um fã, ele apenas ajudará. É um efeito dominó.

Faça o teste de unidade no processo. Se um erro aparecer na produção que é óbvio demais para ser detectado no teste de unidade, esse cara é o culpado. Designe pessoas para escrever cada teste que fizerem. Escolha aleatoriamente casos e assista à execução de poucos casos toda semana. Ao fazer testes de unidade, as pessoas perguntam sobre os requisitos e, eventualmente, vinculam os requisitos ao desenvolvimento e esperamos desenvolver software que seja necessário e que funcione :)