Upload
tatiana
View
12
Download
1
Embed Size (px)
DESCRIPTION
Garantia da Qualidade da Programação de SoftwareUtilizando a Metodologia deDesenvolvimento Dirigido por TestesTDD – Test Driven Development
Citation preview
UNIVERSIDADE CATLICA DE SANTOS
FACULDADE DE ENGENHARIA - FENGE
CINCIA DA COMPUTAO
TRABALHO DE CONCLUSO DE CURSO II
Garantia da Qualidade da Programao de Software
Utilizando a Metodologia de
Desenvolvimento Dirigido por Testes
TDD Test Driven Development
Prof. Orientador: Joo Batista Carneiro Aluna: Tatiana Costa Rodrigues Novembro / 2003
Garantia da Qualidade da Programao de Software
Utilizando a Metodologia de
Desenvolvimento Dirigido por Testes
TDD Test Driven Development
___________________________________ Aluna: Tatiana Costa Rodrigues
____________________________________ Prof. Orientador: Joo Batista Carneiro
Resumo Qualidade de Software um requisito que preocupa a maioria das empresas de
desenvolvimento de software. Todavia, muitas empresas no se preocupam em
aplicar esforos para garantir que os produtos do software sejam gerados com
qualidade. Geralmente essas empresas no utilizam processos de desenvolvimento
de software ou usam processos ineficazes, que comprometem o cronograma do
projeto e conseqentemente a qualidade do software.
As Metodologias geis foram criadas para enfrentar a burocracia das metodologias
tradicionais e assim conquistar desenvolvedores de software que rejeitam as
metodologias tradicionais.
A Extreme Programming (XP) uma metodologia gil de desenvolvimento de
software, que possui prticas simples e se preocupa em entregar ao cliente software
com qualidade.
O Desenvolvimento Dirigido por Testes (TDD) uma metodologia direcionada
atravs da prtica de testes da XP, e consiste em criar cdigos de teste para guiar o
desenvolvedor na criao dos cdigos de design, desenvolvendo com simplicidade,
confiana e qualidade.
Palavras-Chave
Software, Qualidade, Processos, SQA, Testes, Metodologias geis, XP, TDD,
Anlise, Design, Simplicidade, Confiana, Produtividade, JAVA, JUnit
Abstract
Software quality is a requirement that worries most of the software development
companies. Still, much companies dont care in apply efforts to certify that the
software products have been produced with quality. Usually, these companies dont
use software development process or do it in a non-effective process that
compromise the projects schedule and consequently the softwares quality.
The Agile Methodologies were created to confront with the bureaucracy of the
traditional methodologies and then to conquer softwares developers that reject the
traditional methodologies.
The Extreme Programming (XP) is a software development agile methodology that
has simple practices and worries in delivering to the customer software with quality.
The Test Driven Development (TDD) is a methodology directed through XP test
practice and consists in produce test-code to guide the developer in the production of
design- code, developing with simplicity, confidence and quality.
Keywords
Software, Quality, Process, SQA, Test, Agile Methodologies, XP, TDD, Analysis,
Design, Simplicity, Confidence, Productivity, JAVA, Junit
Lista de Figuras Fig. 1 Prticas XP [Bec, 2000] _____________________________________________________ 19 Fig. 2 - TestCadastro.Java __________________________________________________________ 40 Fig. 3 Compilando TestCadastro.Java _______________________________________________ 41 Fig. 4 - Cadastro.java ______________________________________________________________ 41 Fig. 5 Compilando Cadastro.java ___________________________________________________ 41 Fig. 6 Compilando TestCadastro.java ________________________________________________ 42 Fig. 7 - Cadastro.java ______________________________________________________________ 42 Fig. 8 Compilando todas as classes _________________________________________________ 42 Fig. 9 Comando de execuo do JUnit _______________________________________________ 43 Fig. 10 Execuo do JUnit ________________________________________________________ 43 Fig. 11 - Cadastro.java _____________________________________________________________ 44 Fig. 12 Compilando todas as classes e executando o JUnit ______________________________ 44 Fig. 13 Execuo do JUnit ________________________________________________________ 45 Fig. 14 - TestCadastro.Java _________________________________________________________ 46 Fig. 15 Compilando TestCadastro.java _______________________________________________ 46 Fig. 16 - Cadastro.java _____________________________________________________________ 47 Fig. 17 Compilando todas as classes e executando o JUnit ______________________________ 47 Fig. 18 Execuo do JUnit ________________________________________________________ 48 Fig. 19 - Cadastro.java _____________________________________________________________ 49 Fig. 20 Compilando todas as classes e executando o JUnit ______________________________ 49 Fig. 21 Execuo do JUnit ________________________________________________________ 50 Fig. 22 - TestCadastro.java _________________________________________________________ 51 Fig. 23 Compilando TestCadastro.java _______________________________________________ 52 Fig. 24 - Cadastro.Java ____________________________________________________________ 52 Fig. 25 - Compilando todas as classes e executando o JUnit ______________________________ 53 Fig. 26 Execuo do JUnit ________________________________________________________ 53 Fig . 27 - Cadastro.java ____________________________________________________________ 54 Fig. 28 Compilando todas as classes e executando o JUnit ______________________________ 54 Fig. 29 Execuo do JUnit ________________________________________________________ 55
Sumrio 1. Introduo _____________________________________________1
1.1 Contextualizao _____________________________________________________________ 1 1.2 Problema____________________________________________________________________ 3 1.3 Problematizao ______________________________________________________________ 3 1.4 Objetivos ____________________________________________________________________ 3
1.4.1 Objetivo Geral ____________________________________________________________ 3 1.4.2 Objetivos Especficos _______________________________________________________ 4
1.5 Relevncia ou Justificativa ______________________________________________________ 5
2. Reviso Bibliogrfica ____________________________________5 2.1 Qualidade de Software _________________________________________________________ 5 2.2 Metodologias geis ___________________________________________________________ 6 2.3 Extreme Programming XP _____________________________________________________ 7 2.4 Test Driven Development TDD _________________________________________________ 9
3. Projeto _______________________________________________11 3.1 A Garantia da Qualidade de Software ____________________________________________ 11
3.1.1 Qualidade de Software_____________________________________________________ 11 3.1.2 Garantia da Qualidade de Software - SQA _____________________________________ 12 3.1.3 Testes de Software _______________________________________________________ 13 3.1.4 Padres de Qualidade _____________________________________________________ 14
3.2 Metodologias geis Agile Methodology __________________________________________ 15 3.3 Extreme Programming - XP ____________________________________________________ 17
3.3.1 Valores da XP ___________________________________________________________ 19 3.3.1.1 Simplicidade _________________________________________________________ 20 3.3.1.2 Comunicao ________________________________________________________ 21 3.3.1.3 Feedback ___________________________________________________________ 22 3.3.1.4 Coragem ____________________________________________________________ 23
3.3.2 Prticas da XP ___________________________________________________________ 23 3.3.2.1 The Planning Game____________________________________________________ 23 3.3.2.2 Small Releases _______________________________________________________ 24 3.3.2.3 Metaphor ____________________________________________________________ 25 3.3.2.4 Simple Design ________________________________________________________ 26 3.3.2.5 Testing ______________________________________________________________ 27 3.3.2.6 Refactoring __________________________________________________________ 28 3.3.2.7 Pair Programming _____________________________________________________ 29 3.3.2.8 Collective Ownership ___________________________________________________ 29 3.3.2.9 Continuous Integration _________________________________________________ 30 3.3.2.10 40 Hour Week______________________________________________________ 31 3.3.2.11 On-site Customer ____________________________________________________ 31 3.3.2.12 Coding Standards ____________________________________________________ 32
3.3.3 Os papis na XP _________________________________________________________ 32 3.3.3.1 A equipe do cliente ____________________________________________________ 33 3.3.3.2 A equipe de desenvolvimento ____________________________________________ 33
3.4. Test Driven Development - TDD ________________________________________________ 34 3.4.1 Como funciona o TDD? ____________________________________________________ 35 3.4.2 Benefcios do TDD. _______________________________________________________ 38 3.4.3 A Importncia de Ferramentas Automatizadas de Teste __________________________ 38
3.5 Implementao de Casos de Teste ______________________________________________ 40 3.6 Concluso __________________________________________________________________ 56
BIBLIOGRAFIA ___________________________________________57 SITES VISITADOS ______________________________________________________________ 57
1
1. Introduo
1.1 Contextualizao
A Metodologia de Desenvolvimento TDD uma metodologia na qual
programadores utilizam as facilidades e benefcios de Tcnicas de Teste para
exercer suas atividades e implementar as funcionalidades do sistema.
O objetivo no TDD a produo de Software com qualidade, obedecendo as
regras de negcio e prazos estipulados. Espera-se tambm que o desenvolvimento
do sistema seja realizado de forma simples e rpida, e que as no-conformidades
sejam identificadas facilmente e no menor tempo possvel.
A criao de cdigos de teste para testar cdigo de design antes da criao
dos mesmos o elemento que caracteriza o TDD como uma metodologia que facilita
o desenvolvimento de software. O Programador deve comear (1) criando um teste
simples e pequeno, (2) codificar somente o que foi declarado no cdigo de teste e
(3) continuar com o prximo teste at que o cdigo esteja finalizado e limpo.
Entre os fatores que acarretam os maiores riscos qualidade em um Projeto de
Software, est a ausncia ou ineficincia de testes que validem o funcionamento
correto do sistema e a boa aplicabilidade de suas caractersticas.
A Garantia da Qualidade de Software ("Software Quality Assurance, SQA")
uma atividade importante e necessria em todos os projetos de Desenvolvimento de
Software e deve estar presente em todas as etapas do Processo de
Desenvolvimento (Anlise, Design, Implementao, Testes,...).
Muitas equipes de projeto acreditam que a utilizao de testes um esforo
desnecessrio. Outras pretendem utilizar testes para verificar o correto
funcionamento do sistema, mas devido inexperincia de alguns membros da
equipe ou o trmino do prazo de entrega do projeto, os testes so ignorados,
comprometendo a qualidade do software.
As atividades para garantir a qualidade do software so responsabilidades dos
Programadores ou do Pessoal de Controle de Qualidade? A grande maioria dos
programadores prefere no saber nem como os testes funcionam ou para que eles
foram criados. Pensamentos como esse distanciam a qualidade do software ainda
mais do projeto. O Desenvolvimento Dirigido por Testes faz com que o Programador
2
produza um cdigo de teste para validar e facilitar a criao do cdigo de design, e
aps produza o cdigo de design.
A Metodologia gil de Desenvolvimento de Software Extreme Programming -
XP, possui valores que auxiliam equipe de projeto no desenvolvimento do
software. Comunicao, simplicidade, feedback e coragem so valores que (1)
melhoram a comunicao entre todos os membros da Equipe (clientes, gerentes e
programadores), (2) produzem somente funcionalidades que so necessrias para o
momento apropriado, (3) capturam informaes dos membros da equipe e/ou do
prprio sistema que tm impacto no funcionamento do sistema e (4) do confiana
equipe para realizar mudanas sempre quando necessrias.
Alguns valores da XP esto relacionados prtica de teste, que a grande
chave da XP. Para que sejam criados testes eficientes, os membros da equipe
precisam estar aptos a aproveitar esses valores e concordar com os mesmos.
Alm da prtica de Teste (Testing), a XP possui prticas como The Planning
Game (Planejamento do Jogo), Simple Design (Simplicidade), Refactoring
(Reestruturar o Sistema), Pair Programming (Programao em Pares), Collective
Ownership (Propriedade coletiva de cdigo), entre outras.
O Desenvolvimento Dirigido por Testes (ou Test Driven Development - TDD)
uma Metodologia de Desenvolvimento, utilizada na mais importante prtica da XP, a
prtica de teste, que tem como caractersticas (1) a utilizao exaustiva de conjuntos
de testes unitrios, (2) a no permisso da produo de cdigo de design antes que
exista um cdigo de teste para valid-lo (3) e a percepo de qual cdigo dever ser
escrito baseando-se no cdigo de teste, o que limita o cdigo de design e
conseqentemente diminui o risco de implementao de caractersticas
desconhecidas.
O TDD no uma tcnica de teste. A criao de cdigo de teste anteriormente
criao de cdigo de design, se d na fase de Codificao e pode ser
caracterizada mais apropriadamente como uma tcnica de anlise ou design, isso
porque a criao do cdigo de teste possibilita ao programador (1) decidir o que ele
ir programar no cdigo de design e o que no ir, (2) e tambm definir que
caractersticas de design vo possuir as funcionalidades que sero implementadas.
3
1.2 Problema
Baixa qualidade dos Softwares em decorrncia da no utilizao de tcnicas
que validem e facilitam o processo de programao.
1.3 Problematizao
Atualmente cerca de 60% dos projetos de desenvolvimento de software so
executados sem um processo estabelecido de desenvolvimento de software.
[Ast, 2002]
A no utilizao de uma Metodologia de Desenvolvimento de Software se d
pelo alto ndice de documentao requerida pelas metodologias tradicionais,
que muitas vezes no so utilizadas e/ou so ineficazes e dificultam o
cumprimento do cronograma do projeto.
1.4 Objetivos
1.4.1 Objetivo Geral
Apresentar a metodologia de Desenvolvimento de Software Dirigido por Testes
(TDD), e como essa metodologia possibilita garantir a qualidade do software
utilizando suas tcnicas e frameworks de teste, notadamente aplicada fase de
codificao das especificaes.
4
1.4.2 Objetivos Especficos
Definir e/ou Relatar:
O que , quais as atividades que devem ser exercidas e produtos que
envolvem a Garantia da Qualidade de Software, SQA.
A importncia dos testes para a garantia da qualidade de software.
O que so Metodologias geis (Agile Methodology), quais as suas
caractersticas e benefcios para a garantia da qualidade.
A Garantia da Qualidade de Software atravs da Metodologia de
Desenvolvimento de Software Extreme Programming - XP.
O que XP, seus participantes, princpios, tcnicas/prticas e benefcios.
O que , quais so as atividades, quem so os participantes, quais os
benefcios e o resultado da utilizao da metodologia de Desenvolvimento
Dirigido por Testes - TDD.
Em qual atividade do processo de desenvolvimento de software so aplicadas
as tcnicas de teste do TDD, para garantir a qualidade do software.
O framework JUnit e as suas facilidades para a garantia da qualidade
utilizando o TDD.
A aplicao de testes atravs do JUnit, analisando o resultado dos testes,
comparando os resultados obtidos com o resultado esperado.
5
1.5 Relevncia ou Justificativa
O estudo da Garantia da Qualidade de Software significativo para todas as
pessoas que esto envolvidas diretamente ou indiretamente no desenvolvimento de
software.
O crescimento da utilizao da Metodologia de Desenvolvimento de Software
XP envolve a Garantia da Qualidade, uma vez que a prtica de maior importncia na
XP a prtica de Testes.
Algumas tcnicas da XP (Simple Design, Refactoring e Pair Programming)
influenciam a garantia da qualidade, sendo que para um projeto que utiliza a XP
todas as tcnicas da XP devem estar relacionadas para se aproveitar todos os
benefcios que a metodologia oferece.
O Desenvolvimento Dirigido por Testes TDD est diretamente relacionado
com a SQA e a XP. Essa metodologia de desenvolvimento procura elaborar
produtos com qualidade e cumprindo o prazo ajustado com o cliente.
O estudo da garantia da qualidade do software utilizando o TDD relevante,
uma vez que muitos projetos de desenvolvimento de software no adotam uma
metodologia de desenvolvimento. As caractersticas da XP que a tornam uma
metodologia lightweight encorajam as pessoas relacionadas ao desenvolvimento
de software a utiliz-la. Os valores da XP tambm contribuem para que ela seja
utilizada cada vez mais, aumentando as chances de produo de software com
qualidade.
A utilizao do Framework JUnit possibilita que a qualidade seja garantida
utilizando uma ferramenta de alta credibilidade e fcil utilizao.
2. Reviso Bibliogrfica
2.1 Qualidade de Software
A Qualidade do Software um fator essencial e comprometedor em todos os
Projetos de Desenvolvimento de Software. Para garantir um software com qualidade,
6
devem ser avaliados tanto os produtos do software como o processo que est sendo
utilizado para desenvolv-lo.
Qualidade de Software em [Pres, 2001] definida como a conformidade com
requisitos funcionais e de desempenho explicitamente declarados, padres de
desenvolvimento explicitamente documentados e caractersticas implcitas, que so
esperadas em todo software desenvolvido profissionalmente.
A busca pela qualidade visa diminuir a quantidade de defeitos e se preocupa
ainda mais em certificar que a quantidade de erros foi minimizada de uma verso
para outra.
O Controle de Qualidade envolve um conjunto de atividades necessrias para
que sejam feitas revises e avaliaes ao longo do processo de desenvolvimento e
as no-conformidades sejam capturadas to cedo quanto possvel.
O Teste de Software o elemento que representa uma avaliao da
especificao, projeto e gerao de cdigo do software. Os testes tm um papel
importante, e so aplicados para que os erros sejam encontrados antes que sejam
passados para a prxima atividade de Engenharia de Software ou para o cliente.
importante que o objetivo de cada teste satisfaa os requisitos especificados,
que eles sejam planejados anteriormente a gerao de cdigo, que sejam testadas
as funcionalidades do software como tambm a correta interao entre os diversos
componentes.
Alguns padres de qualidade so utilizados pela comunidade de Engenharia de
Software para avaliar os processos de desenvolvimento utilizados pelas empresas
de desenvolvimento de software. Entre as normas e padres mais conhecidos esto:
ISO 9001, ISO 12207, ISO 15504 (SPICE) e os diferentes tipos do CMM.
2.2 Metodologias geis
O desenvolvimento de software utilizando as metodologias tradicionais
possibilita o desenvolvimento atravs de um processo detalhado com nfase no
planejamento.
Um novo grupo de metodologias de desenvolvimento de software tm
aparecido nos ltimos anos, como uma mudana de paradigma de mtodos de
7
desenvolvimento de software. Essas metodologias trazem uma nova forma de
construir software com mudana de diversos conceitos.
Algumas pessoas costumam dizer que o grande problema que compromete os
Projetos de Software que os requisitos mudam constantemente. Porm, a
mudana a norma para garantir um produto com qualidade e que satisfaa as
necessidades do cliente. Uma importante caracterstica das metodologias geis
que elas possuem princpios que encorajam a equipe de projeto a aceitar as
mudanas.
Diversas caractersticas das metodologias geis possibilitam que um software
seja produzido com alta qualidade. O foco na codificao, a valorizao da equipe
de projeto, a aceitao pelas mudanas e a forte colaborao do cliente no projeto
so fatores que aumentam as chances de produo de software com qualidade.
Entre os objetivos das metodologias geis esto: (1) satisfazer o cliente
atravs de entrega rpida e contnua de software com valor, (2) prover ao cliente
vantagem competitiva atravs das mudanas necessrias que so sempre aceitas e
aplicadas, (3) manter um ambiente e relao pacfica e produtiva entre cliente,
desenvolvedores e usurios e (4) desenvolver com simplicidade.
Em [Cun, 2001], o Manifesto gil:
Indivduos e interaes acima de processos e ferramentas;
Software em funcionamento acima de documentao abrangente;
Colaborao do cliente acima de negociao contratual;
Resposta mudana acima do seguimento de um plano.
2.3 Extreme Programming XP
Extreme Programming (XP) uma metodologia gil de desenvolvimento de
software, criada por Kent Beck em meados de 1995, conhecida como uma
metodologia leve, eficiente, de baixo risco, flexvel, que possui poucas regras e
prticas que so fceis de seguir.
8
As premissas da XP so (1) diminuir os riscos do projeto, (2) aumentar a
responsabilidade nas mudanas de negcio, (3) aumentar a produtividade e (4)
adicionar divertimento equipe na construo do software. [Bec, 2000]
Comunicao, simplicidade, feedback e coragem so os quatro valores da XP,
definidos por Kent Beck, que a caracterizam como uma metodologia promissora e de
fcil utilizao. Em projetos XP, deve existir uma constante e pacfica comunicao
entre todos os membros da equipe, o que facilita a descoberta de novos requisitos e
as atividades de programao. Simplicidade visando sempre desenvolver um
produto somente quando necessrio, no adivinhando funcionalidades futuras e
codificando de forma simples. Feedback do cliente e do sistema tambm so
fundamentais para a descoberta de novas funcionalidades, para saber se o que foi
elaborado o que realmente o cliente espera e se o sistema est operando
corretamente. Coragem um princpio que caracteriza a XP como uma metodologia
onde a equipe aceita as freqentes mudanas, como tambm trabalhar com novas
prticas que desafiam as metodologias de desenvolvimento de software tradicionais.
Alm dos valores, a XP possui Prticas, que suportam uma as outras,
relacionadas s etapas de Planejamento, Design, Codificao e Testes.
Planning Game: so determinados escopo, prioridades de negcio,
estimativas tcnicas e datas de entrega; desenvolvedores trabalham junto
com o cliente para decidir quais funcionalidades sero implementadas.
Small Releases: colocar o projeto em produo to cedo quanto possvel;
possibilita rpido feedback do cliente, diminuindo os riscos e certificando que
o produto que o cliente realmente necessita.
Metaphor: possibilitar que cliente e desenvolvedores tenham uma mesma
viso do sistema; uma definio da arquitetura conceitual geral do sistema.
[Ast, 2002]
Simple Design: o processo de codificao deve ser o mais simples possvel,
possibilitando a todos os desenvolvedores trabalhar em um mesmo cdigo;
Testing: a prtica mais importante da XP, sempre em busca de qualidade; a
criao e aplicao de testes devem ser freqentes, desde a concepo de
um produto; os testes provm rpido feedback e d coragem a equipe para
realizar as mudanas sempre que necessrio;
9
Refactoring: os programadores reestruturam o sistema, simplificando o
cdigo, se preocupando em no alterar as suas funcionalidades.
Pair Programming: programao em pares, em uma nica mquina, com um
nico teclado; os programadores se ajudam, trocam conhecimento e
encontram erros mais depressa.
Collective Ownership: qualquer desenvolvedor pode mudar qualquer cdigo;
no existem proprietrios para os cdigos.
Continuous Integration: integrao freqente, verificando se todos os produtos
esto interagindo normalmente e se as mudanas realizadas comprometem o
correto funcionamento do sistema;
40 - Hour Week: respeitar o limite de horas semanais de trabalho,
aproveitando ao mximo o tempo permitido;
On-site Customer: a presena do cliente junto equipe de projeto a todo o
momento, podendo solucionar dvidas e ajudar a equipe sempre que
possvel;
Coding Standards: respeitar o estilo de codificao padro estabelecido pela
equipe de projeto, para que todos os desenvolvedores possam trabalhar em
todos os cdigos.
2.4 Test Driven Development TDD
Desenvolvimento Dirigido por Testes
TDD uma metodologia de desenvolvimento utilizada em projetos de software
atravs da mais importante prtica da XP, a prtica de Testes. Porm, o TDD no
uma tcnica utilizada nas atividades de teste do processo de engenharia de
software. A utilizao dessa metodologia ocorre especialmente na fase de
codificao e caracterizada como uma tcnica de anlise e design.
O grande propsito do TDD produzir testes automatizados para produzir
cdigo, e atravs desse processo guiar o design e a programao. [Adaption]
10
Os testes fornecem uma definio ou documentao do comportamento
desejado. Torna-se parte da soluo. [Adaption] Os casos de teste elaborados
demonstram qual o comportamento correto de uma parte do sistema.
O TDD facilita o desenvolvimento de software, tornando-o mais divertido e
rpido, com cdigo mais simples e com melhor qualidade. Cdigo fcil de se
projetar, escrever, ler, entender, estender e manter. [Ast, 2003]
A elaborao de cdigo de teste e cdigo de produo alternada no TDD.
Assim os programadores no se cansam de escrever cdigos de teste, at mesmo
porque eles facilitam a elaborao do cdigo de produo e tornam esse processo
mais divertido. So os programadores que escrevem os seus prprios casos de
teste, e no uma equipe responsvel pelos testes. Esse estilo de desenvolvimento
faz com que os programadores se sintam mais confiantes em relao aos seus
cdigos, evitando que os erros sejam capturados mais adiante por outras pessoas.
Em Object Mentor [Obj, 2003], os passos para se desenvolver atravs do TDD
so:
Escrever um cdigo de teste que especifica um pequeno pedao de
funcionalidade;
Certificar se o teste falhou (a funcionalidade ainda no foi implementada);
Escrever somente o cdigo necessrio para o teste passar;
Fazer o refactoring no cdigo, certificando que o mesmo possui o mais
simples design possvel, no alterando o seu comportamento.
Entre as regras que devem ser seguidas esto:
Testar tudo que possivelmente possa falhar;
Elaborar primeiro os cdigos de teste;
Todos os testes devem passar 100% a todo o momento.
No TDD, assim como na XP, as mudanas so sempre bem vindas.
importante que qualquer nova funcionalidade seja implementada. No TDD o cdigo
testado antes e depois de qualquer modificao. Quando existir algum erro,
possvel voltar ao que foi produzido anteriormente.
Entre os benefcios do TDD, destacam-se (1) as prevenes de defeitos devido
utilizao exaustiva de testes, (2) o pouco tempo gasto procurando pelos defeitos
no cdigo de design, (3) a elaborao de um cdigo simples, claro e coeso, (4) a
elaborao de testes para cada funcionalidade isoladamente, (5) a criao de testes
11
automatizados e (6) o aumento da coragem do desenvolvedor para modificar o
cdigo se necessrio e da confiana de que o cdigo funciona corretamente.
Diversas ferramentas oferecem suporte a metodologia TDD, facilitando o
acompanhamento dos testes, o progresso das execues e quais testes falharam,
atravs de interfaces com o usurio. O JUnit um framework de teste para a
linguagem de programao JAVA e est diretamente ligado com o TDD. Atravs da
interface do JUnit possvel ter um bom entendimento sobre o que estava sendo
esperado e qual foi o resultado obtido.
3. Projeto
3.1 A Garantia da Qualidade de Software
3.1.1 Qualidade de Software
Com o avano da descoberta de novas tecnologias, a crescente utilizao de
sistemas distribudos e o grande nmero de usurios acessando informaes de um
domnio especfico, a busca pela qualidade dos servios providos por um sistema
tm preocupado cada vez mais os desenvolvedores de software.
Entre os fatores que acarretam os maiores riscos qualidade em um Projeto de
Software, est a ausncia ou ineficincia de prticas de qualidade e testes que
validem o funcionamento correto do sistema e a boa aplicabilidade de suas
caractersticas.
Outro fator que implica na baixa qualidade do software a no utilizao de
Metodologias de Desenvolvimento de Software, que tornam o desenvolvimento mais
eficiente e previsvel. Porm, devido ao alto ndice de documentao requerida pelas
metodologias tradicionais, que algumas vezes no so utilizadas, so ineficazes e
12
dificultam o cumprimento do cronograma do projeto, elas so rejeitadas pelas
equipes de desenvolvimento.
A qualidade dos produtos do software depende da qualidade do processo
utilizado pela equipe para desenvolv-los. Portanto o processo tambm deve ser
avaliado freqentemente, e as atividades e regras devem ser bem definidas e
respeitadas por toda equipe.
O controle de qualidade deve estar presente em todas as fases do processo de
desenvolvimento de software, garantindo que um produto satisfaz os requisitos
explcitos e implcitos estabelecidos e obedece aos padres especificados.
A preocupao com a qualidade em todas as etapas do processo de
desenvolvimento de software reduz o re-trabalho, os riscos do projeto, o custo e o
prazo de entrega do produto para o cliente.
Muitas equipes de projeto acreditam que, a utilizao de prticas de garantia da
qualidade e testes, so um esforo desnecessrio. Outras pretendem utiliz-las para
verificar o correto funcionamento do sistema, mas devido inexperincia de alguns
membros da equipe ou o trmino do prazo de entrega do projeto, esta etapa
ignorada, comprometendo a qualidade do software.
3.1.2 Garantia da Qualidade de Software - SQA
A Garantia da Qualidade de Software ("Software Quality Assurance, SQA")
uma atividade importante e necessria em todos os projetos de Desenvolvimento de
Software. A SQA deve estar presente em todas as etapas do Processo de
Desenvolvimento de Software (Levantamento de requisitos, Anlise, Design,
Implementao, Testes,...) e tem como principal objetivo garantir a alta qualidade do
software atravs de atividades que possibilitam avaliar os produtos do software e
relatar as ocorrncias de no-conformidades aos responsveis pelo Projeto.
As principais atividades da SQA so:
a preparao do plano de garantia da qualidade para o projeto;
avaliao da descrio do processo de software do projeto;
reviso das atividades de Engenheira de Software do processo;
13
avaliao dos produtos do software elaborados;
documentao e correo das no-conformidades;
registrar e relatar aos superiores todas as no-conformidades;
aplicao de revises tcnicas formais;
3.1.3 Testes de Software
Teste de Software o elemento que representa uma avaliao do projeto e
gerao de cdigo do software. As atividades de Garantia da Qualidade do Software
so importantes para a descoberta de erros, porm so insuficientes para o alcance
do correto funcionamento do software. Os testes tm um papel importante, e so
aplicados para que os erros sejam encontrados antes que sejam passados para a
prxima atividade de Engenharia de Software ou para o cliente.
Os testes garantem que o software est funcionando corretamente, atendendo
o que foi estabelecido na especificao, assim como os requisitos de
comportamento e desempenho.
importante que (1) o objetivo de cada teste satisfaa os requisitos
especificados, (2) que eles sejam planejados anteriormente a gerao de cdigo, (3)
que sejam testadas as funcionalidades do software como tambm a correta
interao entre os diversos componentes e (4) que os testes sejam aplicados por
profissionais capacitados.
Como produto da atividade de testes, na criao dos testes do software so
criados diversos casos de teste que tm grande probabilidade de encontrar erros
com o mnimo esforo e tempo. Na execuo dos testes, o responsvel pela
qualidade simula a execuo de um programa para encontrar os erros existentes.
Os produtos podem ser testados atravs de duas categorias de casos de teste:
(1) os testes de caixa- preta, que so utilizados para verificar se as funes do
software esto operando corretamente como foi especificado e (2) os teste de caixa-
branca que verificam se a interao entre os componentes externos est adequada.
Entre os tipos de teste existentes, destacam-se os (1) testes de unidade, que
verificam a qualidade de cada entidade (e.g., classe, Servlets, EJB em linguagem
14
JAVA) individualmente, garantindo que a mesma funciona corretamente, (2) teste de
integrao que verifica a qualidade de um pacote de software completo, onde esto
integrados diversos componentes, (3) testes de validao que garantem que o
software satisfaz todos os requisitos funcionais e no-funcionais e (4) os testes de
sistema que verificam se todos os elementos (hardware, software, pessoal,...) se
adequam e trabalham corretamente.
3.1.4 Padres de Qualidade
As empresas desenvolvedoras de software tm se preocupado com padres
de avaliao dos processos de desenvolvimento de software, visando a qualidade
geral dos produtos desenvolvidos, atravs da melhoria dos processos utilizados.
Entre os principais padres e/ou modelos de qualidade de software esto:
ISO 9001: indica o controle da no-conformidade de um produto e
recomenda aes corretivas e preventivas. [Tsu, 1997]
ISO 12207: norma que caracteriza todas as atividades que devero ser
utilizadas pela equipe durante todo o ciclo de vida do software.
ISO 15504 (SPICE): modelo que avalia os processos baseando-se nas
caractersticas de modelos com objetivos semelhantes;
CMM (Capability Maturity Model): modelo utilizado para avaliar a
maturidade dos processos utilizados por organizaes que desenvolvem
software e orientar a equipe para a melhoria desses processos.
PCMM (People Capability Maturity Model): modelo utilizado para avaliar a
maturidade da empresa e a sua relao com as pessoas diretamente
ligadas ao desenvolvimento de software.
SA CMM: (Software Acquisiton Capability Maturity Model): modelo que
avalia a maturidade dos processos de aquisio e gerenciamento de
software terceirizado.
15
CMMi (Integration Capability Maturity Model): integrao dos diversos
modelos CMM, com o objetivo de verificar tanto a maturidade dos
processos como a maturidade da organizao.
3.2 Metodologias geis Agile Methodology
Os Desenvolvedores de software utilizam as Metodologias de Desenvolvimento
de Software h muitos anos. A utilizao dessas metodologias facilita o
desenvolvimento de Software e orienta a equipe sobre os papis e atividades que
devem ser exercidas.
O desenvolvimento atravs das metodologias tradicionais possibilita o
desenvolvimento de software atravs de um processo detalhado com nfase no
planejamento. Nesses processos pesados e longos so gastos muito tempo
planejando grande parte do processo. Quando houver mudanas, os processos
pesados procuram resistir a essas mudanas. Quanto mais o sistema cresce, mais
difcil torna-se incluir novas funcionalidades e mudanas no sistema.
Algumas pessoas costumam dizer que o grande problema que compromete os
Projetos de Software que os requisitos mudam constantemente. Porm, a
mudana a norma para garantir um produto com qualidade e que satisfaa as
necessidades do cliente. Os desenvolvedores de software precisam aceitar as
mudanas como um aspecto positivo de renovao do sistema. Nas metodologias
tradicionais as mudanas nem sempre so bem vindas e/ou aplicadas, e os fatores
que implicam essa apreenso o grande nmero de documentos que precisam ser
formulados e consultados, e a falta de prticas que garantam a qualidade do
software. As metodologias tradicionais muitas vezes no se preocupam com os
aspectos que facilitam o desenvolvimento de software e realmente trazem valor para
o cliente.
Um novo grupo de metodologias de desenvolvimento de software tm
aparecido nos ltimos anos, como uma mudana de paradigma de mtodos de
desenvolvimento de software. Essas metodologias trazem uma nova forma de
construir software com mudana de diversos conceitos.
16
Essas metodologias so conhecidas como Metodologias geis e apareceram
para enfrentar a burocracia das metodologias tradicionais, que muitas vezes se
tornava intil, isso porque as metodologias geis so pouco orientadas a
documentao, e sim a codificao e a equipe do projeto. Para as metodologias
geis, a comunicao fundamental, contrariando a quantidade exagerada de
documentao que muitas vezes produzida nas metodologias tradicionais.
As metodologias geis so identificadas como um meio termo entre nenhum
processo e processos pesados de desenvolvimento de software.
A adaptao um desafio e uma caracterstica forte nas metodologias geis
que muitas vezes so conhecidas como Processos Adaptativos ou Lightweight
Methodologies.
Os requisitos mudam bastante e preciso adaptar essas mudanas ao projeto
para que o cliente receba o produto como foi requisitado, obedecendo ao prazo de
entrega e custo determinados. A caracterstica de adaptabilidade prov aos
desenvolvedores liberdade para realizar mudanas sempre que necessrio.
Por serem processos geis, adaptativos, o cliente acompanha todas as
iteraes de perto, verificando se as mudanas requisitadas por ele foram aplicadas
e verificando o progresso do projeto.
No desenvolvimento iterativo, so produzidas diversas verses, sendo que
cada verso possui um conjunto de funcionalidades que so integradas e testadas
como uma verso final. A cada verso entregue, o cliente descobre mais rpido
novas mudanas para o sistema, tornando-se mais fcil implement-las.
Uma caracterstica das metodologias tradicionais, que elas se preocupam em
congelar os requisitos. Os requisitos devem ser totalmente identificados
anteriormente codificao do sistema. Algumas equipes de projeto no aceitam
modificaes nos requisitos, e o planejamento seguido rigorosamente. Porm essa
postura dificulta a construo de um sistema com todas as caractersticas que foram
requisitadas pelo cliente.
O custo de um projeto um fator que tambm possui muitas diferenas em
metodologias geis. Em projetos que utilizam as metodologias tradicionais, os
clientes costumam pagar um preo fixo pelo sistema, pois os requisitos so estveis.
Em projetos que utilizam as Metodologias geis, os requisitos podem mudar
bastante, e portanto o cliente no pode pagar um preo fixo. Para isso o cliente deve
ter um controle do processo de desenvolvimento em cada iterao. O cliente
17
conhece mais rpido como o sistema funciona na realidade, com isso as mudanas
so descobertas mais rpido e portanto o preo estipulado pode mudar no decorrer
do projeto.
Em algumas metodologias tradicionais, a qualidade do projeto medida pela
conformidade com o planejamento, o que dificulta a equipe a perceber quando foi
produzido um produto de baixa qualidade, resultando em desvios no cronograma do
projeto, devido procura pelo causador do erro. Nas metodologias geis a cada
iterao o planejamento refeito. As no-conformidades so descobertas tempo e
a incluso de novas funcionalidades pode ser realizada facilmente. Por isso as
iteraes devem ser pequenas, verificando as variaes e oportunidades para
elaborar o produto adequado.
A equipe de projeto em metodologias geis no difere muito das equipes que
utilizam as metodologias tradicionais para desenvolver software. Os requisitos do
projeto mudam constantemente e toda a equipe precisa saber a existncia de novas
mudanas. Para isso necessita-se de pessoas confiveis, que aceitam mudanas e
com conhecimento suficiente para liderar e trabalhar com as Metodologias geis.
O importante para as metodologias geis prover ao cliente valor de negcio.
Para o cliente, valor de negcio se resume a um software com a qualidade maior
que a esperada e um custo menor que o estipulado.
Escopo bem definido, contrato e distanciamento entre fornecedor e cliente, no
atendem a um mercado em constante mudana.
Metodologias geis provem um conjunto simples de regras, encorajando a
criatividade e produzindo melhores resultados que impondo regras complexas e
rgidas.
O interesse em utilizar metodologias geis no querer voltar ao passado,
onde no existiam regras para desenvolver software e sim utilizar somente regras e
prticas concisas e efetivas que garantam a qualidade do software.
3.3 Extreme Programming - XP
Em 1990 Kent Beck, criador da XP, procurava por um novo modo de
desenvolver software, que facilitasse o desenvolvimento, tornando-o mais simples e
18
eficiente. Em maro de 1996 Beck trabalhou no projeto Chrysler Comprehensive
Compensation, C3, da DaimlerChrysler, onde comeou a utilizar novos conceitos de
desenvolvimento de software, que originaram a XP.
uma metodologia gil de desenvolvimento de software que trabalha criando
uma constante comunicao entre programadores e clientes, assumindo que os
requisitos vo mudar muitas vezes, priorizando funcionalidades de acordo com o
valor de negcio, de forma simples, entregando valores freqentemente e testando o
sistema exaustivamente durante todo o desenvolvimento.
XP uma metodologia leve, eficiente, de baixo risco, flexvel e divertida que
possui poucas regras e prticas que so fceis de seguir.
As metodologias tradicionais de desenvolvimento de software, tambm
conhecidas como processos pesados de desenvolvimento, possuem regras
complexas, difceis de serem seguidas, procedimentos complicados e uma grande
quantidade de documentao a ser elaborada e consultada. Quando os
programadores ignoram as suas regras, provavelmente no as aceitam mais. A
utilizao de metodologias geis de desenvolvimento de software encoraja os
programadores a seguir uma metodologia obedecendo todas as suas regras.
A XP no voltou ao passado quando no haviam regras para se desenvolver
software e tambm no ignorou as regras e prticas das metodologias tradicionais,
simplesmente as simplificou, tornando-as mais fceis de se utilizar e entender,
visando produzir software com qualidade.
As mudanas no projeto so freqentes. As especificaes so alteradas
freqentemente em todas as etapas do processo de desenvolvimento. Nas
metodologias tradicionais os programadores tm dificuldade em aceitar as
mudanas com o receio de que os produtos prontos deixem de funcionar devido as
mudanas que foram aplicadas, ou o produto final no seja igual ao que foi
requisitado pelo cliente. Essas inconformidades acontecem devido a no utilizao
dos testes e prticas de qualidade e/ou da entrega tardia de produtos do software.
Na XP o cliente deve perceber a coragem dos programadores para realizar
modificaes no software sempre que necessrias. Para isso os programadores se
preocupam em obter feedback do cliente e do sistema o mais cedo possvel.
preciso que os produtos do software sejam entregues com freqncia e no de uma
s vez. Quanto mais cedo o feedback for obtido mais fcil ser implementar novas
funcionalidades ou modificaes no sistema.
19
Entre as principais caractersticas da XP que a caracterizam como uma
metodologia gil e de sucesso esto (1) a constante e pacfica comunicao entre
programadores e clientes, (2) a elaborao de um design simples, (3) a procura por
feedback do cliente e do sistema, testando a partir do primeiro dia, (4) a entrega ao
cliente um produto to cedo quanto possvel e (5) a aceitao as mudanas.
Na Fig1. percebe-se que qualquer prtica da XP no tem valor sozinha (com
uma possvel exceo dos Testes). Todas as prticas necessitam uma das outras
para estarem balanceadas. [Bec, 2000]
Fig. 1 Prticas XP [Bec, 2000]
A XP vem crescendo devido o alto custo gerado pela utilizao das
metodologias tradicionais e o fracasso da maioria dos projetos de desenvolvimento
de software.
3.3.1 Valores da XP
A XP possui valores (princpios) que devem estar presentes em todos os
projetos de software XP. Esses valores caracterizam e auxiliam tanto as
necessidades da equipe como as necessidades de negcio. Os valores da XP so
20
fundamentais para que seja possvel atingir todos os objetivos do Projeto. Tais
valores devem ser respeitados e seguidos por todos os membros da equipe,
inclusive o cliente. Das quatro dimenses da XP, uma poder sempre melhorar um
projeto de software. [Don, 2003]
3.3.1.1 Simplicidade
Simplicidade um dos princpios da XP que facilita o desenvolvimento de
software em projetos que utilizam a XP, melhora a compreenso da equipe de
desenvolvimento em relao aos produtos que esto sendo codificados e aumenta
as chances de obter um produto com melhor qualidade.
Pode-se caracterizar o princpio da Simplicidade como um conjunto de
precaues ou atividades que devem ser alertadas ou aplicadas durante o
desenvolvimento do software. O principal objetivo de produzir software com
simplicidade evitar o desnecessrio e produzir somente o necessrio e na hora
certa. A criao de cdigo sem valor para o cliente, em um determinado momento do
projeto pode aumentar as chances de produo de software sem qualidade.
Deve ser evitada a duplicao de funcionalidade, a adivinhao de
funcionalidades futuras, a criao de muitas entidades e operaes (e.g., classes e
mtodos) e a codificao complicada, dificultando o entendimento pelos outros
desenvolvedores.
Cdigo simples tem menor chance de quebrar, principalmente em projetos que
mudam constantemente, ou seja, em projetos XP. Na existncia de mudanas
mais fcil implement-las quando se trata de um cdigo simples, fcil de trabalhar e
entender.
melhor fazer uma coisa simples hoje e pagar um pouco mais amanh para
mud-la se necessrio, ao invs de fazer uma coisa mais complicada hoje que
nunca ser usada. [Bec, 2000]
A simplicidade tem relao com outros valores da XP. Simplicidade e
Comunicao melhoram o desenvolvimento do projeto, uma vez que quanto melhor
a comunicao entre os membros da equipe, mais fcil ser implementar um
software de forma mais simples, evitando problemas futuros.
21
Algumas prticas da XP tambm esto relacionadas com a Simplicidade. Na
prtica Collective Ownership os desenvolvedores precisam entender o cdigo
facilmente para poder trabalhar com o mesmo, uma vez que nenhum programador
proprietrio dos cdigos. Na prtica de Testes, para que a criao dos testes seja
correta e eficaz necessrio um design simples, fcil de entender. A prtica de
Testes e o Desenvolvimento Dirigido por Testes (TDD) so importantes e facilitam a
criao de cdigo simples. No Refactoring o cdigo modificado, no excluindo as
suas funcionalidades, seu objetivo, visando simplificar o cdigo porm garantindo
atravs dos testes que no existem quebras.
3.3.1.2 Comunicao
A Comunicao outro valor importante para a XP. A importncia que a XP d
a interao entre os membros da equipe do projeto e o cliente, faz necessrio que
exista uma boa prtica que auxilie o desenvolvimento do Projeto.
A constante, fcil e pacfica comunicao entre os membros da equipe facilita a
descoberta de novos requisitos, auxilia as atividades de implementao, aumenta as
chances de propagao de conhecimento e prov conforto e diverso a equipe,
visando o bom andamento do projeto.
Entre os meios existentes de comunicao, o que mais interessa a projetos XP
a comunicao face face. A utilizao de documentos formais, e-mails,
telefonemas so viveis, mas a presena real dos envolvidos em um nico ambiente
traz mais benefcios ao projeto e entendimento sobre o mesmo. Esta escolha reduz
a elaborao e consulta de inmeros documentos que muitas vezes so difceis de
entender ou so elaborados mas no utilizados, e tambm as chances de no
entendimento entre as pessoas e delas em relao aos requisitos do projeto.
A Comunicao quando combinada com os outros valores da XP facilita ainda
mais o desenvolvimento do projeto. Quando na necessidade de obter rpido
feedback, a boa comunicao entre a equipe do projeto e o cliente fundamental
para a realizao do mesmo.
Em relao as prticas da XP, a comunicao explorada em prticas como
Pair Programming, onde os programadores precisam se comunicar para que um
22
produto seja elaborado corretamente, e para que um programador possa absorver
determinado conhecimento pertencente ao outro integrante.
3.3.1.3 Feedback
Os resultados positivos da elaborao de produtos do software podem ser
garantidos e explicitados atravs de diversas prticas e valores da XP e no devem
se apoiar no otimismo da equipe. Feedback o valor da XP que possibilita a equipe
descobrir se um produto foi elaborado corretamente e se est em conformidade com
o que foi requisitado pelo cliente. A obteno do feedback deve ser constante e deve
ser obtido tanto do cliente como do sistema.
Pequenas partes do software devem ser desenvolvidas e aps cada
desenvolvimento o feedback deve ser obtido, garantindo o status de aceitao do
cliente em relao ao produto gerado, garantindo que o produto est em
conformidade com os requisitos e diminuindo os riscos de elaborao de um
software sem valor para o cliente.
Obter feedback constantemente facilita a descoberta de novas funcionalidades
ou mudanas mais cedo e assim a implementao das mesmas tambm se torna
mais fcil.
Feedback est relacionado a outros valores da XP, entre eles Comunicao e
Coragem. Uma boa comunicao entre o cliente e a equipe de desenvolvimento
possibilita obter feedback constante, verificando a conformidade do sistema com os
requisitos do cliente. Feedback e coragem se combinam, uma vez que obtendo
feedback do sistema atravs de prticas que verifiquem se um servio foi
implementado corretamente, o programador tem mais coragem para implementar
todas as mudanas que so necessrias.
Feedback tambm se relaciona com algumas prticas da XP. Na prtica on-Site
Customer o cliente est presente no mesmo local que a equipe de projeto e portanto
mais fcil obter feedback sobre os produtos elaborados. Na prtica Testing
possvel obter feedback do sistema atravs da aplicao de testes freqentes.
Obtendo rpido feedback o desenvolvimento do sistema comea mais cedo. O
programador tem a garantia de que se houver alguma no-conformidade, esta ser
encontrada o mais rpido possvel, tanto pelo cliente como pelo sistema. Assim,
23
diminui-se o tempo gasto no planejamento, quando utilizadas as metodologias
tradicionais.
3.3.1.4 Coragem
Coragem o valor da XP que est relacionado com todos os outros valores.
Juntos, quando aplicados, os valores aumentam as chances de produo de
software com qualidade.
Coragem necessria nas horas em que a equipe precisa se comunicar,
principalmente quando as decises no so agradveis mas precisam ser tomadas.
Coragem na hora de desenvolver com simplicidade, mesmo que o programador no
possa mostrar todo o seu conhecimento, desenvolvendo apenas o que tem valor
para o cliente. Coragem para obter feedback constante, realizar todas as mudanas
necessrias, simplificar o sistema sempre que possvel.
3.3.2 Prticas da XP
3.3.2.1 The Planning Game
Tanto em projetos XP como em projetos que utilizam metodologias tradicionais
de desenvolvimento de software necessrio que existam atividades para a
realizao do planejamento do projeto. O Planejamento importante para que
algumas variveis e decises sejam explicitadas ajudando a equipe a entender o
que precisa ser feito e como deve ser feito.
As atividades de planejamento em projetos XP so exercidas por dois grupos
de pessoas. O pessoal de negcio e o pessoal tcnico. Porm algumas atividades
de negcio dependem de atividades tcnicas de planejamento.
24
Entre as atividades exercidas pelo pessoal de negcio, esto a definio (1) do
escopo do projeto, (2) prioridades e (3) composio e datas das verses de
produtos. Nas atividades realizadas pelo pessoal tcnico esto (1) o estudo das
estimativas do projeto, (2) identificao das conseqncias e impactos tcnicos e
financeiros, (3) o estudo e definio de como ser o processo de desenvolvimento e
(4) a definio de um cronograma detalhado. Identificado o tamanho do projeto e
em quanto tempo ser realizado.
O planejamento no deve durar meses, mas preciso um planejamento mnimo
para saber onde estamos indo, como atingiremos os objetivos e quais os riscos que
podem ser encontrados. [Ast, 2002]
Os requisitos mudam constantemente e portanto o planejamento tambm
sofrer diversas mudanas. Devido ao relacionamento existente entre as prticas da
XP, possvel que as atividades de planejamento sejam suportadas por outras
prticas quando temos uma situao negativa. Com a realizao de pequenas
verses (Small releases) as no conformidades do planejamento tm um impacto
muito menor no projeto. Com a presena do cliente (On-site customer) pode-se obter
feedback mais rpido sobre o planejamento elaborado e no-conformidades
existentes.
Voc pode comear a desenvolver com um plano simples e continuamente
refin-lo ao longo do projeto. [Bec, 2000]
3.3.2.2 Small Releases
Toda verso de um produto do software deve ser a menor possvel, contendo
os requisitos de negcio mais valiosos. [Bec, 2000]
As releases (verses de entrega) so planejadas e devem ser pequenas, mas
principalmente ter valor de negcio significativo. Uma release implementada pela
metade no uma release pequena, e sim uma release incompleta, sem significado.
Uma release no pode ser liberada enquanto no estiver completamente acabada.
[Ast, 2002]
Small releases tem suporte de algumas prticas XP. Com small releases
possvel planejar (The planning Game) o suficiente para uma verso de um produto
25
do software em menos tempo. Aps a implementao da release, ela testada
(Testing) e integrada (Contnuos Integration), fornecendo rpido feedback em
relao aos requisitos implementados. O design pode ser o mais simples (Simple
design), representando apenas os servios necessrios.
Com small releases algumas variveis do projeto podem ser modificadas ao
longo do desenvolvimento, como escopo, datas de entrega, prioridades.
3.3.2.3 Metaphor
As metforas so utilizadas pela equipe do projeto para ter um entendimento
comum do contexto do sistema. As metforas ajudam cada membro do projeto a
entender os elementos bsicos e suas relaes. Ao longo do desenvolvimento do
projeto, a equipe encontrar nova inspirao atravs da compreenso da metfora
escolhida para o projeto. [Bec, 2000]
A utilizao de metforas evita que os membros da equipe tenham diferentes
vises sobre o que deve ser implementado, e aumenta a produtividade da equipe,
uma vez que a metfora definida compreendida e utilizada para facilitar o
desenvolvimento. Porm a escolha de uma metfora deve ser um processo
cauteloso, uma vez que muitos membros da equipe podem no aproveitar o seu
significado, o que dificultaria o desenvolvimento do projeto.
A idia que cliente e desenvolvedores tenham uma mesma viso do sistema
e sejam capazes de falar sobre o sistema utilizando uma mesma linguagem. [Hig,
2002]
O uso de metforas est relacionado a alguns valores da XP. possvel obter
rpido feedback e fcil comunicao entre os membros da equipe se as metforas
foram aceitas e esto sendo utilizadas pelos membros da equipe para facilitar o
desenvolvimento do projeto.
Entre as prticas da XP que fazem uso da metfora do sistema esto o
Refactoring, que atravs da metfora, mais fcil realiz-lo para refinar o sistema; o
Pair Programming, onde um par de programadores ir desenvolver mais rpido e
fcil se apoiados em uma metfora do sistema; e o Simple Design, onde os
26
membros da equipe desenvolvem com simplicidade quando utilizam a metfora
escolhida e entendem atravs dela o que realmente precisa ser feito.
3.3.2.4 Simple Design
O design correto para o sistema, aquele que passa em todos os testes, no
tem lgica duplicada, demonstra a inteno dos programadores e tem o menor
nmero possvel de classes e mtodos. [Bec, 2000]
Elaborar um design simples implementar o que estritamente necessrio e
somente no momento necessrio. Um design simples deve conter somente as
informaes necessrias para que o produto esteja em conformidade com o que foi
requisitado.
Simple Design tem um vnculo forte com outras prticas XP. Mantendo um
design simples, o Refactoring torna-se ainda mais fcil. O Pair Programming
garante que o design implementado realmente est sendo o mais simples possvel.
As Small Releases devem possuir um design simples com somente as
funcionalidades necessrias.
Simple Design e Testing possuem uma relao ainda maior. A criao dos
cdigos de teste antecipadamente ao cdigo de design, garante que no cdigo de
design vo existir somente as funcionalidade necessrias (aquelas que foram
implementadas no cdigo de teste), obtendo um design simples, com maior
qualidade e desenvolvendo no tempo estimado, j que funcionalidades futuras no
so implementadas e os testes provem feedback em relao as no-
conformidades. Neste momento pode-se notar a importncia e benefcios do
Desenvolvimento Dirigido por Testes (TDD).
27
3.3.2.5 Testing
A prtica de testes Testing a prtica XP mais importante nesse trabalho,
devido a sua forte relao com a qualidade dos produtos codificados e com o TDD.
Alm disso, a prtica de testes tratada como a prtica chave da XP. [Hig, 2002]
A prtica de testes til aos programadores em qualquer contexto de
desenvolvimento, e junto com o TDD so um timo ponto de partida para qualquer
programador que deseja torna-se um usurio XP. [Adaption]
Toda funcionalidade do sistema precisa ter testes automatizados. Os
programadores so responsveis por elaborar os testes unitrios, que testam
pequenas partes do software, enquanto o cliente responsvel pelos testes de
aceitao (teste funcionais) que so criados para validar as funcionalidades.
As metodologias tradicionais possuem prticas que suportam atividades para
certificar que um produto codificado tem qualidade e atende aos requisitos do
cliente. Porm, as prticas muitas vezes no so levadas a srio, assim como a
metodologia utilizada, ou so aplicadas aps a integrao do produto ao sistema, o
que torna a fase de correo bem mais difcil. O tempo gasto na correo de no-
conformidades preocupante, mas o tempo gasto depurando o cdigo geralmente
bem maior e pode prejudicar o andamento do projeto.
O TDD, por ser uma metodologia de desenvolvimento utilizada na prtica de
testes, possui as caractersticas da prtica de testes da XP e em muitas bibliografias
o TDD caracterizado como sendo uma das prticas da XP. Por esse motivo as
caractersticas adicionais e o funcionamento da prtica de testes ser descrito no
captulo referente ao TDD. Neste momento vale ressaltar que a elaborao e
aplicao de testes devem ser exaustivas. Atravs dos testes programadores e
cliente obtm rpido feedback sobre os produtos gerados. Os testes precisam ser
elaborados, ou seja, codificados antes da elaborao do cdigo de design. A
elaborao do cdigo de teste antes da elaborao do cdigo de design vantajosa,
uma vez que criando o cdigo de teste descobrimos quais so as verdadeiras
funcionalidades de uma parte do sistema. Se a cada alterao no cdigo o teste for
executado, o programador tem total confiana de que o cdigo est funcionando
corretamente.
28
A prtica de Testes tambm tem relao com as outras prticas da XP. Com
um design simples (Simple Design) a elaborao dos cdigos de teste se torna muito
mais fcil. Com o Pair Programming ambos os programadores podem incrementar
cada vez mais os testes. A integrao contnua (Continuos Integration) dos produtos
mais fcil e confiante uma vez que um produto s integrado quando todos os
testes passarem 100%. Como os cdigos no possuem proprietrios (Collective
Ownership) mais fcil entender o objetivo de um programa/cdigo analisando pelo
cdigo de teste. O refinamento do cdigo atravs do Refactoring feito sempre que
necessrio e com coragem pelos desenvolvedores, pois os mesmos podem certificar
que as alteraes no comprometeram o que estava funcionando corretamente,
atravs dos testes. O cliente acompanha o desenvolvimento (On-Site Customer) e
verifica que o projeto est em bom andamento atravs dos testes.
3.3.2.6 Refactoring
Refactoring o processo de alterar um sistema de software de tal forma que
ele no altere o comportamento externo do cdigo e melhore a sua estrutura interna.
Essa uma forma disciplinada de limpar o cdigo que minimiza as chances de
introduo de bugs. [Fow, 1999]
O Refactoring um refinamento do cdigo com o objetivo de torn-lo mais
simples porm sem excluir qualquer funcionalidade. O Refactoring uma atividade
que deve ser executada a todo o momento, antes dos testes e de qualquer alterao
no cdigo. Algumas vezes voc codifica mais que o necessrio para que uma
funcionalidade funcione corretamente. [Bec, 2000]
O Refactoring aumenta a qualidade do cdigo, evitando redundncias,
complexidade e tornando o cdigo mais fcil de entender e modificar.
Atravs da propriedade coletiva de cdigo (Collective Ownership) os
programadores podem fazer o Refactoring sempre que acharem necessrio. Com
um design simples (Simple Design) mais fcil fazer o Refactoring. Atravs dos
testes (Testing) possvel verificar se o Refactoring no comprometeu o correto
29
funcionamento do cdigo, e com isso os programadores se sentem mais
encorajados para realiz-lo.
3.3.2.7 Pair Programming
Na XP, toda linha de cdigo desenvolvida por um par de programadores. Dois
programadores fazem uso de um nico computador, com um mouse e teclado. Um
dos programadores fica com o papel de piloto, elaborando os testes, codificando as
funcionalidades ou fazendo o Refactoring, ou seja, pensando taticamente. O outro
programador observa o piloto, pensando estrategicamente, no impacto de um
mtodo implementado em uma classe. O co-piloto ajuda o piloto oferecendo
idias e se achar necessrio podem trocar de papis.
A programao em pares muda constantemente, ou seja, um programador no
faz par com outro programador o dia todo. Quando um programador tem dificuldade
em um determinado domnio, o mesmo deve programar com um programador que
tenha mais experincia naquele domnio.
Respeitando a prtica de 40 horas semanais (40 - Hour Week) os
programadores estaro descansados e dispostos para codificar em pares
produtivamente. A metfora (Metaphor) utilizada ajuda os pares a terem uma mesma
viso sobre o contexto do sistema. Codificando com simplicidade (Simple Design) os
programadores entendem mais facilmente o que o outro programador desenvolveu.
3.3.2.8 Collective Ownership
A prtica de propriedade coletiva (Collective Ownership) utilizada na XP para
que qualquer pessoa possa alterar um cdigo se achar necessrio. No
necessrio que um programador requisite uma permisso para alterar um cdigo,
uma vez que no existem proprietrios de cdigo. Porm necessria a utilizao
de uma ferramenta de controle de cdigo fonte (repositrio).
30
Permitindo que muitas pessoas trabalhem com o cdigo, faz com que cada
pessoa conhea um pouco de todo o sistema.
Como as prticas da XP suportam uma as outras, com a propriedade coletiva
no diferente. necessrio integrar o cdigo continuamente (Continuos
Integration), para evitar problemas de versionamento. Qualquer um pode alterar os
cdigos, uma vez que os Testes vo verificar se as mudanas no comprometeram
o correto funcionamento.
3.3.2.9 Continuous Integration
Na XP, a integrao contnua uma prtica utilizada para facilitar a
manipulao e entrega dos produtos do software (principalmente as alteraes),
evitar problemas de incompatibilidade, e verificar se os produtos que esto sendo
integrados no possuem falhas.
A freqncia com que a integrao deve ser realizada de no mnimo uma vez
ao dia, porm o ideal que a integrao seja realizada toda vez que uma tarefa for
concluda, e quanto mais vezes, melhor. Quanto mais integrao, o produto sofrer
menos quebras diminuindo o re-trabalho. indispensvel que todos os
desenvolvedores trabalhem com a ltima verso do produto.
A integrao contnua uma prtica que est relacionada com outras prticas
XP. Trabalhando com Small Releases, as funcionalidades implementadas so
menores e as atividades de integrao se tornam mais fceis. Os Testes so
utilizados para verificar se um produto est realmente pronto para ser integrado aos
demais, sendo necessrio que todos os testes passem 100% antes da integrao do
cdigo, evitando o depsito de cdigos com erro. Na propriedade coletiva (Collective
Ownership) necessria a utilizao de um repositrio de cdigo fonte para que os
desenvolvedores possam utilizar as verses finais dos produtos do software e
implementar as modificaes necessrias, depositando/integrando o cdigo ao
repositrio.
31
[1] ANT Produto do Projeto Apache [2] JUnit framework para criao de testes automatizados; criado por Kent Beck e Erich Gamma
As atividades de integrao so mais facilmente realizadas quando so
utilizadas ferramentas automticas para a construo do sistema (ANT[1]) e para a
realizao dos testes (JUnit[2]).
3.3.2.10 40 Hour Week
A prtica de 40 horas semanais uma prtica que aconselha a equipe de
projeto a no ultrapassar os seus limites de trabalho semanal. Os integrantes da
equipe so diferentes, produzem e tm rendimentos diferentes.
importante que a equipe planeje corretamente para desenvolver o projeto no
tempo esperado, respeitando o limite dos desenvolvedores. Trabalhar por hora extra
freqentemente, uma prtica desaconselhvel em projetos XP. No comeo do dia,
o desenvolvedor precisa estar bem, fisicamente e emocionalmente, para poder
exercer todas as suas tarefas dirias da melhor forma possvel.
A prtica de testes (Testing) minimiza as chances do desenvolvedor se
surpreender com problemas que afetariam todo seu dia de trabalho. A produtividade
do desenvolvedor aumenta, j que com os testes a codificao mais rpida e
segura.
3.3.2.11 On-site Customer
A XP insiste em fazer um cliente real trabalhar diretamente no projeto.
[Ast, 2002]
32
Em projetos XP importante que exista uma pessoa (Cliente), que represente o
usurio do sistema, para estar junto (fisicamente se possvel) com a equipe de
projeto, pronta para resolver problemas referentes ao mesmo, solucionar dvidas e
tomar decises referentes a prioridades, escopo e risco.
A presena do Cliente junto a equipe de projeto traz benefcios e qualidade ao
mesmo. Entre os benefcios mais importantes, est o rpido e constante feedback
que o cliente real pode fornecer a equipe de projeto.
3.3.2.12 Coding Standards
Em um projeto XP, a prtica Coding Standards utilizada para definir um
padro de codificao (comum no mercado) que deve ser adotado por toda a
equipe, buscando aumentar a produtividade e qualidade dos produtos gerados. A
utilizao de diferentes prticas de codificao, pode prejudicar o entendimento dos
desenvolvedores em relao aos produtos codificados e prejudicar a realizao de
algumas prticas XP.
A utilizao de uma codificao padro facilita a programao em pares (Pair
Programming), o Refactoring e a propriedade coletiva (Collective Ownership).
3.3.3 Os papis na XP
Assim como nas metodologias tradicionais de desenvolvimento de software, na
XP os papis desempenhados pelos integrantes da equipe do projeto so
importantes para que o projeto seja desenvolvido corretamente e com qualidade,
orientando cada um dos integrantes em relao as suas responsabilidades (alguns
integrantes tm mais de um papel) e mantendo um ambiente de desenvolvimento
comunicativo e agradvel.
A participao do cliente no desenvolvimento do projeto essencial para a XP,
mas ainda assim podemos dividir a equipe do projeto em duas equipes essenciais.
33
3.3.3.1 A equipe do cliente
A equipe do cliente representa o usurio do sistema e responsvel pela
caracterizao dos requisitos e elaborao dos testes de aceitao. Entre os papis
existentes na equipe do cliente esto:
Contadores de histrias: pessoas responsveis pela elaborao das user
stories (representao breve dos requisitos do sistema, necessidades do
usurio).
Examinador/Aceitante: pessoas responsveis pela realizao dos testes
de aceitao, para verificar o comprometimento das user stories.
Patrocinadores: pessoas provedoras de recursos para o projeto. [Ast,
2002]
Chefe: pessoa que supervisiona e incentiva as equipe do projeto.
3.3.3.2 A equipe de desenvolvimento
A equipe de desenvolvimento est ambientada com a linguagem tecnolgica
que ser utilizada para desenvolver o sistema e responsvel pelas estimativas
tcnicas e o desenvolvimento do projeto. Entre os papis existentes na equipe de
desenvolvimento esto:
Tcnico: pessoa experiente, com a responsabilidade de guiar a equipe
quando necessrio e tornar o desenvolvimento mais fcil.
Acompanhador/Tracker: pessoa responsvel por fornecer feedback a
equipe, do comprometimento com as estimativas definidas.
Facilitador: tem o objetivo de facilitar o relacionamento entre os membros
da equipe, atuando com neutralidade.
Arquiteto: a arquitetura produzida e refinada (Refactoring) pelo arquiteto
conforme necessrio. [Ast, 2002]
Programador: o programador XP, responsvel pela codificao, trabalha
de forma simples, comunicando-se constantemente com os membros da
34
equipe. Constri os testes unitrios, programa em pares e faz o
Refactoring.
Com muito pouco processos preciso ter pessoas extraordinrias para fazer
coisas ordinrias; com processos demais, nem mesmo as pessoas extraordinrias
conseguem fazer coisas extraordinrias. [Ast, 2002]
3.4. Test Driven Development - TDD
Desenvolvimento Dirigido por Testes
As metodologias tradicionais de desenvolvimento de software geralmente
utilizadas pelos desenvolvedores, facilitam o desenvolvimento do software atravs
da aplicao de prticas e regras especficas de cada metodologia. Anteriormente,
j foi citado o problema dessas metodologias tradicionais e a rejeio dos
desenvolvedores em relao as suas prticas. Decorrente desse problema, as
metodologias geis de desenvolvimento de software esto cada vez mais ganhando
adeptos e espao na comunidade de Engenharia de Software.
A XP (Extreme Programming) foi apresentada neste trabalho como uma das
diversas metodologias geis de desenvolvimento de software, que possui prticas
simples, fceis de serem seguidas e que realmente contribuem para o
desenvolvimento de um projeto de software (quando so seguidas corretamente).
As prticas da XP possuem um alto grau de dependncia, suportando uma as
outras, e para que um projeto XP obtenha os benefcios da aplicao dessa
metodologia, preciso que todas as prticas sejam aplicadas simultaneamente (com
exceo da prtica de testes).
O Desenvolvimento Dirigido por Testes (TDD Test Driven Development)
uma metodologia de desenvolvimento utilizada em projetos de software atravs da
35
prtica de Testes da XP, com o objetivo de facilitar o desenvolvimento
(principalmente a codificao) e garantir qualidade aos produtos gerados.
Em algumas bibliografias [Adaption], a prtica de testes da XP caracterizada
como o prprio TDD, e com isso percebe-se que a XP se apropriou do TDD e seus
benefcios. As prticas da XP aplicadas juntamente com os conceitos do TDD
aumentam ainda mais as chances de desenvolvimento com qualidade.
Apesar de o TDD ser uma metodologia aplicada com objetivo de verificar a
conformidade dos produtos codificados com os requisitos especificados durante o
desenvolvimento, devemos caracteriza-lo como uma tcnica de Anlise e Design, e
no uma tcnica de Testes do processo de Engenharia de Software, pois a sua
grande contribuio est na percepo de o que deve ser feito e como deve ser
feito.
O TDD uma descoberta recente e vem ganhando cada vez mais ateno dos
desenvolvedores de software devido aos seus benefcios em relao a qualidade do
software e produtividade no desenvolvimento.
3.4.1 Como funciona o TDD?
O grande propsito do TDD produzir testes automatizados para produzir
cdigo, e atravs desse processo guiar o design e a programao. [Adaption]
O TDD uma metodologia de desenvolvimento que consiste na realizao de
algumas atividades repetitivas (realizadas durante a programao do sistema) para a
codificao de produtos do software produtivamente e qualificadamente.
Testes unitrios e Testes Funcionais so diferentes tipos de teste que verificam
diferentes vises do sistema. Em [Can, 2001], Jeff Canna utilizou uma metfora
para caracterizar testes unitrios e testes funcionais, imaginando-se a construo de
uma casa. Os testes unitrios seriam semelhantes a visita de um inspetor geral na
casa, para verificar se as diversas partes internas que compe a casa (fundao,
parte eltrica, parte hidrulica,...) iro funcionar corretamente, enquanto os testes
36
funcionais seriam uma vistoria dos futuros usurios da casa, verificando como seria
morar nessa casa.
Testes unitrios so elaborados pelos programadores para verificar se todos os
servios do sistema (e.g., todos os mtodos, de todas as classes) esto operando
corretamente. Testes funcionais so elaborados pelo cliente (algumas vezes com a
ajuda de uma pessoa experiente) para verificar que o sistema faz o esperado.
As atividades que compe o TDD so atividades que facilitam a elaborao da
anlise, design e codificao dos produtos do software, e que encorajam os
programadores a simplificar e realizar todas as mudanas no sistema quando
necessrio.
As principais atividades do TDD so: (1) a elaborao de testes unitrios
automatizados, que representem uma pequena funcionalidade (e.g., um mtodo de
uma classe), (2) a elaborao do cdigo de design referente ao cdigo de teste e (3)
o refactoring. Essas atividades so realizadas at que toda a funcionalidade seja
implementada, todos os testes passem 100% e o design seja o mais simples
possvel. Nenhum cdigo de design pode ser produzido antes que exista um cdigo
de teste referente ao mesmo, e o no cumprimento dessa regra pode comprometer a
qualidade dos produtos do software e a utilizao da metodologia TDD.
A elaborao de cdigos de teste e cdigos de design alternada no TDD.
Com isso, os programadores no se cansam de escrever cdigos de teste, pois eles
facilitam a elaborao dos cdigos de design e tornam esse processo mais divertido.
A elaborao do cdigo de teste anteriormente a elaborao do cdigo de
design um fator indispensvel no TDD. Esta prtica facilita o entendimento sobre o
que deve ser implementado e como deve ser implementado (anlise e design). Alm
disso, a codificao ter o design mais simples possvel, pois somente ser
implementado o que foi explicitado no cdigo de teste.
Na prtica, quando o programador receber um novo servio do sistema para ser
desenvolvido/codificado (em XP uma user story), o programador (1) elabora o cdigo
de teste (testes unitrios) para verificar as funcionalidades do cdigo de design; (2)
aps, o programador executa o cdigo de teste para verificar o sucesso ou falha do
mesmo; (3) atravs do resultado da execuo dos testes, o programador elabora o
cdigo de design necessrio, para que as falhas sejam corrigidas e o teste passe;
(4) o refactoring realizado para que o cdigo se torne mais simples; aps o
37
refactoring os testes so executados novamente para verificar que as modificaes
feitas no causaram nenhuma quebra e nem modificaram o comportamento.
No incio da codificao, quando os testes forem executados, sempre ocorrer
falhas/erros, pois a entidade (e.g., classe) e operaes (e.g., mtodos) que esto
sendo verificadas ainda no foram implementadas no cdigo de design, portanto os
testes no os reconhece. Assim, descobrimos o que temos que implementar no
cdigo de design e implementamos (e.g., quais mtodos e em quais classes).
No TDD, assim como na XP, as mudanas so sempre bem vindas.
importante que qualquer nova funcionalidade seja implementada quando necessria.
No TDD o cdigo testado antes e depois de qualquer modificao. Quando existir
algum erro, possvel voltar ao estado anterior.
Algumas prticas da XP tm bastante relao com o TDD e alguns xispeiros
dizem que a utilizao do TDD a porta de entrada para novos adeptos da XP,
pois a prtica de Testes a prtica chave da XP e tem relao com as demais.
O Refactoring uma prtica XP diretamente ligada ao TDD, pois ele deve ser
realizado continuamente para garantir que o cdigo tem o design mais simples
possvel. Os testes so executados antes e aps o refactoring. Pair Programming
outra tcnica da XP til para o TDD, pois um desenvolvedor pode explicitar sobre
outras operaes que deveriam constar no cdigo de teste.
Outra questo importante no TDD, o que testar? Tudo que possivelmente
possa quebrar deve ser testado. Todas as operaes devem ser testadas, com a
exceo de mtodos acessores (e.g., set(); e get();) e construtores simples.
Se voc tiver certeza que o seu cdigo possivelmente no possui quebras, tem
um design perfeito, todos gostam da sua interface e perfeitamente claro para
todos, ento voc no precisa test-lo. Porm, SEMPRE existir um erro em algum
cdigo, voc SEMPRE poder melhorar o cdigo, algum SEMPRE faz perguntas
sobre como o cdigo trabalha ou algum SEMPRE reclama da sua interface. [Ast,
2003]
38
3.4.2 Benefcios do TDD.
A utilizao do TDD como metodologia de desenvolvimento prov diversos
benefcios para os projetos de software. Entre os principais benefcios esto:
Design mais simples, limitado: evita a implementao de servios
futuros.
Melhor entendimento sobre o que deve ser desenvolvido.
Desenvolvimento rpido / produtividade.
Confiana: os testes do confiana ao programador.
Coragem para realizar mudanas: qualquer alterao que gerar um
erro, logo ser percebida.
Rpido feedback : aps a implementao o programador verifica qual
o resultado.
Programao mais divertida.
Menos depurao de cdigo: os erros existentes so explcitos.
Qualidade dos produtos codificados.
O TDD orienta o programador sobre qual caminho est sendo percorrido e
como se deve chegar no ponto de chegada.
3.4.3 A Importncia de Ferramentas Automatizadas de Teste
No TDD a elaborao e a execuo de Testes Unitrios deve ser exaustiva, e
para que este processo seja o mais agradvel e produtivo possvel, imprescindvel
a utilizao de ferramentas automatizadas de teste (e.i., frameworks de teste) que
auxiliem os programadores no desenvolvimento e acompanhamento dos testes.
A utilizao de ferramentas de desenvolvimento e execuo de testes
extremamente necessria para que os objetivos do TDD sejam alcanados, e a no
utilizao dessas ferramentas inviabiliza a utilizao dessa metodologia.
39
[1] JUnit framework para criao de testes unitrios automatizados; [Bec, 2001] [2] Cactus framework para criar testes unitrios em componentes J2EE [Cactus] [3] HttpUnit framework para criar testes funcionais para aplicaes web [HttpUnit] [4] JunitPerf framework para criar testes de performance em Web sites. [JunitPerf]
Atualmente existem diversas ferramentas para o desenvolvimento e
acompanhamento de testes de diversos tipos e que testam diferentes entidades
(e.g., classes, componentes, Servlets, JDBC,...) de um Sistema, como o JUnit [1],
Cactus [2], HttpUnit [3], JunitPerf [4],...
Em [Ast, 2003], foi discutida a metfora utilizada por Willian Wake para
descrever o ciclo de desenvolvimento do TDD.
Luz Verde - todos os testes passaram.
Luz amarela - falha de compilao
Luz vermelha - falha no teste
Para Willian, o ciclo de desenvolvimento consiste em:
1. Incio (luz verde)
2. Escreva um cdigo de teste.
3. Rode o teste; falha de compilao, a rotina ainda no foi definida. (luz
amarela)
4. Defina a nova rotina (assinatura).
5. Rode o teste novamente; erro, pois a rotina no tem funcionalidade. (luz
vermelha)
6. Fornea as operaes para a rotina.
7. Rode o teste. Passou. (luz verde)
8. Comece o ciclo novamente.
Um framework padro da linguagem JAVA para utilizao no TDD o JUnit,
que foi criado por Kent Beck (mesmo criador da XP) e Erich Gamma, e um
framework opensource sob licena da IBM. Atravs do JUnit e da sua arquitetura
possvel a criao de conjuntos de testes unitrios automatizados e o
acompanhamento da execuo dos testes atravs de uma das suas interfaces de
apresentao.
40
Na criao dos testes so utilizados mtodos que geralmente comparam
resultados esperados e resultados obtidos (e.g., assertEquals (esperado, obtido)) ou
a nulidade (e.g., assertNull() ou assertNotNull()) e a veracidade (e.g., assertTrue() ou
assertFalse()) dos resultados obtidos.
Alm da criao de testes unitrios automatizados, o JUnit possibilita que o
programador adicione em uma nica classe, diversos mtodos de teste referentes a
classes diferentes.
3.5 Implementao de Casos de Teste
PROBLEMA: Elaborar uma aplicao para manipular o cadastro de algumas
disciplinas do 4 ano de Cincias da Computao, com os nomes dos respectivos
professores.
1 passo
Fig. 2 - TestCadastro.Java
import junit.framework.*; public class TestCadastro extends TestCase{ String prof; Cadastro objCad = new Cadastro(); public void testCadastrar(){ objCad.cadastrar("Sistemas Informacao","Joao Batista"); prof = objCad.consultar("Sistemas Informacao"); assertEquals("Joao Batista", prof); } public void testConsultar(){ objCad.cadastrar("IA", "Andre"); prof = objCad.consultar("IA"); assertEquals("Andre", prof); }
}
41
- A classe de teste (TestCadastro) implementada e definido um conjunto
mnimo de operaes (e.i., mtodos) que devem ser testadas.
Fig. 3 Compilando TestCadastro.Java
- A classe TestCadastro compilada e erros ocorrem pois a classe Cadastro
no foi identificada e precisa ser implementada.
Fig. 4 - Cadastro.java
Fig. 5 Compilando Cadastro.java
- A classe Cadastro implementada da forma mais simples possvel e
compilada com sucesso.
public class Cadastro{
}
42
Fig. 6 Compilando TestCadastro.java
- A classe TestCadastro compilada novamente e erros ocorrem, pois os
mtodos que devem ser testados no fo
