Delphi Clean Code

Artigos sobre Técnicas Ágeis de Desenvolvimento de Software com Delphi

TDD – Desenvolvimento Orientado a

Testes com Delphi

TDD – Desenvolvimento Orientado a Testes (Test Driven Development) é uma técnica de

desenvolvimento de software relacionado aos conceitos de XP (Programação Extrema). que
baseia em um ciclo curto de repetições.

O ciclo de desenvolvimento com TDD se resume em:

1 – Primeiro crie os testes unitários. 

2 – Crie o código até que os testes funcionem.

 3 – Refatore o código. 

TDD é uma das formas de manter seu código funcionando seguramente mesmo que sejam
feitas mudanças radicais no projeto. O primeiro passo, onde é requisito escrever um teste
antes de ter o código final desenvolvido no projeto, certamente é o ponto mais difícil de
entendimento entre profissionais e equipes que ainda não conhecem esta técnica.

O fato é que nesta primeira etapa é justamente onde você vai entender dentre muitas outras
coisas, que terá uma regra seguramente funcionando antes de partir para o desenvolvimento
do código.

Como assim? Você está me dizendo que “do nada” eu tenho que codificar uma regra?

Você ainda pode estar se perguntando: “Se eu ainda não tenho o código que funciona, como terei
um teste para ele?”

Eu lhe digo, justamente! A regra no caso do TDD é justamente ter um teste que ainda não
funcione, para que você passe para a segunda etapa que é “Criar um código que faça seu teste
funcionar”, certo?

Para que isto se torne possível, neste texto irei falar do uso do framework DUnitX.

DUnitX é um framework open-source que pode ser utilizado no Delphi a partir da versão 2010.
Ele é baseado em frameworks como NUnit e xUnit, contendo inúmeros métodos para
implementação de testes unitários de suas classes e métodos. DUnitX utiliza métodos
anônimos e generics. Existem muitos artigos e videos com exemplos práticos a serem
explorados, a princípio você pode conhecer um pouco mais sobre este framework, conceitos e
métodos a serem utilizados em:
http://docwiki.embarcadero.com/RADStud…/…/en/DUnitX_Overview

Ok, mas voltando ao texto,  isso pode não está bem claro ainda, então vamos ao tal código do
teste.

Antes quero lhe dizer que cada teste, deve ser baseado em uma regra compreendida pela
análise do problema a ser resolvido, então vamos ver um exemplo comum para iniciar.

Caso do teste:

Ao iniciar uma venda, em seguida finalizar a mesma venda sem itens lançados,

 o sistema deverá informar o usuário por diálogo de exceção, com a seguinte
mensagem “É necessário pelo menos um item lançado para finalizar a venda”.
Observe a estrutura das classes de Venda. Note que não existem implementações desta regra
de negócio na classe TVenda.

Mas isto não impede a criação dos métodos de teste, pois é justamente o que deve ser feito
quando se trabalha com TDD, Desenvolvimento Orientado a Testes!

Agora vamos ver como é feito o Teste:

E o que este teste quer dizer mesmo?

Simples! Vamos ver cada parte demonstrada por cores.

Verde: Este método Setup serve para que seja executado algo para cada método
de teste, isto ajuda para que você separe a parte de inicialização de variáveis e
instancias de objetos e deixe seu código somente com a regra a ser testada.

Vermelho: É outro método a ser executado, desta vez após todo método de teste
que for implementado. Assim como o Setup, neste método, você pode liberar
possíveis objetos da memória e até executar outros procedimentos como finalizar
uma conexão por exemplo.

Amarelo: Este é o primeiro método de teste conforme nosso caso relatado acima!

E como foi implementado este teste?

No framework de testes DUnitX,  existe a classe Assert que contém inúmeros métodos para
que possa ser feito várias condições, para nosso caso, foi utilizado o
método  WillRaiseWithMessage (a grosso modo quer dizer: Irá(deverá) levantar uma exceção
contendo a seguinte mensagem). Para este método, podem ser passados os seguintes
parâmetros:
 1 – Um procedimento anônimo com uma implementação que deverá ser a
mesma utilizada no sistema, ou seja, Inicia uma venda e Finaliza uma venda,
neste caso sem lançar nenhum item, assim como previsto no Caso de teste.

2 – Uma classe de exceção, pode ser nil caso não tiver nenhuma específica.

3 – A mensagem que será esperada pelo sistema ao ocorrer o caso  do teste. Esta
mensagem tem que ser exatamente a mesma, caso contrário o teste irá falhar.

Pronto! Assim concluímos a primeira etapa do teste, este teste já pode ser executado e deverá
dar errado, é isso que precisamos fazer até o momento.

Olhe o resultado ao executar o teste:

Pode comemorar, o teste falhou!

Veja só o que temos, o retorno de que o teste FinalizarVendaSemItensLancados não retornou

um exceção como esperado!

Agora sim já podemos partir para o segundo passo que é justamente fazer isto acontecer em
nossa classe, consequentemente na aplicação onde ela será utilizada.

O que precisamos fazer é simplesmente codificar nossa classe para que dispare uma exceção
com a mensagem esperada pelo teste, então observe um exemplo de como isto pode ser feito
na classe TVenda:
Assim, ao chamar o método Finalizar, será verificado se existem itens lançados, caso não
existam é disparado a exceção com a mensagem correspondente.

Então ao executar novamente a aplicação de testes, devemos receber o seguinte resultado.

