O que significa TDD e qual é o seu benefício    

Olá pessoal!

Hoje vou publicar um mini artigo que fiz para a pós-graduação ano passado sobre TDD. Se fosse escrever hoje sobre o mesmo assunto, com certeza falaria de muitas coisas diferentes, mas neste post vou colocar o artigo exatamente como entreguei na faculdade. Provavelmente voltarei a abordar esse tema por aqui, e ai sim colocarei mais informações. Por ser um artigo acadêmico, ele é bem superficial e não técnico. Segue o texto na íntegra.


O que significa TDD e qual é o seu benefício

Fazer software com qualidade não é uma tarefa fácil. Especificações mal definidas e que mudam sempre, tecnologias e conhecimento sempre em evolução e mais uma série de fatores torna a construção de software uma tarefa muitas vezes ingrata. Quando dizemos Software de qualidade, temos que ter em mente que qualidade não é medida apenas por experiência do Usuário ou grau de completude da especificação funcional. Qualidade de Software deve contemplar todos os aspectos do mesmo, como o código. Em código temos vários outros fatores que podemos citar, como legibilidade, complexidade, desempenho e o que mais interessa esse artigo, manutenção. Uma manutenção difícil em código pode acabar com o funcionamento de um sistema e causar perdas inestimáveis.

Teste é a principal ferramenta para alcançar a qualidade de Software. Ao longo de um desenvolvimento de Software, vários tipos de testes são executados, cada tipo é especifico para uma fase do desenvolvimento. Para o escopo do código, o tipo de testes apropriado é o Teste de Unidade ou Unitário, que visa validar cada pequeno trecho de código e conferir que ele está executando conforme esperado. Em um cenário onde a mudança é constante esse risco deve ser mitigado ao mínimo e Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes, é uma ferramenta que se encaixa perfeitamente nesse cenário. TDD é a prática de desenvolver Testes Unitários antes de desenvolver a unidade, para dessa forma direcionar o desenvolvimento da unidade.

“Código limpo que funciona é o objetivo do TDD. Código limpo que funciona é um objetivo que vale a pena por uma série de razões: Prediz a forma de desenvolver. Você sabe quando terminou, sem a preocupação de uma lista de erros. Permite seu time confiar em você. Melhora a vida do seu usuário. Possibilita aprender do seu código tudo que ele tem para te ensinar.” [1]

TDD prega que você deve codificar o teste do seu código antes mesmo de escrevê-lo, dessa forma, a primeira pergunta que você deve fazer ao iniciar o desenvolvimento não é “Como devo desenvolver este código”, mas sim “Como devo testar esse código”. Um dos benefícios dessa abordagem é que ao pensar nos testes, o desenvolver irá desejar códigos fáceis de testar, dessa forma com os testes prontos, ele será forçado a desenvolver um código limpo, desacoplado, do contrario será muito difícil realizar o teste.

Todo software de qualidade tem a maior parte do seu código testado, métrica essa chamada de Code Coverage. Com o TDD, você tem a certeza que 100% do seu código está testado, pois ele só foi escrito depois que você o testou. Comprovadamente, você gastará menos tempo com código testado ao alterá-lo do que com código sem testes. Código sem teste é legado para o próprio desenvolvedor que o desenvolve.

“Você provavelmente terminará o seu sistema com o mesmo número de linhas de testes que o número de código funcional quando implementar TDD. Para TDD fazer sentido economicamente, você precisa estar apto a desenvolver duas vezes mais linha de código por dia ou a metade de linhas para desenvolver a mesma funcionalidade” [1]. Quando uma pessoa está iniciando em TDD, é normal se questionar apenas com a realidade de ter que desenvolver mais rápido, e isso motiva muitos profissionais a desistirem dessa técnica. Porém, como afirmado anteriormente, o código desenvolvido com TDD é mais limpo, simples e enxuto, logo, no maior número de vezes, o seu código é que vai cair pela metade no número de linhas, e não sua produtividade terá que aumentar.

Ainda que seu código não diminua, em muitos casos você não terá que aumentar a capacidade de velocidade de desenvolvimento, pois se você desenvolver cem linhas de código com testes perderá X tempo para realizar manutenção no mesmo, por outro lado, se você fizer o mesmo número de linhas de código sem testes, o tempo que perderá para fazer manutenção em algum código é imprevisível, mas será sempre maior que X.

Podemos saber que está na hora de começar a desenvolver testes para nosso código no momento que o nível de Stress para realizar uma manutenção nele for alto. Ou seja, quando o desenvolvedor ao deparar com um código necessitado de manutenção o Stress do time aumenta? Então você não sabe o que está falhando. Esse sentimento é comum em projetos sem testes, com TDD o nível de Stress de uma equipe tende a zero, pois o erro é rapidamente explicitado por testes, e você sabe exatamente o momento que a manutenção está completada, pois os novos testes criados antes das alterações estarão passando. Para implementar TDD em uma equipe, comece com indicadores que mostre o nível de Stress ou Medo da sua Equipe. Mostre a evolução desse índice conforme o TDD for sendo adotado.

Todas as práticas utilizadas em testes devem ser adotadas em TDD, como testes isolados, simples, etc; mas com TDD alguns outros passos também devem ser considerados, tais como fazer pequenos passos (baby steps), não ter pressa de fazer um teste passar, etc. Essas são boas práticas que facilitam a vida de pessoas iniciantes no Desenvolvimento Orientado a Testes, mas que devem ser seguidas por todos os desenvolvedores experientes. “Escaladores conservadores têm uma regra de que pelo menos três dos quatro membros do corpo devem estar presos à montanha ao mesmo tempo. Movimentos rápidos onde são tirados dois membros ao mesmo tempo são muito arriscados.” [1]. Essa mesma regra deve ser seguida por desenvolvedores, não ter pressa de pular os pequenos passos ao desenvolver os testes, dessa forma, terá certeza que a maior parte do código está sendo testado, e seu Nível de Medo será praticamente zero ao entregar o software.

Apesar de TDD ser muito aplicado quando o time segue Metodologias Ágeis de desenvolvimento, essa técnica pode e até mesmo deve ser adotada por qualquer tipo de time, como aqueles que utilizam RUP, por exemplo. Com testes, você pode confiar em refatoração, Builds automáticos, e com TDD você pode confiar, além de tudo isso, que seu time entrega software não só que roda, mas que faz o que é certo, pois você codificou o que ele precisava fazer de acordo com um teste previamente escrito, e não testou algo que já estava escrito sem garantia que ele fizesse o que deveria.

Com TDD, concluí-se que é possível fazer “código limpo que funciona” e que é possível ser agradável criar software de qualidade sem altos níveis de Stress.

[1] Beck, Kent; Test-Driven Development by Example. Addison Wesley,2003


É isso. Até o próximo post.

31. janeiro 2013 09:21 by Frederico B. Emídio | Comments (0) | Permalink

Sobre mim

Minha Imagem

Meu nome é Frederico Batista Emídio, trabalho com desenvolvimento de sistemas profissionalmente a oito anos, porém, já faço sites pessoais a pelo menos dez anos.

Para saber mais clique aqui.

Páginas

Calendário

<<  novembro 2017  >>
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Visualizar posts em um Calendário
Sigua @fredemidio

MCP Asp.NET