Como convencer colegas de equipe a usar o TDD [fechado]

Eu sou a única pessoa na minha equipe que usa TDD. Como faço para que eles usem?

Estou aborrecido porque, quando eu puxo, o código de alguém interrompe meus testes e sou eu quem precisa corrigi-los.

O uso da solicitação github, fork e pull resolverá esse problema, para que eles precisem passar no teste antes que a pull seja aceita?

Não sou o gerente do projeto e não consigo convencê-la a usá-lo.

Na minha opinião, a única maneira de convencer sobre os testes é demonstrar que eles são úteis - ou seja, que as falhas nos testes ajudam a encontrar e corrigir bugs .

A maneira como você descreve o problema, parece que este não é o caso aqui. Veja...

... quando eu puxo, o código de alguém interrompe meus testes e sou eu quem precisa corrigi-los.

Se bem entendi, você quer dizer que precisa modificar os testes. Bem, isso não soa como falhas de teste que ajudam a encontrar e corrigir bugs, não é? Se os testes não ajudarem a encontrar bugs, é uma posição bastante fraca para convencer seus colegas - o que eles poderiam esperar ganhar? correções tediosas no código de teste frágil?

Isso pode parecer um beco sem saída, mas realmente não é. Seu objetivo final (convencer o TDD) ainda faz muito sentido, não o deixe cair. Apenas concentre seus esforços novamente em remover o obstáculo que você descobriu.

As falhas de teste que o incomodam agora são essencialmente "alertas falsos" - o que significa que são erros nos testes que não estão no código. Use-os como uma oportunidade para aprimorar testes e aprender como criar um bom design de teste confiável. Trabalhe em testes para tornar os "alertas falsos" menos frequentes e para facilitar a descoberta de erros reais no código testado.

Ao descobrir erros reais, informe seus colegas e ajude-os a corrigir - e não se esqueça de apontar que esses erros foram encontrados pelos seus testes. Isso criará um terreno realmente sólido para convencer seus colegas.

Vale ressaltar que as habilidades de design de teste que você desenvolve no estágio "preliminar" provavelmente serão necessárias novamente se (quando :) você finalmente convencer seus colegas de equipe a usar o TDD. Pense nisso...

... O que aconteceria quando o desenvolvimento orientado a testes fosse apresentado a seus colegas inexperientes?

A primeira coisa a esperar é que os caras comecem a escrever testes de baixa qualidade e (horror!) Até quebrem os bons enquanto aprendem. Para ajudá-los a encontrar uma maneira de fazê-lo corretamente, você precisará de um entendimento sólido do bom design de teste.

Todos os erros que você encontra e corrige em seus testes agora serão repetidos várias vezes por todos os seus colegas de equipe quando começarem a aprender. Se (quando!) Isso acontecer, é melhor você estar preparado para explicar rápida e claramente como melhorar se deseja que eles continuem positivos sobre o TDD.

Quando quis incentivar o uso do Test Driven Development , executei um Cyber-Dojo . Com esse tipo de exercício, a ênfase não está no código em si, mas no processo de escrita do código .

Passamos uma tarde, em pares, repetindo o mesmo kata, mas sob condições diferentes. Começamos com todos os grupos fazendo um exercício ao mesmo tempo. Isso forneceu uma linha de base.

Em seguida, discutimos alguns dos princípios básicos do TDD, todos mudaram de parceiro e repetiram o mesmo kata. Repetimos o mesmo kata para enfatizar menos a geração de código e, em vez disso, concentrar as pessoas no processo de nomear casos de teste e no ciclo Vermelho / Verde.

Em seguida, repetimos o kata novamente, mas aproximadamente a cada 10 minutos uma pessoa em cada grupo se deslocava para outro grupo, simulando os ambientes de equipe bastante fluidos que costumamos encontrar nos dias de hoje.

Na iteração final, os dois parceiros foram alterados a cada 10 minutos ou mais em grupos diferentes. Isso ajudou a demonstrar que, com o TDD, mesmo a transferência de uma equipe para uma equipe completamente diferente não precisa necessariamente ser muito dolorosa, pois o projeto deve ter apenas um ciclo de vermelho / verde a cada trabalho.

