Como explicar testes para uma pessoa que nunca escreveu sequer um teste? Como mudar a visão de um programador mostrando que testes são sim úteis? Se para um desenvolvedor já é difícil mudar sua mente em favor dos testes e TDD qual será o esforço necessário para que um gerente fique de acordo com tal prática?
Recente surgiu uma discussão no fórum de arquitetura, o Tectura, sobre como fazer com que um programador mude a sua visão sobre testes e TDD. Carlos Alberto, programador e adepto aos testes, questionou sobre como mostrar para um desenvolvedor a real utilidade dos testes garantindo que ele vá adotar TDD como prática de desenvolvimento.
[...] a introdução de práticas ágeis em um ambiente novo, sempre é um grande desafio, principalmente na diferença que existe entre o conhecimento de um programador habituado com TDD e um não habituado.
O que pode ser feito para ajudar o outro desenvolvedor a ver a utilidade de uma prática de testes? Como demonstrar para os gerentes o benefício real relacionado a aplicação de TDD no desenvolvimento de software?
André Brito sugere a realização de DOJOS mas que no fim, a única forma de convencer alguém de utiliza testes e fazendo com que o mesmo pratique, ele diz:
O que pode ser feito para ajudar o outro desenvolvedor a ver a utilidade de uma prática de testes?
Acho que uma boa forma pra ‘convencer’ o programador é fazer dojos. É muito mais divertido parear e ir em baby-steps do que pensar no problema como um todo e tentar resolver ele. Hoje em dia não uso TDD ‘formalmente’ onde trabalho, mas sempre que tenho algum problema de lógica (problemas relacionados a cálculos, por exemplo), uso TDD fora do projeto pra encontrar e trazer a solução.
Então acho que a melhor forma de convencer ele a usar TDD é… fazendo ele usar! [...]
Como demonstrar para os gerentes o benefício real relacionado a aplicação de TDD no desenvolvimento de software?
[...] eu tento convencer o povo aqui por meio dos casos de sucesso do TDD em empresas de renome (vide Yahoo, Gcom e Caelum). Se não é o suficiente, argumento que ao usar TDD o design melhora (e muito). [...]
Maurício Aniche que é programador e possui uma tese de mestrado na área de TDD, complementa a idéia de André mostrando onde está o real valor do TDD.
Ver um monte de testes quebrarem mostra ao programador o valor dos testes automatizados. Independente se ele escreveu antes ou depois.
O verdadeiro valor do TDD está no design, e isso é muito difícil de mostrar a curto prazo. O valor de um bom design, vem depois: fácil de dar manutenção, fácil de evoluir.
E ensinar isso pra alguém não é fácil. Geralmente ele nem conhece xUnit, e fica tão focado no framework que esquece de ver o feedback que o teste dá pra ele no design.
Acho que só com ele praticando TDD, aprendendo com os testes e evoluindo o design pouco a pouco, é que ele vai ver que TDD é uma ferramenta legal e vale a pena usar.
É interessante perceber que todas as opiniões levam a prática, devemos sempre tentar, cada vez mais, incluir o TDD como prática diária, para que depois de um tempo ele perceba o real benefício dos testes, como manutenção, segurança no refatoramento, design evolutivo, entre outros.
E você leitor, o que poderia sugerir para desenvolvedores que desejam adotar o TDD porém não conseguem visualizar o real benefício da prática. Como vocês apresentariam isso para um gerente?
Como vocês apresentariam isso para um gerente?
by Hudson Leite,
Re: Como vocês apresentariam isso para um gerente?
by Waldyr Felix,
Como vocês apresentariam isso para um gerente?
by Hudson Leite,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Ainda estou tentando convencer a mim dos reais benefícios, pois encontro muitos obstáculos conceituais, como por exemplo: quando começar; quando parar; melhor, quando usar.
Quanto a apresentar para um gerente, escolhi começar por uma espécie de "Testes de Aceitação", que posteriormente serão usados como "Testes de Regressão", utilizando ferramentas menos como o Easyb aliado ao Selenium.
Recentemente tivemos um problema de padronização no desenvolvimento que precisou passar por uma "refatoração" muito grande, o que fez surgir muitos problemas, tais como: coisas que antes funcionavam, pararam; tempo perdido realizando a verificação manual do que se estava "mexendo".
Fiz uma pequena demonstração para os colegas bem como para o gerente, automatizando alguns cenários de um dos módulos do sistema em questão, na esperança de convencê-los dos benefícios de se utilizar essa abordagem no projeto.
Acredito que utilizando uma espécie de metodologia "Top-Down", podemos seguir construindo um "Design" mais focado no que realmente importa para o usuário final e a medida que nos aprofundamos na implementação propriamente dita vão surgindo desafios que são mais facilmente resolvidos (ou a complexidade é melhor gerenciada) utilizando a prática do TDD.
Dessa forma acredito que o ambiente influencia muito na forma como as coisas são conduzidas, e para tanto, cada um tem que adequar a prática ao seu próprio contexto. Não estou convencido da existência de uma "receita de bolo".
Re: Como vocês apresentariam isso para um gerente?
by Waldyr Felix,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Pois é Hudson, vc acabou de citar mais um grande benefício de se usar TDD. Quando tempos uma boa cobertura de testes no sistema, ganhamos mais liberdade para refatorar o sistema como e quando quisermos, pois se algo deixar de funcionar os testes vão quebrar.
E se pensarmos bem, se não usarmos TDD, o que garante que ao alterar uma funcionalidade qualquer do sistema, ele continuará funcionando? Com TDD fica mais fácil refatorar e avaliar o impacto de mudanças na aplicação.