Quebrando paradigmas: Como mostrar o real benefício dos testes e TDD?
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
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
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.
Conteúdo educacional
Lean na Globo.com
Bernardo Heynemann 24 Mai, 2013
Mobilidade: Frameworks, SOs e o Mercado
Ricardo Ogliari 23 Mai, 2013
Caminhos de uma estratégia mobile
Sérgio Lopes 23 Mai, 2013
Complexidade organizacional no Século 21
Alexandre Magno 16 Mai, 2013

Olá visitante
Você precisa cadastrar-se no InfoQ Brasil ou Login para enviar comentários. Há muitas vantagens em se cadastrar.Obtenha o máximo da experiência do InfoQ Brasil.
Dê sua opinião