O interessante é que havia poucas pessoas que haviam feito algum TDD antes da sessão, mas que conhecimento sobre TDD havia se espalhado rapidamente até a iteração final através do kata, a maioria das pessoas estava pensando de uma maneira TDD ou pelo menos podia entender por que pode ser benéfico.

As pessoas geralmente diziam que a tarde foi divertida e informativa e agora estamos procurando outras maneiras de usar o Cyber-Dojo no meu local de trabalho.

O Cyber-Dojo , escrito por Jon Jagger , funciona incrivelmente bem para esse tipo de exercício. É um ambiente baseado na web integrada para fazer a prática deliberada de TDD e aprender sobre a dinâmica da equipe. Ele tem muitos katas selecionados especificamente para ajudar as pessoas a se concentrarem no processo de TDD e não no problema. Ele também suporta uma variedade de linguagens, de Python e Ruby a Java e C ++.

O melhor é que, depois de fazer um kata, você pode voltar e observar a progressão vermelho / verde (ou talvez não * 8 ') de cada um dos grupos participantes. Os semáforos são uma ótima maneira de visualizar como o processo TDD funciona.

Se você deseja seu próprio servidor CyberDojo, todo o projeto pode ser encontrado no github e há até uma máquina virtual do dispositivo Turnkey Linux vinculada a partir daí, o que significa que, assumindo que você já possui o VMware player ou o VirtualBox instalado, você pode estar em funcionamento no alguns minutos de download do aparelho!

Se eles resistirem ao TDD, está tudo bem. Muitas pessoas (inclusive eu) estão tendo problemas para escrever testes de unidade primeiro.

No entanto, você deve fazer uma pergunta sobre não ter nenhum teste de unidade e a questão da quebra dos testes de unidade. Os testes de unidade são uma rede de segurança que evita muitos possíveis erros e permite a refatoração de código. Explique sobre qualidade de código mais alta e código mais limpo.

Acho que o melhor seria encontrar um vídeo que explique as vantagens do uso do TDD e mostrá-lo em uma reunião.

Se ela se recusar a ouvir, você pode tentar procurar alguém acima dela, mas isso pode não ser muito inteligente se o seu chefe for tão teimoso.

É realmente difícil convencer as pessoas a mudar seus hábitos, mas aqui estão algumas coisas que você pode tentar:

• Converse com os outros desenvolvedores e explique a eles por que você acha que o TDD é uma boa ideia.
• Convença-os (ou pelo menos alguns deles) a experimentá-lo por um tempo limitado
• Tente estabelecer alguns requisitos mínimos para trabalhar bem em equipe. Eles não precisam necessariamente fazer TDD, mas certamente não devem verificar o código que está falhando nos testes de unidade. Essa é uma questão separada do que convencê-los a usar o TDD e é muito mais importante de resolver.
• Tente convencer a gerência a impor um período de teste para TDD. Você precisará estar pronto para fornecer algumas evidências sobre por que essa é uma boa prática e como economizará tempo e dinheiro da empresa no futuro.

Se nada disso funcionar, considere trabalhar em outro lugar. Existem muitas outras empresas em que sua vida seria consideravelmente mais fácil.

Existem duas questões ligeiramente diferentes aqui: levar as pessoas a fazer TDD e as pessoas que quebram seus testes.

Não tenho certeza sobre o primeiro problema. Pessoalmente, acho que é uma maneira artificial de trabalhar e que não é adequada a todos os tipos de desenvolvimento. Sou a favor de ter um bom conjunto de testes de unidade, mas geralmente acho mais eficiente escrever o código primeiro e depois os testes, pois ao escrever o código, minhas idéias estão sempre mudando e é uma perda de tempo escrevendo testes também cedo (IMO).

Na segunda questão, configure o projeto para que os testes de unidade sejam executados no check-in, para que outros desenvolvedores não tenham outra escolha a não ser saber que eles quebraram um teste.

Como já foi dito em muitos outros "como convencer o X a usar o método / tecnologia Y", minha resposta é sempre a mesma: por exemplo.

Use-o e tenha melhores resultados (mensuráveis). Depois, verifique se os outros notam.

Em um projeto existente, você não. É o mesmo que fazer alterações na maneira como os colchetes são colocados no código legado, porque você não gosta do estilo de indentação.

Muitos bons conselhos. E agora, um pouco mais ...

Você deve conquistar corações e mentes (WHAM), um ludita de cada vez. Esqueça de forçá-lo pela garganta. Muitas lições sobre objetos durante um período indeterminado (desculpe por isso). Eventualmente, você atingirá uma massa crítica e convencerá a pessoa "certa".

Seu entusiasmo constante e consistente e a vocação para TDD são muito importantes em uma campanha WHAM.

Você deve transformar as quebras de teste e de código em momentos de aprendizado, as lições que são importantes para seus codificadores. Torne pessoal. IE Eles se preocupam com a reputação de fornecer código limpo acima da média? Eles se preocupam com o gerenciamento que os incomoda sobre o código que está atrasado porque os testadores de integração lhes deram uma verificação da realidade? Jack deseja modificar algum código difícil, mas tem medo de efeitos colaterais?

Reúna bons exemplos de quebra de teste como interceptar erros induzidos pelo codificador. Os codificadores verão os testes alterados como um trabalho desnecessário para códigos irrelevantes; eles devem entender que os testes apenas cobriram suas bundas.

Encontre algum código com implicações globais (algum método simples de utilidade), crie alguns testes e demonstre que os testes permitem mudanças sem medo de terremotos em todo o aplicativo. E pretendo enfatizar também a questão emocional!

Reúna alguns exemplos simples de tempo para limpeza do código (isto é, passados ​​para a produção) e demonstre que, apesar do esforço extra para a codificação de teste , conseguimos fazê-la mais rapidamente e com maior qualidade.

Aviso: O TDD não é uma cura e não pode superar o design e a codificação incorretos de OO (mas definitivamente pode expô-lo). Não deixe que os luditas culpem o esforço do código de teste por sua incompetência.

Eu tentaria tentar novamente convencer o gerente. Pelo que você escreveu, não acho que você possa convencer seus colegas de equipe a fazer TDD pelas costas.

Você tem que falar a língua dela. O gerente tende a não se impressionar com a tecnologia, mas entende o idioma da empresa:

• Os testes economizarão tempo durante o desenvolvimento, porque, em vez de testes manuais (tentando reproduzir erros localmente, jogando com o console do rails ...), você executará os testes automaticamente

• O teste economizará muito tempo durante a manutenção do aplicativo, quando você poderá detectar facilmente erros sempre que alterar alguma coisa. Explique que os testes exigem maior investimento inicial, mas se pagam a longo prazo (a manutenção de bons testes geralmente é rápida e fácil)

• e o que você fará com o tempo extra? criar coisas moar e fazê-los ganhar dinheiro :)

Quanto aos programadores, tente este argumento (funcionou para mim, há muito tempo): "Você está testando código de qualquer maneira, com ou sem TDD. Somente você o faz manualmente, em vez de automatizá-lo. Desenvolvedores inteligentes automatizam o máximo de coisas possível. "

Em projetos reais com prazos, as pessoas querem se concentrar em realizar o trabalho com o que sabem. Essa é apenas a natureza humana. E se você nunca aprendeu TDD, seria o mesmo que ela nessa situação. Eu garanto.

Por que a multidão da coleta de lixo não ama, aprende e vive a RAII? Como você pode defender o gerenciamento automático de memória, mas manter o gerenciamento antiquado de recursos gerais, como arquivos, conexões etc.? Como o RAII é uma tecnologia que eles não conhecem, entendem e não têm tempo para usar quando têm um prazo que precisa ser feito.

Aposto que você não usa o RAII e não está disposto a aprender e entender o projeto atual. O mesmo que seu colega de trabalho que não está disposto a aprender e entender o TDD.