Como convencer os colegas de equipe a usar o TDD [closed]

14

Eu sou a única pessoa na minha equipe que usa o TDD. Como faço para usá-lo?

Estou incomodado que quando eu puxar o código de alguém irá interromper meus testes e eu sou o único que tem que consertá-los.

O uso do github, fork e pull irá resolver este problema, para que eles precisem passar no teste antes que o pull seja aceito?

Eu não sou o gerente de projetos e não consigo convencê-la a usá-lo.

    
por wizztjh 12.04.2012 / 08:09
fonte

10 respostas

5

Do jeito que eu vejo, a única maneira de convencer qualquer coisa sobre testes é demonstrar que eles são úteis - isto é, que as falhas de teste ajudam a encontrar e corrigir erros .

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

...when I pull, someone's code will break my tests and I am the one who has to fix them.

Se eu entendi corretamente, você quer dizer que você tem que modificar testes. Bem, isso não soa como falhas de teste ajudam a encontrar e corrigir erros faz isso? Se os testes não ajudam a encontrar bugs, é uma posição bastante fraca para começar a convencer seus colegas - o que eles poderiam esperar ganhar? consertos tediosos no código de teste frágil?

Isso pode soar como um beco sem saída, mas na verdade não é. Seu objetivo final (convencer para TDD) ainda faz muito sentido, não deixe cair. Apenas reorientem seus esforços para remover o obstáculo que você descobriu.

As falhas de teste que o incomodam agora são essencialmente "alertas falsos" - o que significa que esses erros não estão no código. Use-os como uma oportunidade para melhorar os testes, para aprender como fazer um bom projeto 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.

À medida que você descobrir bugs reais, informe seus colegas e ajude-os a corrigir - e não se esqueça de apontar que esses bugs são encontrados em seus testes. Isso tornará um terreno realmente sólido para convencer seus colegas.

Vale a pena mencionar que as habilidades de teste de design 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 para testes fosse apresentado aos seus colegas inexperientes?

A primeira coisa a esperar é que os caras começarão a escrever testes ruins e (horror!) até quebrar os bons enquanto aprendem. Para ajudá-los a encontrar uma maneira correta de fazer isso, você precisará ter uma compreensão sólida do bom design de teste.

Todos os erros que você encontrar e consertar em seus testes agora serão repetidos novamente por todos os seus colegas de equipe quando eles começarem a aprender. Se (quando!) Isso acontecer, é melhor você estar preparado para explicar de forma rápida e clara como melhorar se quiser que eles permaneçam positivos sobre o TDD.

    
por 13.04.2012 / 21:38
fonte
12

Quando quis incentivar o uso de Desenvolvimento orientado a testes , executei um Cyber-Dojo . Com esse tipo de exercício, a ênfase não está no próprio código, mas no processo de escrever o 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, se todos mudassem de parceiro e repetissem o mesmo kata. Repetimos o mesmo kata para não enfatizar a geração de código e, em vez disso, concentramos as pessoas no processo de nomeação de casos de teste e no ciclo Vermelho / Verde.

Em seguida, repetimos o kata novamente, mas a cada 10 minutos, aproximadamente, uma pessoa de cada grupo se mudaria para outro grupo, simulando os ambientes de equipe bastante fluidos com os quais nos encontramos frequentemente nos dias de hoje.

Na iteração final, tivemos que os parceiros mudassem a cada 10 minutos em diferentes grupos. Isso ajudou a demonstrar que, com TDD, até mesmo a transferência de uma equipe para outra completamente diferente não precisa necessariamente ser muito dolorosa, já que o projeto deve ser apenas um ciclo Vermelho / Verde do trabalho.

O interessante foi que havia poucas pessoas que haviam feito qualquer TDD antes da sessão, mas que conhecimento do TDD havia rapidamente espalhado até a iteração final através do kata, a maioria das pessoas estava pensando em um modo TDD ou podia pelo menos Aprecie por que isso pode ser benéfico.

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

Cyber-Dojo , escrito por Jon Jagger , funciona incrivelmente bem para este tipo de exercício. É um ambiente integrado baseado na web para fazer prática deliberada de TDD e aprendendo 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 ++.

