BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Quebrando paradigmas: Como mostrar o real benefício dos testes e TDD?

Quebrando paradigmas: Como mostrar o real benefício dos testes e TDD?

Favoritos

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?

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

  • 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.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT