devmedia - versão para impressão.pdf

7/24/2019 DevMedia - Verso para impresso.pdf

1/20

10/11/2015 DevMedia - Verso para impresso

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=3&artigo=3150&revista=impressao_125#a-3150 1/20

DevMedia - Verso para impresso

Desenvolvimento gilEntenda a relao entre desenvolvimento gil e testes unitrios

Do que trata o artigo

Este artigo explica o que desenvolvimento gil e ensina como criar um projeto seguindo o

princpio de desenvolvimento dirigido por testes. At o final do artigo voc aprender como

executar testes unitrios com DUnit e como usar o Discover para saber quanto do seu cdigo

ainda no foi testado, alm de entender quais so as tcnicas mais interessantes para testar

um software.

Para que serve

O desenvolvimento dirigido por testes ajuda a codificar mais rpido, programas que tero

menos falhas. Um programa que foi desenvolvido com metodologias geis normalmente so

mais claros e flexveis diante das mudanas do dia-a-dia.

Em que situao o tema til

Executar testes uma tarefa imprescindvel para o desenvolvimento de um bom software.

Quando eles so aplicados juntamente com o uso da ferramenta Discover, voc pode chegar

a ter 100% de todas as linhas do seu cdigo testadas. Isto com certeza far seu projeto

amadurecer.

Resumo do DevMan

Os testes automatizados ajudam manter o projeto estvel mesmo aps grandes mudanas.

Este artigo explica o que so testes unitrios e que eles tm a ver com programao gil alm

de ensinar como criar testes automatizados com o DUnit, que vem integrado ao Delphi desde

a verso 2005. No final de tudo, voc aprender como usar o Discover para saber se os

testes deixaram escapar algum bug.

Rafael StavarengoLinkedIn: http://linkedin.com/in/stavarengo

Antes de tudo preciso saber que no importa se o teste ser feito com tcnicas

automatizadas ou no, o importante e testar. Existem outras maneiras de testar o software,

como por exemplo, contratar pessoas especialmente para esta funo. Esta provavelmente
http://www.devmedia.com.br/revista-clubedelphihttp://www.devmedia.com.br/autor.asp?id=69348http://www.devmedia.com.br/revista-clubedelphi


2/20



no a melhor alternativa, mas possvel e deve trazer bons resultados. O importante

executar os testes no importa se eles sero automatizados ou no. Por outro lado, alm de

tornar o software mais barato, quando voc automatiza os testes voc tambm codifica mais

rpido e quando tiver que fazer modificaes poder faz-las mais facilmente e com mais

segurana: voc no estar preocupado se sua ltima alterao estragou outras partes do

sistema. comum que as pessoas se assustem quando comeam a estudar sobre teste

unitrio, pois existem muitos termos tcnicos sobre o assunto como caixa branca, testes de

regresso, fases de testes, entre outras. Isso o suficiente para assustar algum queprovavelmente no vai mais nem querer ouvir falar em tcnicas de testes. Todos estes termos

fazem os testes parecerem complicados, mas no so. Vou explicar o porqu.

Por que os testes so simples Existe uma sequncia natural para o processo de desenvolvimento de um projeto e os testes

esto nesta seqncia.

Quando voc comea a criar um programa ou uma nova parte dele, naturalmente a primeira

coisa que voc precisa saber o que esta nova funo deve fazer, sendo assim os testes

devem ser criados para validar se a nova opo faz o que deveria fazer. Depois que os testes passarem o sistema estar fazendo o que precisa: a prxima etapa

garantir que ele faz do jeito certo. Para isto outros testes sero executados, seja por voc

mesmo ou por outras pessoas. Nesta etapa sero testados itens como desempenho em

situaes extremas, facilidade de uso, clareza das mensagens, padronizao das telas,

funcionalidade entre outras coisas: o objetivo refinar a opo. Existe um tipo de teste que se

adapta melhor para cada tipo de refinamento, por este motivo existem tantos termos

tcnicos. No se concentre de mais com o nome de cada fase (refinamento): tenha em mente

que cada opo deve passar por vrias fases de testes para melhorar a qualidade.

Todo este processo natural. Primeiro o sistema codificado par afazer o que precisa fazer.

Depois uma srie de procedimentos so executados para refinar o programa e garantir que

ele faz o que deve fazer do jeito certo. Voc poderia fazer isso sem estudar nada sobre

testes, mas seria mais difcil. As tcnicas de testes existem para facilitar o trabalho de

refinamento e aumentar a qualidade do software.

Teste de software: o que ? Teste de software qualquer procedimento com o objetivo de provar que o software no

funciona corretamente.

Estes procedimentos podem ser executados por uma pessoa ou podem ser automatizados

em pilhas de testes que ficaram cada vez mais completas medida que o projeto madurece.

A diferena mais evidente entre um projeto desenvolvido orientado a testes e outro no

orientado a testes est no processo de desenvolvimento.

Enquanto que um comea a partir do teste automatizado e s criado o necessrio para o

teste passar, o outro simplesmente construdo e em algum momento no futuro os testes

sero executados por um humano. Por serem executados por humanos no h garantia de

que os testes sero fielmente repetidos sempre que algo mudar.

comum pensar que criar classes de testes aumenta o tempo de desenvolvimento do

software tornando-o mais caro e at mesmo invivel.

Este um pensamento equivocado, pois de modo geral programas desenvolvidos com baseem testes so mais simples e fazem somente o que devem fazer uma vez que ser escrito

somente o necessrio para o teste passar. Dificilmente o tempo desperdiado com algo que

no seja realmente necessrio.


3/20



Quem programa com bases nos testes que cria, ganha tempo quando precisa encontrar um

erro, pois raramente ser necessrio debugar o programa para encontrar um erro: basta

rodar o teste e ele aponta onde exatamente est o problema. Algumas metodologias de

desenvolvimento de software nos levam a criar classes de testes antes mesmo de criar a

opo em si: este a meu ver o cenrio ideal. No decorrer deste artigo voc ver como fazer