A partir deste modelo, você já pode criar outros testes unitários para sua classe, não há limites
para isto, o ideal é que sejam atendidos 100% dos possíveis casos de sua aplicação, quanto
mais casos forem atendidos melhor!

Bom, isto está longe de ser um material completo sobre testes unitários, porém já é o
suficiente para que você conheça como irá finalmente garantir que sua aplicação se torne
segura independente da mudança sofrida durante a vida do projeto

Para finalizar quero ressaltar alguns benefícios ao adotar TDD:

Certeza de que se algum outro desenvolvedor acidentalmente mudar a regra de negócio na

aplicação, o teste irá falhar antes que chegue ao cliente.
Conhecimento de todas as regras de negócio ao ler os casos de testes.
Identificar rapidamente regras incorretas ou obsoletas.
Facilidade de alocação de um novo profissional para o projeto sem maiores riscos de mexer
em código que já estava funcionando.
Identificar quais são os mínimos e máximos argumentos para que regras de negócio sejam
atendidas (eliminando redundância e métodos desnecessários).
Documentação de regras de negócio, baseada nos casos de testes.
Confiança!

É isso ai, muito obrigado por ler este artigo e não para por aqui, estou editando alguns videos
onde certamente falarei mais sobre testes :d

Obrigado.

Carlos Eduardo – Delphi Clean Code

 

Sponsored Content

Como Corrigir o Nutricionista Revela [Fotos] A Câmera Não

Envelhecimento da Pele Como Reduzir a Gordura Devia Estar Ligada,
(Faça Isso Todos os Dias) Abdominal Maiores Erros Em Filmes
Especialista em Beleza - Dr. Rafael Fre… Receitas Modernas | Sponsored Restwow | Sponsored

[Fotos] Famosos que [Fotos] Aos 55 anos, 30+ Piores Alimentos Que
largaram a fama por Padre Marcelo Rossi vive Consumimos Diariamente
empregos normais no luxo Revista Investing | Sponsored
Revista Investing | Sponsored Revista Investing | Sponsored

Você sente dores na Pessoas que sofrem com [Fotos] Essa prisão é uma
lombar ou nas costas? ronco devem ler isso. das mais famosas do
Então precisa conhecer… Solução é simples. mundo por um motivo…
portadanoticia.com.br | Sponsored especiariasorientais.com.br | Sponsored Revista Investing | Sponsored

Autor: Delphi Clean Code

Blog dedicado a publicação de metodologias ágeis e boas práticas de desenvolvimento utilizando a
linguagem Delphi Ver todos posts por Delphi Clean Code

Delphi Clean Code / 26 26+00:00 abril 26+00:00 2016 / Artigos

6 comentários em “TDD – Desenvolvimento Orientado a
Testes com Delphi”

Andre Luiz Oliveira

26 26+00:00 abril 26+00:00 2016 às 12:43

Se todos os sistemas fizessem o uso de técnicas assim o mundo seria melhor kakaka

 Curtido por 1 pessoa

Delphi Clean Code 

26 26+00:00 abril 26+00:00 2016 às 12:52

Concordo Andre Luiz,

Desenvolver sem TDD é se aventurar em terras desconhecidas, correndo riscos constantes e
sujeito a surpresas desagradáveis.

 Curtir

Éverton Bueno Lima

26 26+00:00 abril 26+00:00 2016 às 22:59

Parabéns pelo post, muito bem explicado, eu ainda não tinha utilizado o dunit em meus
projetos, mas pelo seu post me incentivou a aplicar, espero novos post sobre o tdd.

 Curtir

Delphi Clean Code 

27 27+00:00 abril 27+00:00 2016 às 02:20

Obrigado! TDD é muito bom, fico feliz que tenha lhe motivado, com certeza virão mais
conteúdos sobre o assunto, continue acompanhando os canais e aproveite para assinar o
Blog e receberá em primeira mão as novidades. Valeu!

 Curtir
 Conde
29 29+00:00 abril 29+00:00 2017 às 15:51

n veja como critica, mas li o seu post e n me senti convencido em usar TDD.
n qro dizer q é ruim ou coisa do tipo, mas ainda n vi algo q fizesse sentido para mim, talvez o
exemplo n tenha sido bom (no meu caso), sugere algum outro conteudo ou pretende lancar
algo mais sobre?

 Curtir

Delphi Clean Code 

29 29+00:00 abril 29+00:00 2017 às 16:11

Olá @Conde tudo bem?

Primeiramente obrigado pelo feedback sobre o artigo!

Entendo perfeitamente e tem razão o artigo se trata de uma visão bem básica sobre TDD.

Recentemente tuitei a seguinte frase sobre TDD: “E se você pudesse testar antes de tomar
decisões em sua vida?” , talvez isso lhe ajude a refletir sobre o uso de TDD.
E claro, pretendo sim escrever muito sobre TDD, inclusive estou preparando uma série de
videos e artigos, onde tentarei levar ao conhecimento de testes utilizando exemplos reais do
dia a dia. Estou envolvido em projetos que não me permite as publicações no tempo que
gostaria. Aproveito e lhe peço para ue se tiver exemplos em seu seguimento que queira
questionar como seria o uso do TDD, estou a disposição para tentar esclarecer e quem sabe
até um material como estudo de caso.

Abraços, fique com Deus.

 Curtir

Delphi Clean Code / Blog no WordPress.com.