¦ M ! L Є S i • B Λ S Γ Ø S ¦

Learning and Coolness – Beyond Code

Posts Tagueados ‘TDD

Refatoração

fazer um comentário »

(Astels, 2003), em seu livro, define refatoração como o processo de realizar alterações em um código já existente sem alterar o seu comportamento. Com o objetivo de melhor a estrutura interna do código, uma refatoração alterara a forma como o código produz algum comportamento sem alterar o que ele faz.

Refatoração e TDD estão intimamente relacionados de duas maneiras:

  • Depois de fazer a coisa mais simples para um teste passar, vamos refatorar para limpar o código e remover duplicidades.
  • Quando praticamos TDD temos um conjunto exaustivo de testes que nos dão confiança e coragem para refatorar.

Quando refatorar

De um modo geral, nós refatorar sempre que necessário. No entanto, (Astels, 2003) define três situações em que precisamos refatorar:

  • quando há duplicação;
  • quando percebemos que o código e / ou a sua intenção não é clara;
  • quando se detectar códigos cheiros, ou seja, sutis (ou não tão sutil) indícios de que há um problema.

Referências:


Astels, David. 2003. Test-Driven Development: A Practical Guide. s.l. : Prentice Hall, 2003.

Escrito por Antônio Milesi Bastos

20/dezembro/2010 em 09:09

Orientação a Testes

fazer um comentário »

Em seu trabalho, (Astels, 2003) define o Desenvolvimento Orientado a Teste (TDD) como um estilo de desenvolvimento onde:

  • você mantenha um exaustivo conjunto de Testes Automatizados;
  • nenhum código entra em produção a menos que tenha um teste associado;
  • você escreve primeiro os testes;
  • os testes determinam o código que você deve escrever.

No estudo publicado por (Aniche, 2010), baseado em experimentos na indústria e na academia. Ele mostra que TDD melhora o processo de desenvolvimento, aumenta a qualidades do código produzido, reduz o número de defeitos, diminui o tempo gasto com depuração e até aumenta a produtividade dos desenvolvedores.

Manter um exaustivo conjunto de Testes Automatizados

Os Testes Automatizados testam se suas classes produzem o comportamento esperado. Embora sejam semelhantes aos Testes Unitários, eles são escritos por um motivo diferente. Os Testes Unitários são escritos para verificar se o código que foi escrito funciona. Testes Automatizados são escritos para definir o que esse código deve fazer.

Praticar TDD implica, em ter um exaustivo conjunto de testes. Isso porque para cada linha de código deve ter sido escrita como resposta a um teste. O que gera um conjunto exaustivo de testes.

Nenhum código entra em produção a menos que tenha alguns testes associados

Uma característica não existe até que haja um conjunto de testes para acompanha-la. Isso traz confiança e coragem para refatorar e integrar.

Escreva primeiro os testes

O teste define o que se espera do código produzido. Então, escreve-se um pequeno teste e apenas o código suficiente para fazê-lo passar, então um pouco mais de teste e um pouco mais de código, teste e código, etc.

Os testes determinam o código que você deve escrever

Escrever apenas o suficiente para passar no teste implica em fazer a coisa mais simples que possa funcionar, limitando o código que será produzido.

Referências:


Aniche, Mauricio. 2010. TDD realmente ajuda? www.aniche.com.br. [Online] 04 16, 2010. [Cited: 09 18, 2010.] http://www.aniche.com.br/2010/04/tdd-realmente-ajuda/.
Astels, David. 2003. Test-Driven Development: A Practical Guide. s.l. : Prentice Hall, 2003.

Escrito por Antônio Milesi Bastos

30/novembro/2010 em 09:09

Mantendo a capacidade evolutiva da Arquitetura

fazer um comentário »

Manter a capacidade evolutiva da arquitetura de um sistema vai além de definir um modelo de arquitetura, um conjunto de padrões e adotar boas práticas beneficiando-se do avanço das tecnologias e ferramentas de desenvolvimento. A equipe de desenvolvimento deve adotar práticas que ajudem a manter a capacidade evolutiva do software.

Tão rápido quanto o Movimento Ágil tem crescido, essas práticas vieram evoluindo. Algumas, a partir de práticas ágeis, antes focados no desenvolvedor, que se expandiram para incluir outros interessados como a equipe de qualidade e os gerentes de projetos entre outros.

Baseado neste sucesso, essas práticas estão agora sendo aplicadas em projetos de todos os tipos, Ágeis e Não-Ágeis, igualmente.

Os próximos posts serão sobre algumas dessas práticas, entre elas:


  • Orientação a Testes
  • Refatoração
  • Integração Contínua.

Escrito por Antônio Milesi Bastos

29/novembro/2010 em 09:09

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.