isso.

Escrever testes para todas as classes que voc criar deve ser uma realidade no seu dia-a-

dia. Alm de ser um requisito do modelo ISO de qualidade de software, os testes levaro oseu projeto para outro nvel de qualidade. claro que a qualidade dos testes, e

consequentemente do produto final, depende diretamente da pessoa envolvida, mas mesmo

assim um programa desenvolvido orientado a testes normalmente consegue atingir o objetivo

com mais clareza e em menos tempo.

Teste de software: o que NO ? Testar um software no debugar. Ao contrrio da fase de codificao, cujo objetivo

construir o software, o teste um processo que visa desmont-lo para provar que ele no

funciona ou que tem erros.Os testes devem ser escritos como se quem os escreve tivesse sido desafiado a provar que

o programa tem falhas, como se j soubesse que as falhas existem e encontr-las apenas

uma questo de tempo.

difcil garantir que um software no tem erros, visto que normalmente existem muitas

variveis para avaliar, o que aumenta a complexidade.

Um software pode falhar por vrios motivos, como: problemas de hardware, erros de

codificao, requisitos errados, mensagens pouco claras, entre outros motivos.

A quantidade de pessoas envolvidas no projeto e qualificao de cada uma tambm

influencia diretamente na qualidade do produto final.

Alm disso tudo, ainda tem o fato de que as alteraes so constantes e normalmente

muitas ao mesmo tempo: parece um ambiente catico para quem no conhece.

Ainda hoje existem pessoas que pensam nos testes como uma tarefa secundria, porm h

muito tempo escrever testes passou a ser uma fase do desenvolvimento assim como a

anlise e implantao.

Os testes fornecem informaes preciosas sobre o nvel de qualidade de software em

relao ao contexto que ele pertence.

Modelo de qualidade Existe um modelo base de qualidade, ou seja, existem documentos que descrevem como

um programa deve se comportar para ser considerado de boa qualidade. O modelo ISO de

qualidade de software considera quatro categorias diferentes para as falhas de um software,

so elas: processo de desenvolvimento, qualidade interna, qualidade externa e qualidade

percebida pelo usurio. Estas categorias englobam pelo menos seis caractersticas que no

podem faltar em um software: usabilidade, funcionalidade, confiabilidade, eficincia,

portabilidade e manutenibilidade.

Alcanar os nveis mais elevados de qualidade definidos pelos rgos responsveis no

uma tarefa muito simples. Para facilitar este trabalho os testes foram divididos em fasesdiferentes, cada uma delas focada em testar um determinado aspecto do sistema. sobre

estas fases que voc ver a seguir.


4/20



Fases de teste Se voc testa o seu projeto, ento provavelmente j executa testes para a maioria das fases

que cito a seguir, mesmo sem saber que elas existem.

Isto acontece porque o processo de teste algo natural e voc no precisa conhecer as

fases para poder execut-lo, embora conhec-las facilita o trabalho e aumenta o

profissionalismo. a fase de teste que o projeto se encontra que diz qual o objetivo do teste

que deve ser executado e a partir da possvel saber qual tcnica de teste a maisapropriada para o tal objetivo. A seguir eu cito algumas fases de testes e posteriormente as

tcnicas mais interessantes. Existe uma fase chamada teste de unidade. Ela acontece ao

mesmo tempo em que as opes esto sendo criadas. O objetivo testar unidade por

unidade do programa: cada classe/arquivo deve ter pelo menos outra classe de teste

especialmente para ela. As tcnicas de caixa branca e caixa preta so excelentes exemplos

de tcnicas para esta fase, pois para testar as unidades o testador precisa necessariamente

ter acesso ao cdigo fonte do projeto. Equipes que trabalham com desenvolvimento gil

normalmente criaram estes testes antes de comear a codificar a opo propriamente dita.

Outra fase a teste de integrao. Nesta fase o objetivo garantir que a comunicao

esteja fluindo bem entre os componentes (ou mdulos, como preferir), do sistema. Mais uma

vez deve existir uma srie de classes de testes para garantir, por exemplo, que uma venda

no ser feita em quanto um balano estiver em execuo.

Este teste tambm pode ser executado por um humano interagindo com a interface do

programa, embora tambm existam maneiras de automatizar testes que interagem com a

interface como se fossem usurios. Os testes da categoria no funcionais so executados nas

fases Testes de desempenho e testes de carga. Como o prprio nome diz, nestas fases o

objetivo descobrir qual o limite de informao que o sistema consegue processar at que

seu desempenho seja considerado inaceitvel. Depois desta fase ser mais fcil identificarquais os requisitos mnimos para o software. Existem ainda outras fases como, por exemplo,

testes de sistema e testes de aceitao. Durante a fase testes de sistema os testes so

executados por algum que realmente entende como o usurio ir trabalhar no dia-a-dia, pois

nesta fase o sistema deve ser usado como de fato ser usado quando estiver em produo.

Posteriormente vem a fase dos testes de aceitao. Estes testes devem ser executados por

um grupo seleto de usurio que diro se o programa aceitvel para a realidade.

Tcnicas de testes Voc viu que para facilitar o trabalho de testar um projeto foram criadas fases de testes cadauma com o objetivo de descobrir falhas de categorias diferentes.

Alm das fases, tambm existem tcnicas de testes. Algumas das tcnicas mais populares

so: caixa branca, caixa preta, e regresso. Cada uma destas tcnicas funciona melhor para

encontrar falhas de uma ou mais categorias.

Enquanto a fase do teste diz qual o tipo de falha deve ser procurada, as tcnicas ajudam a

encontrar as falhas propriamente ditas. Por exemplo, durante a fase de teste de desempenho

o objetivo encontrar falhas que ocorrem quando o software estiver no limite de

processamento e a tcnica de testes no funcionais a melhor para encontrar falhas desta

categoria.

As tcnicas e fases existem para facilitar o trabalho de testar um software sem deixar de