A melhor coisa é, depois de fazer um kata, você pode voltar e olhar para a progressão vermelha / verde (ou talvez não * 8 ') de cada um dos grupos participantes. É semáforos uma ótima maneira de visualizar como o processo TDD funciona.

Se você quiser seu próprio servidor CyberDojo, o projeto inteiro pode ser encontrado no github e há até mesmo um Turnkey Linux máquina virtual ligada a partir daí, o que significa que você já tem VMware player ou VirtualBox instalado, você pode estar instalado e funcionando dentro de alguns minutos após o download do aparelho!

    
por 12.04.2012 / 13:46
fonte
8

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

No entanto, você deve levantar uma questão sobre não ter nenhum teste unitário, e a questão da quebra dos testes de unidade. Testes de unidade são uma rede de segurança que evita muitos bugs possíveis e permite a refatoração de código. Explique sobre qualidade superior de código e código mais limpo.

Acho que o melhor seria encontrar um vídeo que explique as vantagens de usar o TDD e exibi-lo em uma reunião.

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

    
por 12.04.2012 / 08:19
fonte
6

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

  • Converse com os outros desenvolvedores e explique para 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 necessariamente têm que fazer TDD, mas certamente não deveriam estar verificando o código que está falhando nos testes de unidade. Esta é uma questão separada do que convencê-los a usar o TDD, e é muito mais importante abordar.
  • Tente convencer a administração a impor um período de teste para o TDD. Você terá que estar pronto para fornecer algumas evidências sobre por que essa é uma boa prática e como ela economizará tempo e dinheiro para a empresa no futuro.

Se nada disso funcionar, você pode querer considerar trabalhar em outro lugar. Há muitas outras empresas em que sua vida seria consideravelmente mais fácil.

    
por 12.04.2012 / 08:23
fonte
6

Há duas questões ligeiramente diferentes: fazer com que as pessoas façam TDD e as pessoas quebrem seus testes.

Eu não tenho certeza sobre o primeiro problema, pessoalmente acho que é uma maneira artificial de trabalhar e não adequada para todos os tipos de desenvolvimento. Eu sou todo para ter um bom conjunto de testes unitários, mas eu costumo achar mais eficiente escrever o código primeiro e depois os testes, já que enquanto escrevo o código minhas idéias estão sempre mudando, e é uma perda de tempo escrever testes também cedo (IMO).

Na segunda ediçã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.

    
por 12.04.2012 / 09:24
fonte
4

Como disse em muitos outros "como eu deveria convencer X a usar o método / tecnologia Y", minha resposta é sempre a mesma: por exemplo.

Use e tenha melhores resultados (mensuráveis). Em seguida, certifique-se de que os outros percebam.

    
por 12.04.2012 / 17:17
fonte
2

Em um projeto existente, você não faz isso. É o mesmo que se você estivesse fazendo alterações na forma como as chaves são colocadas no código legado porque você não gosta do estilo de recuo.

    
por 12.04.2012 / 08:40
fonte
2

Muito bom conselho. E agora, um pouco mais ...

Você deve ganhar corações e mentes (WHAM) um Luddite de cada vez. Esqueça sobre forçá-lo a descer suas gargantas. Muitas lições sobre objetos por um período indefinido (desculpe por isso). Eventualmente você atingirá uma massa crítica, convencerá a pessoa "certa".

Seu entusiasmo constante e consistente & A vocação para TDD é muito importante em uma campanha WHAM.

Você deve transformar as alterações de código e teste em momentos de aprendizado, as lições que importam para os seus co-programadores. Torne isso pessoal. I.E. Eles se importam com a reputação de fornecer código limpo acima da média? Eles se preocupam com o gerenciamento de problemas sobre o código que está atrasado porque os testadores de integração deram a eles uma checagem de realidade? Jack tem o desejo de modificar algum código difícil, mas tem medo de efeitos colaterais?

Reúna bons exemplos de quebra de teste como erros induzidos por codificadores de trapping. Os codificadores verão mudanças nos testes como trabalho desnecessário para código irrelevante; eles devem entender que os testes apenas cobriam suas bundas.

Encontre algum código com implicações globais (algum método utilitário simples), construa alguns testes e, em seguida, demonstre que os testes permitem mudanças sem medo de terremotos em todo o aplicativo. E eu quero enfatizar o questão emocional também!

Reúna alguns exemplos simples de tempo para limpar códigos (ou seja, passados para produção) e demonstre que apesar do esforço extra para codificação de teste , fizemos ela mais rápido & com maior qualidade.

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

    
por 12.04.2012 / 16:41
fonte
1

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

Você tem que falar a língua dela. O gerente não costuma ficar impressionado com a tecnologia, mas entende a linguagem comercial:

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

  • O teste de
  • economizará muito tempo durante a manutenção do aplicativo, quando você puder detectar bugs facilmente sempre que alterar alguma coisa. Explique que os testes exigem um investimento inicial maior, mas eles 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 torná-los dinheiro moar:)

Quanto aos programadores, tente este argumento (funcionou para mim, muito tempo atrás): "Você está testando código de qualquer maneira, com ou sem TDD. Somente você faz isso manualmente em vez de automatizá-lo. Desenvolvedores inteligentes automatizam como muitas coisas que puderem. "

    
por 12.04.2012 / 09:31
fonte
0

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

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

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

    
por 12.04.2012 / 14:37
fonte