devmedia - versão para impressão.pdf
TRANSCRIPT
-
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 -
7/24/2019 DevMedia - Verso para impresso.pdf
2/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 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.
-
7/24/2019 DevMedia - Verso para impresso.pdf
3/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 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.
-
7/24/2019 DevMedia - Verso para impresso.pdf
4/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
5/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
6/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 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)
34 FPedidoDao.Post(Pedido)
35 CheckEquals(1 , FPedidoDao.Cou nt, Adicionou duas vezes o mesmo pedido)
36 Pedido := TPedido.Create
37 Pedido.Id := 2
38 FPedidoDao.Post(Pedido)
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/24/2019 DevMedia - Verso para impresso.pdf
7/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
8/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 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.
-
7/24/2019 DevMedia - Verso para impresso.pdf
9/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 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.
-
7/24/2019 DevMedia - Verso para impresso.pdf
10/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
11/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 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.
[abrir imagem em janela]
-
7/24/2019 DevMedia - Verso para impresso.pdf
12/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
13/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 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.
[abrir imagem em janela]
-
7/24/2019 DevMedia - Verso para impresso.pdf
14/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 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.
-
7/24/2019 DevMedia - Verso para impresso.pdf
15/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
16/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 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
-
7/24/2019 DevMedia - Verso para impresso.pdf
17/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 17/20
24 Result.Endere co := Endereco
25 Result.Empres a := Empresa
26 end
[abrir imagem em janela]
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-
-
7/24/2019 DevMedia - Verso para impresso.pdf
18/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 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
7 Fail(Precisa implementar este mtodo)
8 end
9 procedure TestTClienteDa o.TestCampoEnd erecoEhObrigat orio
10 begin
11 Fail(Precisa implementar este mtodo)
12 end
[abrir imagem em janela]
Figura 5. Executando os testes novamente
[abrir imagem em janela]
-
7/24/2019 DevMedia - Verso para impresso.pdf
19/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 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.
[abrir imagem em janela]
-
7/24/2019 DevMedia - Verso para impresso.pdf
20/20
10/11/2015 DevMedia - Verso para impresso
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.
[abrir imagem em janela]
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.