testar nenhuma caracterstica. como se todas estas fases e tcnicas juntas formassem um

protocolo de testes, que quando seguido garantem um selo de qualidade superior.

A seguir voc ver um pouco sobre as tcnicas de testes mais populares. Estas tcnicas


5/20



podem ser usadas para encontrar falhas de mais de uma categoria.

Caixa Branca Testes de caixa branca so criados pela pessoa que tem acesso ao cdigo fonte, por isso

fica a cargo do prprio programador que criou a opo.

Este um tipo de teste bem difundido entre os desenvolvedores. Neste teste o programador

deve criar uma classe de teste para garantir que o comportamento interno de outra classeesteja correto. O objetivo garantir que a classe testada faa o que deve fazer sem erros. O

teste de caixa branca tambm conhecido como testes orientados a lgica, j que o

programador precisa conhecer como a classe a ser testada funciona internamente. O

resultado deve ser um teste que valide todos os caminhos possveis - todos os ifs e cases

opcionais - com esta tcnica de teste que o programador garante o bom fluxo de

informaes da classe testada. Frameworks como JUnit e DUnit, entre outros, so exemplos

de ferramentas para criar testes do tipo caixa branca. Estes frameworks facilitam a vida do

programador, pois a maioria do trabalho sujo necessrio para criar classes de testes j est

pronto, restando para o programador simplesmente criar os mtodos de testes. O DUnit vem

integrado ao Delphi desde a verso 2005. Mais adiante voltarei a falar sobre ele. Por hora

veja um exemplo de teste caixa branca feito com DUnit, na Listagem 1.

Caixa Preta O teste caixa preta, tambm conhecido como teste funcional o complemento do teste caixa

branca e vice-versa.

Enquanto o teste caixa branca concentra-se no comportamento interno da classe, o teste

caixa preta concentra-se no comportamento externo. Eles so usados para demonstrar que

as funes do software so operacionais.

De modo grosseiro, para executar este tipo de teste deve-se levantar todas as entradas

possveis para ento pass-las para o software que vai processar e devolver o resultado que

ser comparado com o valor que se espera para cada parmetro de entrada.

As entradas variam de acordo com a estrutura do programa e podem ser infinitas

dependendo do contexto: imagine quantas entradas diferentes existem para um programa

que aceita um ponto flutuante como parmetro.

O ideal sempre testar todas as entradas existentes, mas quando isto se torna invivel o

testador deve escolher um conjunto de entradas que garanta um teste mais completo

possvel.

O testador - que no precisa ser necessariamente o programador - deve garantir que a

sada de dados est de acordo com o esperado para cada entrada. Estes testes geralmente

identificam erros de categorias bem especficas, como: erro de inicializao, erro de interface,

erro de conexo com o banco de dados, erro de estrutura de dados, entre outros.

Repare que todos estes erros so referentes ao comportamento externo do programa, onde

a tcnica caixa preta atua.

Testes Caixa Cinza e no funcionais Os testes de caixa branca e caixa preta complementam um ao outro, pois sozinhos no so

capazes de identificar todos os erros e riscos que envolvem um programa. O teste caixa cinza

a juno destes dois testes. A tcnica de testes no funcionais visa garantir que o software

funciona mesmo em situaes extremas. So os testes no funcionais que garantem o bom

comportamento do sistema quando, por exemplo, a conexo com o banco de dados cair


6/20



inesperadamente. Para executar os testes no funcionais tambm comum usar uma grande

quantidade de dados para descobrir qual o limite do sistema. Aps passar por uma boa srie

de testes no funcionais o software provavelmente ser capaz de manter o controle da

situao e continuar funcionando mesmo quando algo inesperado sair errado.

Listagem 1. Exemplo de uma classe de teste caixa branca

1 unit TestPedidoDao

2 interface

3 uses

4 TestFramework , PedidoDao, Generics.Col lections, Pedido

5 type

6 TestTPedidoDa o = class(TTestCas e)

7 strict private

8 FPedidoDao: TPedidoDao

9 public

10 procedure SetUp override

11 procedure TearDown override

12 published

13 procedure TestPost

14 end

15 implementation

16 procedure TestTPedidoDao .SetUp

17 begin

18 FPedidoDao := TPedidoDao.Cr eate

19 end

20 procedure TestTPedidoDao .TearDown

21 begin

22 FPedidoDao.Free

23 FPedidoDao := nil

24 end

25 procedure TestTPedidoDao .TestPost

26 var

27 Pedido: TPedido

28 begin

29 CheckEquals(0 , FPedidoDao.Cou nt, A base deve estar vazia)

30 Pedido := TPedido.Create

31 Pedido.Id := 1

32 FPedidoDao.Post(Pedido)

33 CheckEquals(1 , FPedidoDao.Cou nt, No salvou o primeiro pedido)


35 CheckEquals(1 , FPedidoDao.Cou nt, Adicionou duas vezes o mesmo pedido)

36 Pedido := TPedido.Create

37 Pedido.Id := 2


39 CheckEquals(2 , FPedidoDao.Cou nt, No adicinou o segundo pedido)

40 end

41 initialization

42 RegisterTest(TestTPedidoDao.Suite)

43 end.

Testes de Regresso Normalmente voc aplica todos os testes para cada nova opo ou alterao do projeto e

quando chegar ao final de uma verso, todos os testes devem ser executados novamente


7/20



para garantir que nenhuma outra parte parou de funcionar por conta das modificaes feitas

durante o desenvolvimento da verso.

Executar todos os testes criados desde a primeira verso uma tcnica chamada de teste

de regresso.

Quando se cria testes automatizados voc tem a opo de execut-los todos de uma vez a

qualquer momento, para garantir que as alteraes no influenciaram o que estava

funcionando: esta mais uma (enorme), vantagem dos testes unitrios.

Imagine alterar grandes pedaos do projeto e ter certeza de que as outras partes no foramdanificadas - testes unitrios tornam o software mais maduro e deixam o programador mais

seguro do que faz.

Teste de regresso significa que todos os testes j criados desde a primeira verso do

projeto sero executados novamente para garantir que tudo saiu como esperado - este um

teste necessrio para garantir que as modificaes no causaram novos erros.

Esta tcnica normalmente usada no final de cada ciclo de desenvolvimento.

Metodologias de Desenvolvimento gil Algo comum hoje em dia encontrar vagas para desenvolvedores cujo um dos requisitos ter participado de alguma equipe que trabalhe com desenvolvimento gil. Metodologia gil

um conceito que visa trazer uma srie de vantagens para a equipe diminuindo os riscos que

envolvem produzir um software e tem como caracterstica a velocidade com que novas

funes so implementadas quando comparada com a metodologia convencional: semanas

ao invs de meses. Uma equipe de desenvolvimento gil normalmente tem comunicao em

tempo real tanto entre os integrantes da equipe quanto entre a equipe e as pessoas que

conhecem a definio do programa - por exemplo, os clientes. Para tornar o processo mais

gil esta comunicao deve ser preferencialmente feita frente a frente ao invs de usar

documentos - talvez por isso a baixa documentao seja considerada uma desvantagem das

metodologias geis. Um dos princpios dos mtodos geis que toda alterao deve trazer

uma nova funo e para conseguir isto o desenvolvimento divido em pequenos ciclos, como

se cada ciclo fosse um pequeno projeto dentro do projeto verdadeiro - um novo ciclo

iniciado sempre que alguma funo nova precisar ser implementada ou uma antiga precise

ser alterada.

Estes ciclos envolvem passos pr-determinados, que mudam de acordo com a metodologia.

Existem diversos mtodos de desenvolvimento gil e o rgo responsvel por promover estes

mtodos o The Agile Alliance. Segundo o site do The Agile Alliance, eles promovem os

princpios de desenvolvimento gil porque acreditam que estas metodologias tornam o

software mais produtivo humano e sustentvel. Uma das coisas que este rgo faz manter oThe Agile Manifesto (O Manifesto gil), onde est descrito quais so os valores e princpios

do desenvolvimento gil. Na sesso Links do artigo est um link para o site do The Agile

Alliance, onde existe, entre outras coisas, o The Agile Manifesto. Como disse, existe mais de

um mtodo de desenvolvimento gil, como por exemplo: Scrum, Dynamic System

Development Method, Feature Driven Development, Extreme Programing e Test Driven

Development, entre outros. A seguir vou falar um pouco sobre o mtodo Test Driven

Development e depois mostrarei o DUnit como uma alternativa para criar testes

automatizados.

TDD - Test Driven Development Test Driven Development que se traduz como Desenvolvimento Orientado a Testes ou

simplesmente TDD, assim como qualquer metodologia de desenvolvimento gil composta


8/20



por pequenos ciclos de desenvolvimentos.

Estes ciclos so formados por cinco passos: 1) Criar um teste 2) Executar o novo teste 3)

Criar a nova funo 4) Executar os testes novamente 5) Refatorar o cdigo.

A primeira coisa que deve ser feita para comear alterar ou criar qualquer opo dentro de

um software seguindo o mtodo orientado por testes, obviamente criar um teste. Este

primeiro teste deve ser criado antes da opo em si, por este motivo quando o teste for

executado a primeira vez ele falha obrigatoriamente, j que a opo ainda no existe. Depois

disto a opo comea a ser desenvolvida com o objetivo de fazer os testes passarem.

Quando tudo estiver certo e o teste no falhar mais, chega a hora de refatorar o cdigo para

tornar o projeto mais flexvel e reutilizvel - depois da refatorao voc pode executar os

testes novamente para garantir que a opo desenvolvida no parou de funcionar.

Este ciclo no pode ser muito demorado - no deve passar de quatro semanas e o ideal

seria uma semana. Se o ciclo demora muito para terminar os testes dos outros integrantes da

equipe comeam a falhar por conta da opo que ainda no est concluda. Este mtodo de

desenvolvimento focado nos requisitos do software, pois o programador comea

escrevendo testes validando somente o que pede o requisito. Consequentemente a opo

desenvolvida ser bem enxuta e objetiva, j que o programador escreve apenas o cdigonecessrio para fazer os testes passarem.

Sem perceber o programador acaba seguindo princpios como KISS (Keep It Simple Stupid)

e You Aint Gonna Need It (no adicionar funcionalidade at que seja necessrio).

DUnit Desde a verso 2005 o Delphi traz integrado ao IDE o DUnit. Este framework implementa

tudo o que voc precisa para comear a escrever classes de testes unitrios sem precisar

configurar nada, pois todo o necessrio j est implementado pelo framework. As classes detestes criadas com DUnit so bem simples, como deveria ser. Basicamente todos os testes

unitrios so criados com apenas dois passos: 1) Voc cria o ambiente 2) Voc executa os

testes.

Os testes unitrios devem ser independentes entre si, isto significa que todos os testes

devem ser capazes de rodar sozinho sem que outro teste precise ser executado antes. Alm

disto, os testes devem rodar sempre sobre as mesmas circunstncias, o que significa que o

teste no pode ser influenciado por variveis externas como, por exemplo, um banco de

dados bagunado. Se for assim, um teste que funciona hoje porque o banco est limpinho,

pode no funcionar amanh quando banco estiver povoado por outros testes: por isto o bancode dados deve sempre estar limpo quando o teste comear. Normalmente o prprio teste

limpa o banco de dados antes de comear.

comum que cada teste configure o ambiente antes de ser executado, como por exemplo,

criar a conexo e limpar o banco de dados - as tarefas necessrias para criar o ambiente

geralmente so repetitivas entre os testes. Para entender melhor o que significa configurar o

ambiente de teste, imagine que voc vai testar o CRUD (cadastro) de clientes.

Cada cliente deve estar necessariamente ligado em uma empresa, logo para poder testar o

CRUD de clientes necessrio que exista pelo menos uma empresa cadastrada, por este

motivo, cadastrar pelo menos uma empresa um exemplo de tarefa necessria para criar o

ambiente de teste.

Depois de configurar o ambiente hora de criar o teste propriamente dito: isto que voc

ver a seguir.


9/20



NotaO gerenciamento de informaes de um cadastro - salvar, buscar, atualizar, excluir -

tambm conhecido como CRUD. CRUD um acrnimo da uma expresso inglesa, cujas

letras significam: Create (salvar), Retrieve (buscar), Update (atualizar) e Delete (excluir).

Praticando Desenvolvimento gil Chegou o momento de juntar tudo que voc viu at agora, para isto vou simular o

desenvolvimento do CRUD de clientes.

Os requisitos desta funo foram definidos na Listagem 2. Com os requisitos definidos, resta

apenas comear a codificar - como se trata de um projeto desenvolvido baseado em testes, a

codificao sempre comea pelos testes e o objetivo do teste sempre garantir que est

sendo feito tudo que os requisitos mandam.

Na Figura 1 est o diagrama de classes com as entidades necessrias para criar o CRUD.

Com certeza, possvel criar um design melhor para esta aplicao, implementando

padres como Command ou Table Data Gateway.

Isto provavelmente tornaria o exemplo mais empolgante, porm seria necessrio explicar

muito sobre coisas que apesar de serem interessantes no so relevantes para o foco do

artigo.

Para criar o CRUD de clientes somente duas classes sero criadas: TCliente e TClienteDao -

todas as outras classes, como por exemplo, TEntidade, TEmpresa e TDao j existem no

projeto. A classe TDao uma classe abstrata que implementa as operaes bsicas para

manipular uma tabela: Salvar, Buscar, Excluir e Listar.

Alm disto tambm declara (mas no implementa), dois outros mtodos, so eles:

AntesDeSalvar para validar as informaes que sero salvas e AntesDeExcluir para verificar

se um registro realmente pode ser excludo.

TDao no implementa estes mtodos porque ela no pode prever todos os tipos de

informaes que sero salvas: TCliente, TEmpresa, entre outras.

Mesmo que pudesse prever seria um caos testar tudo dentro da mesma classe, por isto

TDao abstrata.

Sendo assim, deve existir uma subclasse de TDao para cada tipo de informao.

Por exemplo, para manipular a tabela de cliente vai existir uma subclasse chamadaTClienteDao e para a tabela de empresa vai existir TEmpresaDao.

So as subclasses de TDao que implementam os mtodos AntesDeSalvar e AntesDeExcluir.

A classe TDao sempre invoca o mtodo AntesDeSalvar antes de salvar um registro e

AntesDeExcluir antes de excluir um registro.

Estes mtodos por sua vez devem gerar uma exceo caso a respectiva operao no

puder ser executada.

Por exemplo, o mtodo AntesDeSalvar da classe TClienteDao deve gerar uma exceo se o

cliente estiver sem razo social.

Agora que voc j est familiarizado com as classes do projeto, est na hora de implementar

o CRUD de clientes, para isto primeiro os testes devem ser criados.

Veja a seguir como criar uma classe de teste unitrio com DUnit e entenda como ela

funciona.


10/20



Listagem 2. Requisitos para o CRUD de clientes

1. O cliente deve estar ligado a uma empresa

2. No podem existir dois clientes com o mesmo CPF para a mesma empresa

3. O usurio preenche apenas o nome e endereo do cliente.

[abrir imagem em janela]

Figura 1. Classes envolvidas no problema CRUD de clientes

Primeiro os testes Todo teste baseado puramente na lista de requisitos e foi lendo os requisitos da Listagem

2 que descobri que ser necessrio criar duas novas classes: TCliente e TClienteDao. Como

se trata de um projeto orientado a testes, os testes devem ser criados antes mesmo de criar

as classes envolvidas no problema: por isto a primeira verso dos testes vai falhar

obrigatoriamente.

Mas como escrever um teste para uma classe que no existe? Existem duas alternativas. A

primeira seria criar os testes e implantar uma falha propositalmente para indicar que as

classes ainda no foram criadas (veja exemplo na Listagem 3). A segunda alternativa criar

as classes que sero testadas, mas no implementar nenhuma lgica, ou seja, voc cria as

classes e declara os mtodos, mas no implementa nenhum deles. desta forma que mostro

a seguir.

Para comear vou criar as classes TClienteDao e TCliente, porm no vou implementar

nenhuma lgica. Isso garante que o teste vai compilar, j que a classe TClienteDao e todos

seus mtodos foram declarados, porm o teste vai falhar, pois no implementei nenhum dos

mtodos da classe. Veja na Listagem 4 a classe TCliente e na Listagem 5 a classe

TClienteDao.

Agora que as classes necessrias existem, possvel criar o teste. Para executar os testes

necessrio que exista uma interface para mostrar o resultado dos testes executados. Esta

interface j est pronta e para us-la voc s precisa criar um novo projeto especfico para

executar testes. Para criar um projeto de testes no Delphi 2010 voc deve escolher a opo

Test Project na janela New Items, como aparece na Figura 2. Ao clicar em Ok, aparece um

pequeno assistente com dois passos: no primeiro passo voc poder escolher o nome e o

local onde o projeto de teste ser salvo e no segundo passo apenas clique Finish. Vocpode salvar o projeto de teste em qualquer local, mas normalmente ele salvo dentro de uma

pasta chamada Test no diretrio do projeto verdadeiro (aquele que ser testado).

Listagem 3. Exemplo de uma classe de teste vazia


11/20



1 unit TestClienteDao

2 interface

3 uses

4 TestFramework

5 type

6 TestTClienteD ao = class(TTestCa se)

7 published

8 procedure TestVazio()

9 end

10 implementation

11 procedure TestTClienteDa o.TestVazio

12 begin

13 Fail(A classe TClienteDao precisa ser criada)

14 end

15 initialization

16 RegisterTest(TestTClienteDao.Suite)

17 end.

Listagem 4. A classe TCliente

1 unit Cliente

2 interface

3 uses Empresa, Entidade

4 type

5 TCliente = class(TEntida de)

6 public

7 Empresa: TEmpresa

8 RazaoSocial: string

9 Cpf: string

10 Endereco: string

11 end

12 implementation

13 end.

Listagem 5. O esqueleto da classe TClienteDao

1 unit ClienteDao

2 interface

3 uses Dao

4 type

5 TClienteDao = class(TDao)

6 end

7 implementation

8 end.



12/20



Figura 2. Criando um projeto de testes

Ao executar o projeto de teste (criado no pargrafo anterior), o formulrio da Figura 3 vai

aparecer. Esta a interface do DUnit: neste formulrio que os testes so executados e os

resultados sero exibidos. Voc no precisa mudar ou configurar mais nada, tudo j est

pronto, portanto, vou criar a primeira classe de teste unitrio.

Estendendo TTestCase Para escrever os testes eu devo voltar aos requisitos (Listagem 2), e em uma folha de papel

eu escrevo todos os testes necessrios para garantir que nenhum requisito ser esquecido.Veja na Listagem 6 quais so os testes que eu encontrei para a lista de requisitos da

Listagem 2.

Depois de definir os testes podem ser codificados. O Delphi possui um modelo para classes

de testes e para usar este modelo basta criar um Test Case, que aparece na Figura 2.

Quando pedir para criar um Test Case, o Delphi mostrar um assistente, com dois passos:

no primeiro passo voc escolhe a unit onde est a classe que deseja testar e no segundo

passo voc simplesmente clica em Finish.

Neste exemplo o arquivo ClienteDao.pas ser testado, pois o objetivo testar a classe

TClienteDao que existe dentro dele. Finalizando o assistente o Delphi mostra a nova a classe

de teste TestTClienteDao - esta a classe de teste unitrio que vai testar a classe

TClienteDao.

Veja na Listagem 7 como a classe TestTClienteDao aparece assim que o assistente para

adicionar um Test Case concludo.

Note na linha 6 que a classe TestTClienteDao estende de TTestCase. Esta uma classe do

framework DUnit - todos os seus testes unitrios devem estender dela para poder funcionar.

Na verdade esta classe faz muito mais do que simplesmente permitir que os testes

funcionem. A classe TTestCase tem a maioria (se no todos) os mtodos que voc precisa

para criar um teste. Os dois primeiro mtodos da classe TTestCase que voc precisa conhecer so: SetUp e

TearDown. O mtodo SetUp executado antes de cada teste e o mtodo TearDown depois

de cada teste - essa caracterstica torna estes mtodos ideais para configurar o ambiente de


13/20



teste como citado no tpico DUnit.

Repare que o Delphi sugeriu uma implementao para este dois mtodos: no SetUp criada

uma instncia da classe TClienteDao (classe que ser testada), e no TearDown a instncia

destruda.

Se fosse necessrio criar alguma conexo com o banco ou fazer alguma configurao extra

antes de executar os testes, neste mtodo que estas aes devem ser executadas.

Listagem 6. Testes para os requisitos da Listagem 2

1. No pode existir um cliente sem empresa

2. No podem existir dois clientes com o mesmo CPF para a mesma empresa

3. O campo razo social obrigatrio.

4. O campo endereo obrigatrio.

Listagem 7. Teste unitario para TClienteDao criada pelo Delphi

1 unit TestClienteDao

2 interface

3 uses

4 TestFramework , Cliente, Dao, ClienteDao

5 type

6 TestTClienteD ao = class(TTestCa se)

7 strict private

8 FClienteDao: TClienteDao

9 public

10 procedure SetUp override

11 procedure TearDown override

12 end

13 implementation

14 procedure TestTClienteDa o.SetUp

15 begin

16 FClienteDao := TClienteDao.Cr eate

17 end

18 procedure TestTClienteDa o.TearDown

19 begin

20 FClienteDao.Free

21 FClienteDao := nil

22 end

23 initialization

24 RegisterTest(TestTClienteDao.Suite)

25 end.



14/20



Figura 3. A interface do DUnit para executar testes

Para comear com a implementao dos testes eu vou configurar melhor o meu ambiente

de teste, por isto, vou alterar a implementao do mtodo SetUp (veja a nova implementao

na Listagem 8). Assim como na implementao sugerida pelo Delphi, uma instncia de

TClienteDao continua sendo criada, mas eu adicionei algumas instrues mais interessantes.

Veja na linha 4, que o mtodo CheckEquals executado para garantir no existe nenhum

cliente cadastrado, pois isto poderia atrapalhar o teste.

O mtodo CheckEquals mais um dos mtodos da classe TTestCase. Este mtodo vai

checar se o valor do primeiro parmetro igual ao valor do segundo parmetro: se eles foremdiferentes o teste falha - logo voc ver como identificar se um teste falhou ou no. O terceiro

parmetro deste mtodo - que opcional - indica qual a mensagem que ser exibida caso a

checagem falhe, ou seja, caso o primeiro parmetro seja diferente do segundo parmetro. A

classe TTestCase disponibiliza vrios mtodos que comeam com Check, cada um deles

tem um objetivo diferente: d uma olhada na classe TTestCase para ver todos os mtodos de

checagem existente - no so muitos.

Depois de instanciar TClienteDao e certificar de que no existem clientes cadastrados, a

vez de instanciar um objeto de TEmpresaDao e cadastrar uma empresa que ser usada

durante os testes.

Mas uma vez uso CheckEquals, porm desta vez ele usado para certificar que a nova

empresa realmente foi cadastrada - note que agora o terceiro parmetro no est sendo

usado. O ltimo detalhe antes de criar os testes sobre o mtodo NovaEmpresa. Cadastrar

empresa uma tarefa que pode ser repetida vrias vezes ao longo dos testes e o mtodo

NovaEmpresa deve facilitar isto - repare que ele j foi usado uma vez na linha 6.

NotaToda classe deveria ter outra classe de testes especfica para ela, mas neste exemplo eu

criei um teste apenas para classe TClienteDao. Fiz isto porque a classe TCliente apenasdeclara atributos e no tem nada que precise ser testado. Na vida real, em um projeto

mais robusto, tambm seria necessrio criar uma classe de testes para TCliente.


15/20



Reviso - como chegamos at aqui? Primeiro houve a necessidade de criar o CRUD de clientes para um projeto que j existia. Os

requisitos para este CRUD foram definidos e em seguida foi criado o esqueleto das classes

necessrias para tal funo. O esqueleto era as classes com a declarao dos mtodos sem

a implementao: o mnimo necessrio para poder executar os testes sem criar erros de

compilao.

A partir da lista de requisitos foi criada outra lista: a lista de testes.

Nesta lista foram escritos todos os testes necessrios para garantir que a classeTClienteDao funcione de acordo com os requisitos.

Qualquer teste que no esteja validando um requisito desperdcio de tempo.

O segundo passo foi criar o projeto de testes. Normalmente, para um projeto em andamento

o projeto de testes j estaria criado, mas fiz questo de explicar como cri-lo.

Com o projeto de testes criado, foi adicionado um Test Case para a classe TClienteDao.

Depois o ambiente de teste foi configurado modificando os mtodos SetUp e TearDown.

Agora vem a parte mais interessante: criar os mtodos de testes propriamente dito.

Existiro tantos mtodos de teste quantos foram os testes definidos para validar os

requisitos. Veja a seguir como criar e executar os testes.

Listagem 8. O mtodo SetUp definitivo

1 procedure TestTClienteDa o.SetUp

2 begin

3 FClienteDao := TClienteDao.Cr eate

4 CheckEquals(0 , FClienteDao.Li star.Count, Espera-se que a tabela de

clientes esteja vazia.)

5 FEmpresaDao := TEmpresaDao.Cr eate

6 FEmpresa := NovaEmpresa( 1, Empresa 1)

7 FEmpresaDao.Salvar(FEmpresa)

8 CheckEquals(1 , FEmpresaDao.Li star.Count)

9 end

10 function TestTClienteD ao.NovaEmpresa (Id: Integer Nome: string): TEmpresa

11 begin

12 Result := TEmpresa.Creat e

13 Result.Id := Id

14 Result.RazaoS ocial := Nome

15 end

Criando mtodos de teste De acordo com a Listagem 6 devem existir quatro mtodos de testes. Veja na Listagem 9

como o teste nmero 3 da Listagem 6 foi transformando em mtodo de teste para a classe

TestTClienteDao: foi criado o mtodo TestCampoRazaoSocialEhObrigatorio.

recomendado que os testes tenham um nome que deixe bem claro o que ele est testando,

por isto um nome to grande.

Os mtodos de testes so bem simples de entender: voc executa alguma coisa e em

seguida executa um mtodo Check para garantir que o que voc executou realmente

funcionou. Por exemplo, entre as linhas 6 e 10 tenta-se cadastrar um cliente sem razo social.

O comportamento esperado que o cliente no seja cadastrado, por isto na linha 11 um

CheckEquals executado para garantir que nenhum cliente foi cadastrado.

Este primeiro teste tenta cadastrar um cliente sem razo social e isto provavelmente deve

gerar uma exceo. Por isto o try..except entre as linhas 7 e 10. Este try..except esconde


16/20



qualquer exceo que possivelmente vai existir quando um cliente sem razo social tentar ser

cadastrado.

Depois de garantir que um cliente sem razo social no pode ser cadastrado, chegou a hora

de garantir que um cliente com razo social poder.

Isto acontece nas linhas 13 e 14 - note que desta vez no foi usado try..except. Na linha 15

um novo CheckEquals executado para garantir que existe um novo cliente cadastrado.

Antes de executar o teste, necessrio destacar que agora existem dois projetos quefuncionam em paralelo: um projeto a aplicao de verdade e outro projeto serve apenas

para executar os teste. Este segundo projeto aquele que expliquei como criar no tpico

Primeiro os testes. Uma vez que existem dois projetos, voc deve adicionar manualmente

no projeto de teste todas as units necessrias para faz-lo compilar. Neste exemplo, foi

necessrio adicionar as units TDao, TEmpresaDao, TEmpresa e TEntidade (veja diagrama na

Figura 1). As classes TClienteDao e TCliente foram adicionadas automaticamente quando

criei a Test Case no tpico Estendendo TTestCase.

Feita esta observao, voc est ponto para saber que s precisa pressionar F9 para

executar a aplicao de testes e a partir dela, executar o teste criado na Listagem 9. Veja na

Figura 4 a imagem da aplicao de teste aps executar os testes. Existem algumas

observaes importantes sobre as informaes que aparecem no formulrio da Figura 4.

A primeira coisa que somente o mtodo TestCampoRazaoSocialEhObrigatorio foi

reconhecido como sendo um mtodo de teste.

Os outros mtodos como, por exemplo, NovaEmpresa e NovoCliente no foram. Isto

acontece por que os mtodos de teste devem estar declarados na sesso published. Todos

os mtodos nesta sesso sero reconhecidos como mtodos de testes.

Listagem 9. Seu primeiro mtodo de teste

1 procedure TestTClienteDa o.TestCampoRaz aoSocialEhObri gatorio

2 var

3 Cliente: TCliente

4 begin

5 { Tenta salvar um cliente sem nome. }

6 Cliente := novoCliente(1 , , 11111111111, Rua X, FEmpresa)

7 try

8 FClienteDao.Salvar(Cliente)

9 except

10 end

11 CheckEquals(0 , FClienteDao.Li star.Count, Salvou cliente sem nome)

12 { Salva cliente com um nome vlido }

13 Cliente := novoCliente(1 , Miguel, 11111111111, Rua X, FEmpresa)

14 FClienteDao.Salvar(Cliente)

15 CheckEquals(1 , FClienteDao.Li star.Count, No salvou cliente com nome

vlido.)

16 end

17 function TestTClienteD ao.NovoCliente (Id: Integer Nome, Cpf, Endereco:

string

18 Empresa: TEmpresa): TCliente

19 begin

20 Result := TCliente.Creat e

21 Result.Id := Id

22 Result.RazaoS ocial := Nome

23 Result.Cpf := Cpf


17/20



24 Result.Endere co := Endereco

25 Result.Empres a := Empresa

26 end


Figura 4. Executando os testes

Outra informao importante que todos os testes falharam (neste caso s existe um). Mas

isto j era esperado, pois ainda no existe nenhuma lgica na classe TClienteDao. Repare

que a mensagem Salvou cliente sem nome aparece na parte destacada da imagem. Para

resolver este problema eu devo ir at a classe TClienteDao e implementar o mtodo

AntesDeSalvar para testar se o cliente possui ou no possui razo social. Veja esta alterao

na Listagem 10.

Depois de alterar a classe TClienteDao, o teste deve passar porm, antes de execut-lo

mais uma vez para garantir isto, eu vou declarar os demais mtodos de teste definidos na

Listagem 6. Veja a declarao destes mtodos na Listagem 11. Para poupar espao eu no

vou implementar estes mtodos de teste, vou apenas fazer a declarao e forar a falha deles

com uma mensagem indicando que eles ainda no foram implementados. Agora ao executar

os testes novamente, o resultado ser o que aparece na Figura 5.

possvel notar nesta figura que a alterao feita na classe TClienteDao teve um efeito

positivo, pois o teste TestCampoRazaoSocialEhObrigatorio parou de falhar. Por outro lado

os demais testes esto falhando propositalmente porque ainda no foram implementados.

Implementar estes mtodos um bom exerccio para colocar em prtica o que este artigo

ensina: baixe o arquivo deste artigo e implemente os mtodos de testes que esto falhando.

Cobertura de cdigo Cobertura de cdigo uma tcnica usada para verificar se os testes que voc criou

deixaram alguma coisa sem testar para trs, ou seja, uma tcnica para descobrir quantas

linhas de cdigos no foram cobertas pelos testes escritos. Discover um programa open-


18/20



source usado para medir quantas linhas de cdigo faltam ser cobertas. Ele no precisa ser

instalado, basta execut-lo para poder usar.

Para usar o Discover voc precisa do arquivo de detalhamento do projeto cujo percentual de

cobertura ser calculado. Este arquivo criado quando a opo Map file do Delphi est

habilitada. Para configurar o Delphi para criar o arquivo de detalhamento voc deve abrir o

projeto no Delphi e dentro de Project + Options voc deve escolher Detailed para o item

Map file da sesso Linking - Veja na Figura 6.

Listagem 10. Alterando TClienteDao para fazer o teste passar

1 procedure TClienteDao.An tesDeSalvar(Ob j: TEntidade)

2 begin

3 if Trim((Obj as TCliente).Raz aoSocial) = then

4 raise Exception.Crea te(o nome do cliente obrigatrio.)

5 end

Listagem 11. Os demais mtodos de teste

1 procedure

TestTClienteDao.TestNaoPodeExistirDoisClienteComOMesmoCpfNaMesmaEmpresa

2 begin

3 Fail(Precisa implementar este mtodo)

4 end

5 procedure TestTClienteDa o.TestNaoPodeE xistirUmClient eSemEmpresa

6 begin


8 end

9 procedure TestTClienteDa o.TestCampoEnd erecoEhObrigat orio

10 begin


12 end


Figura 5. Executando os testes novamente



19/20



Figura 6. Configurando o Delphi para gerar o arquivo .map

Esta configurao deve ser feita no projeto de testes e no no projeto verdadeiro. Depois de

configurar o Map File, ser necessrio executar o projeto uma vez para que o arquivo.map

seja criado. Aps execut-lo, o Delphi no ser mais necessrio e se preferir poder fech-lo.

Agora o trabalho restante feito no Discover. Para descobrir o percentual de cdigo ainda

no coberto pelos testes, execute o Discover, clique no menu Project + Load e selecione o

arquivo .dpr do projeto de testes (aquele que foi configurado o arquivo .map). Depois de

carregar o projeto para o Discover, j possvel executar a aplicao escolhendo o menu

Application + Run do Discover. Quando o projeto de testes for iniciar basta excuta-lo

normalmente como foi feito no tpico Criando mtodos de teste. Depois de executar os

testes o Discover mostrar o percentual de cdigo coberto. A seguir voc vai aprender a ler

as informaes que o Discover gerou. Dentro da guia Routines (Figura 7) do Discover, estar

o nome de todas as rotinas do programa e o percentual de cobertura de cada uma - o

percentual de cobertura aparece somente depois que voc executar a aplicao, como

expliquei nos dois ltimos pargrafos.

Ao clicar no nome de uma das rotinas ser exibido do lado direito o cdigo fonte, com um

X ao lado da linha que no foi executado ainda.

A guia Overview (Figura 8) apresenta outro ponto de vista do cdigo. Esta guia mostra a

aplicao de um ponto de vista global.



20/20


Figura 7. A guia Routines do Discover

Todas as rotinas so representadas por um pequeno quadrado que aparece no painel

esquerdo.

Cada quadrado ter uma cor indicando o percentual de cobertura: o valor percentual que

cada cor representa aparece na parte inferir do painel esquerdo. Clicando em um dos

guardados, aparece no painel direito a parte do cdigo fonte que ele representa.


Figura 8. A guia Overview do Discover

Concluso Testar parte do desenvolvimento de software to importante quanto codificar. As

tcnicas apresentadas neste artigo so apenas algumas das existentes. Para aqueles que

pretendem se aprofundar na parte terica do assunto eu recomendo a leitura de um bom livro

para ter conhecimento de todas as demais tcnicas e fases existentes.

devmedia - versão para impressão.pdf

Documents