Ian Sommerville: Desisto do TDD (Test-driven Development)

No assunto de Engenharia de Software, Ian Sommerville dispensa qualquer apresentação. 

Agora um professor aposentado, ele traz um reflexão interessante sobre TDD (Test-driven Development), ou em português mais claro, abordagem de desenvolvimento de testar primeiro e codificar depois

Depois de tentar utilizar TDD em um projeto ele desistiu e explica as razões neste post: "http://iansommerville.com/systems-software-and-technology/giving-up..." (último acesso em 17-março-20160).

Sommerville lista quatro motivos que o levaram a desistir de TDD. Resumo estes motivos: 

  1. Queremos que os testes sejam executados com sucesso, logo, é provável que este fato nos afete psicologicamente a não realizarmos testes exaustivos.
  2. Testamos melhor quando o software não é nosso
  3. Risco de focar demais em aspectos do testes e não no software em si que, em última instância, é o que importa.
  4. Muitas falhas tem origem na baixa qualidade dos dados (input). Para Sommerville é difícil gerar dados com "erros".

Você pode concordar ou não com o mestre da Engenharia de Software, mas isto não invalida a nossa reflexão e discussão.

(texto original em http://www.papodecafe.com/curtas/2016/3/18/ian-so, 18-março-2016)

Exibições: 407

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Cirilo Lourenço Xavier Junior em 21 março 2016 às 12:13

É claro que toda opinião merece respeito, e esta é de uma figura respeitada no mundo do software.

No entanto, dos 4 pontos que ele usa como justificativa, somente o último achei razoável. Quanto aos outros, minha opinião é:

  • O cara que simplesmente quer fazer o teste passar, não entendeu ou não valoriza a técnica, logo esse vai sempre ser resistente ao TDD e é o mesmo que fazer uma média entre 2, 6, 4 e 1000, sem destacar o 1000 que é ponto fora da curva. Perde totalmente a representatividade.
  • Se trabalhamos para uma empresa, normalmente o software é de terceiro, logo a qualidade e empenho nos testes é uma questão de profissionalismo. Além do mais testar algo "dos outros" ou "feito por outros" ou "do qual você não domina" é válido para testes exploratórios. Para testes funcionais e para o TDD (que não é só teste. É muito mais design de código), quanto mais você dominar o assunto e for íntimo dele melhor.
  • O TDD não é sobre focar muito em testes, mas como já falei, sobre design. E bom design favorece testes, pois segue as boas práticas universais de baixo acoplamento, alta coesão...
Comentário de Ricardo Faria em 21 março 2016 às 7:47

Li o texto original, e ele cita que os problemas começaram a partir do momento em que resolveu construir uma GUI utilizando TDD, acredito que talvez a tecnologia de GUI utilizada não tivesse um suporte simples (haja visto Android).

Um dos trechos que mais me chamou atenção foi na parte em que ele cita que o TDD ti faz focar mais em decisão que permita testes do que a decisão certa. Mas a pergunta que fica é, a decisão que permite que o seu código seja testável não é a mais correta? A melhor decisão do mundo, mas que não possa ser testada certamente é uma solução frágil. Claro, sabemos até onde é possível testar com TDD, e de certo ponto pra frente nem é o foco da disciplina utilizá-lo.

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço