UNIVERSIDADE CATÓLICA DE SANTOS

FACULDADE DE ENGENHARIA - FENGE
CIÊNCIA DA COMPUTAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO – II

Garantia da Qualidade da Programação de Software
Utilizando a Metodologia de
Desenvolvimento Dirigido por Testes
TDD – Test Driven Development

Prof. Orientador: João Batista Carneiro
Aluna: Tatiana Costa Rodrigues
Novembro / 2003

Garantia da Qualidade da Programação de Software
Utilizando a Metodologia de
Desenvolvimento Dirigido por Testes
TDD – Test Driven Development

___________________________________
Aluna: Tatiana Costa Rodrigues

____________________________________
Prof. Orientador: João Batista Carneiro

Resumo
Qualidade de Software é um requisito que preocupa a maioria das empresas de
desenvolvimento de software. Todavia, muitas empresas não se preocupam em
aplicar esforços para garantir que os produtos do software sejam gerados com
qualidade. Geralmente essas empresas não utilizam processos de desenvolvimento
de software ou usam processos ineficazes, que comprometem o cronograma do
projeto e conseqüentemente 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 práticas simples e se preocupa em entregar ao cliente software
com qualidade.
O Desenvolvimento Dirigido por Testes (TDD)

é uma metodologia direcionada

através da prática de testes da XP, e consiste em criar códigos de teste para guiar o
desenvolvedor na criação dos códigos de design, desenvolvendo com simplicidade,
confiança e qualidade.

Palavras-Chave
Software, Qualidade, Processos, SQA, Testes, Metodologias Ágeis, XP, TDD,
Análise, Design, Simplicidade, Confiança, Produtividade, JAVA, JUnit

Abstract
Software quality is a requirement that worries most of the software development
companies. Still, much companies don’t care in apply efforts to certify that the
software products have been produced with quality. Usually, these companies don’t
use software development process or do it in a non-effective process that
compromise the project’s schedule and consequently the software’s quality.
The Agile Methodologies were created to confront with the bureaucracy of the
traditional methodologies and then to conquer software’s 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 – Práticas 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 execução do JUnit _______________________________________________ 43
Fig. 10 – Execução do JUnit ________________________________________________________ 43
Fig. 11 - Cadastro.java _____________________________________________________________ 44
Fig. 12 – Compilando todas as classes e executando o JUnit ______________________________ 44
Fig. 13 – Execução 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 – Execução do JUnit ________________________________________________________ 48
Fig. 19 - Cadastro.java _____________________________________________________________ 49
Fig. 20 – Compilando todas as classes e executando o JUnit ______________________________ 49
Fig. 21 – Execução 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 – Execução do JUnit ________________________________________________________ 53
Fig . 27 - Cadastro.java ____________________________________________________________ 54
Fig. 28 – Compilando todas as classes e executando o JUnit ______________________________ 54
Fig. 29 – Execução do JUnit ________________________________________________________ 55

Sumário

1. Introdução _____________________________________________1
1.1 Contextualização _____________________________________________________________ 1
1.2 Problema____________________________________________________________________ 3
1.3 Problematização ______________________________________________________________ 3
1.4 Objetivos ____________________________________________________________________ 3
1.4.1 Objetivo Geral ____________________________________________________________ 3
1.4.2 Objetivos Específicos _______________________________________________________ 4
1.5 Relevância ou Justificativa ______________________________________________________ 5

2. Revisão Bibliográfica ____________________________________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 Padrões 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 Comunicação ________________________________________________________ 21
3.3.1.3 Feedback ___________________________________________________________ 22
3.3.1.4 Coragem ____________________________________________________________ 23
3.3.2 Práticas 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 papéis 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 Benefícios do TDD. _______________________________________________________ 38
3.4.3 A Importância de Ferramentas Automatizadas de Teste __________________________ 38
3.5 Implementação de Casos de Teste ______________________________________________ 40
3.6 Conclusão __________________________________________________________________ 56

BIBLIOGRAFIA ___________________________________________57
SITES VISITADOS ______________________________________________________________ 57

1. Introdução

1.1 Contextualização
A Metodologia de Desenvolvimento TDD é uma metodologia na qual
programadores utilizam as facilidades e benefícios de Técnicas de Teste para
exercer suas atividades e implementar as funcionalidades do sistema.
O objetivo no TDD é a produção de Software com qualidade, obedecendo as
regras de negócio e prazos estipulados. Espera-se também que o desenvolvimento
do sistema seja realizado de forma simples e rápida, e que as não-conformidades
sejam identificadas facilmente e no menor tempo possível.
A criação de códigos de teste para testar código de design antes da criação
dos mesmos é o elemento que caracteriza o TDD como uma metodologia que facilita
o desenvolvimento de software. O Programador deve começar (1) criando um teste
simples e pequeno, (2) codificar somente o que foi declarado no código de teste e
(3) continuar com o próximo teste até que o código esteja finalizado e limpo.
Entre os fatores que acarretam os maiores riscos à qualidade em um Projeto de
Software, está a ausência ou ineficiência de testes que validem o funcionamento
correto do sistema e a boa aplicabilidade de suas características.
A Garantia da Qualidade de Software ("Software Quality Assurance, SQA") é
uma atividade importante e necessária em todos os projetos de Desenvolvimento de
Software e deve estar presente em todas as etapas do Processo de
Desenvolvimento (Análise, Design, Implementação, Testes,...).
Muitas equipes de projeto acreditam que a utilização de testes é um esforço
desnecessário.

Outras

pretendem

utilizar

testes

para

verificar

o

correto

funcionamento do sistema, mas devido à inexperiência de alguns membros da
equipe ou o término do prazo de entrega do projeto, os testes são ignorados,
comprometendo a qualidade do software.
As atividades para garantir a qualidade do software são responsabilidades dos
Programadores ou do Pessoal de Controle de Qualidade? A grande maioria dos
programadores prefere não 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
1

produza um código de teste para validar e facilitar a criação do código de design, e
após produza o código de design.
A Metodologia Ágil de Desenvolvimento de Software “Extreme Programming XP”, possui valores que auxiliam à equipe de projeto no desenvolvimento do
software. Comunicação, simplicidade, feedback e coragem são valores que (1)
melhoram a comunicação entre todos os membros da Equipe (clientes, gerentes e
programadores), (2) produzem somente funcionalidades que são necessárias para o
momento apropriado, (3) capturam informações dos membros da equipe e/ou do
próprio sistema que têm impacto no funcionamento do sistema e (4) dão confiança à
equipe para realizar mudanças sempre quando necessárias.
Alguns valores da XP estão relacionados à prática 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.
Além da prática de Teste (Testing), a XP possui práticas como The Planning
Game (Planejamento do Jogo), Simple Design (Simplicidade), Refactoring
(Reestruturar o Sistema), Pair Programming (Programação em Pares), Collective
Ownership (Propriedade coletiva de código), entre outras.
O Desenvolvimento Dirigido por Testes (ou Test Driven Development - TDD) é
uma Metodologia de Desenvolvimento, utilizada na mais importante prática da XP, a
prática de teste, que tem como características (1) a utilização exaustiva de conjuntos
de testes unitários, (2) a não permissão da produção de código de design antes que
exista um código de teste para validá-lo (3) e a percepção de qual código deverá ser
escrito baseando-se no código de teste, o que limita o código de design e
conseqüentemente

diminui

o

risco

de

implementação

de

características

desconhecidas.
O TDD não é uma técnica de teste. A criação de código de teste anteriormente
à criação de código de design, se dá na fase de Codificação e pode ser
caracterizada mais apropriadamente como uma técnica de análise ou design, isso
porque a criação do código de teste possibilita ao programador (1) decidir o que ele
irá programar no código de design e o que não irá, (2) e também definir que
características de design vão possuir as funcionalidades que serão implementadas.

2

1.2 Problema

Baixa qualidade dos Softwares em decorrência da não utilização de técnicas
que validem e facilitam o processo de programação.

1.3 Problematização

“Atualmente cerca de 60% dos projetos de desenvolvimento de software são
executados sem um processo estabelecido de desenvolvimento de software ”.
[Ast, 2002]

A não utilização de uma Metodologia de Desenvolvimento de Software se dá
pelo alto índice de documentação requerida pelas metodologias tradicionais,
que muitas vezes não são utilizadas e/ou são 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 técnicas e frameworks de teste, notadamente aplicada à fase de
codificação das especificações.

3

1.4.2 Objetivos Específicos

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 importância dos testes para a garantia da qualidade de software.

O que são Metodologias Ágeis (Agile Methodology), quais as suas
características e benefícios para a garantia da qualidade.

A Garantia da Qualidade de Software através da Metodologia de
Desenvolvimento de Software “Extreme Programming - XP”.

O que é XP, seus participantes, princípios, técnicas/práticas e benefícios.

O que é, quais são as atividades, quem são os participantes, quais os
benefícios e o resultado da utilização da metodologia de Desenvolvimento
Dirigido por Testes - TDD.

Em qual atividade do processo de desenvolvimento de software são aplicadas
as técnicas 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 aplicação de testes através do JUnit, analisando o resultado dos testes,
comparando os resultados obtidos com o resultado esperado.

4

1.5 Relevância ou Justificativa

O estudo da Garantia da Qualidade de Software é significativo para todas as
pessoas que estão envolvidas diretamente ou indiretamente no desenvolvimento de
software.
O crescimento da utilização da Metodologia de Desenvolvimento de Software
XP envolve a Garantia da Qualidade, uma vez que a prática de maior importância na
XP é a prática de Testes.
Algumas técnicas da XP (Simple Design, Refactoring e Pair Programming)
influenciam a garantia da qualidade, sendo que para um projeto que utiliza a XP
todas as técnicas da XP devem estar relacionadas para se aproveitar todos os
benefícios 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 não adotam uma
metodologia de desenvolvimento. As características da XP que a tornam uma
metodologia “lightweight” encorajam as pessoas relacionadas ao desenvolvimento
de software a utilizá-la. Os valores da XP também contribuem para que ela seja
utilizada cada vez mais, aumentando as chances de produção de software com
qualidade.
A utilização do Framework JUnit possibilita que a qualidade seja garantida
utilizando uma ferramenta de alta credibilidade e fácil utilização.

2. Revisão Bibliográfica

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,

5

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, padrões de
desenvolvimento explicitamente documentados e características implícitas, que são
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 versão
para outra.
O Controle de Qualidade envolve um conjunto de atividades necessárias para
que sejam feitas revisões e avaliações ao longo do processo de desenvolvimento e
as não-conformidades sejam capturadas tão cedo quanto possível.
O Teste de Software é o elemento que representa uma avaliação da
especificação, projeto e geração de código do software. Os testes têm um papel
importante, e são aplicados para que os erros sejam encontrados antes que sejam
passados para a próxima atividade de Engenharia de Software ou para o cliente.
É importante que o objetivo de cada teste satisfaça os requisitos especificados,
que eles sejam planejados anteriormente a geração de código, que sejam testadas
as funcionalidades do software como também a correta interação entre os diversos
componentes.
Alguns padrões de qualidade são utilizados pela comunidade de Engenharia de
Software para avaliar os processos de desenvolvimento utilizados pelas empresas
de desenvolvimento de software. Entre as normas e padrões mais conhecidos estão:
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 através de um processo detalhado com ênfase no
planejamento.
Um novo grupo de metodologias de desenvolvimento de software têm
aparecido nos últimos anos, como uma mudança de paradigma de métodos de

6

desenvolvimento de software. Essas metodologias trazem uma nova forma de
construir software com mudança de diversos conceitos.
Algumas pessoas costumam dizer que o grande problema que compromete os
Projetos de Software é que os requisitos mudam constantemente. Porém, a
mudança é a norma para garantir um produto com qualidade e que satisfaça as
necessidades do cliente. Uma importante característica das metodologias ágeis é
que elas possuem princípios que encorajam a equipe de projeto a aceitar as
mudanças.
Diversas características das metodologias ágeis possibilitam que um software
seja produzido com alta qualidade. O foco na codificação, a valorização da equipe
de projeto, a aceitação pelas mudanças e a forte colaboração do cliente no projeto
são fatores que aumentam as chances de produção de software com qualidade.
Entre os objetivos das metodologias ágeis estão: (1) satisfazer o cliente
através de entrega rápida e contínua de software com valor, (2) prover ao cliente
vantagem competitiva através das mudanças necessárias que são sempre aceitas e
aplicadas, (3)

manter um ambiente e relação pacífica e produtiva entre cliente,

desenvolvedores e usuários e (4) desenvolver com simplicidade.
Em [Cun, 2001], o Manifesto Ágil:

Indivíduos e interações acima de processos e ferramentas;

Software em funcionamento acima de documentação abrangente;

Colaboração do cliente acima de negociação contratual;

Resposta à mudança 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, flexível, que possui poucas regras e
práticas que são fáceis de seguir.

7

As premissas da XP são (1) diminuir os riscos do projeto, (2) aumentar a
responsabilidade nas mudanças de negócio, (3) aumentar a produtividade e (4)
adicionar divertimento à equipe na construção do software. [Bec, 2000]
Comunicação, simplicidade, feedback e coragem são os quatro valores da XP,
definidos por Kent Beck, que a caracterizam como uma metodologia promissora e de
fácil utilização. Em projetos XP, deve existir uma constante e pacífica comunicação
entre todos os membros da equipe, o que facilita a descoberta de novos requisitos e
as atividades de programação. Simplicidade visando sempre desenvolver um
produto somente quando necessário, não adivinhando funcionalidades futuras e
codificando de forma simples. Feedback do cliente e do sistema também são
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 princípio que caracteriza a XP como uma metodologia
onde a equipe aceita as freqüentes mudanças, como também trabalhar com novas
práticas que desafiam as metodologias de desenvolvimento de software tradicionais.
Além dos valores, a XP possui Práticas, que suportam uma as outras,
relacionadas às etapas de Planejamento, Design, Codificação e Testes.

Planning Game: são determinados escopo, prioridades de negócio,
estimativas técnicas e datas de entrega; desenvolvedores trabalham junto
com o cliente para decidir quais funcionalidades serão implementadas.

Small Releases: colocar o projeto em produção tão cedo quanto possível;
possibilita rápido 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
visão do sistema; uma definição da arquitetura conceitual geral do sistema.
[Ast, 2002]

Simple Design: o processo de codificação deve ser o mais simples possível,
possibilitando a todos os desenvolvedores trabalhar em um mesmo código;

Testing: é a prática mais importante da XP, sempre em busca de qualidade; a
criação e aplicação de testes devem ser freqüentes, desde a concepção de
um produto; os testes provêm rápido feedback e dá coragem a equipe para
realizar as mudanças sempre que necessário;

8

Refactoring: os programadores reestruturam o sistema, simplificando o
código, se preocupando em não alterar as suas funcionalidades.

Pair Programming: programação em pares, em uma única máquina, com um
único teclado; os programadores se ajudam, trocam conhecimento e
encontram erros mais depressa.

Collective Ownership: qualquer desenvolvedor pode mudar qualquer código;
não existem proprietários para os códigos.

Continuous Integration: integração freqüente, verificando se todos os produtos
estão interagindo normalmente e se as mudanças realizadas comprometem o
correto funcionamento do sistema;

40 - Hour Week: respeitar o limite de horas semanais de trabalho,
aproveitando ao máximo o tempo permitido;

On-site Customer: a presença do cliente junto à equipe de projeto a todo o
momento, podendo solucionar dúvidas e ajudar a equipe sempre que
possível;

Coding Standards: respeitar o estilo de codificação padrão estabelecido pela
equipe de projeto, para que todos os desenvolvedores possam trabalhar em
todos os códigos.

2.4 Test Driven Development – TDD
Desenvolvimento Dirigido por Testes

TDD é uma metodologia de desenvolvimento utilizada em projetos de software
através da mais importante prática da XP, a prática de Testes. Porém, o TDD não é
uma técnica utilizada nas atividades de teste do processo de engenharia de
software.

A utilização dessa metodologia ocorre especialmente na fase de

codificação e é caracterizada como uma técnica de análise e design.
O grande propósito do TDD é produzir testes automatizados para produzir
código, e através desse processo guiar o design e a programação. [Adaption]

9

Os testes fornecem uma definição ou documentação do comportamento
desejado. Torna-se parte da solução. [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
rápido,

com código mais simples e com melhor qualidade. Código fácil de se

projetar, escrever, ler, entender, estender e manter. [Ast, 2003]
A elaboração de código de teste e código de produção é alternada no TDD.
Assim os programadores não se cansam de escrever códigos de teste, até mesmo
porque eles facilitam a elaboração do código de produção e tornam esse processo
mais divertido. São os programadores que escrevem os seus próprios casos de
teste, e não uma equipe responsável pelos testes. Esse estilo de desenvolvimento
faz com que os programadores se sintam mais confiantes em relação aos seus
códigos, evitando que os erros sejam capturados mais adiante por outras pessoas.
Em Object Mentor [Obj, 2003], os passos para se desenvolver através do TDD
são:

Escrever um código de teste que especifica um pequeno pedaço de
funcionalidade;

Certificar se o teste falhou (a funcionalidade ainda não foi implementada);

Escrever somente o código necessário para o teste passar;

Fazer o refactoring no código, certificando que o mesmo possui o mais
simples design possível, não alterando o seu comportamento.

Entre as regras que devem ser seguidas estão:

Testar tudo que possivelmente possa falhar;

Elaborar primeiro os códigos de teste;

Todos os testes devem passar 100% a todo o momento.

No TDD, assim como na XP, as mudanças são sempre bem vindas. É
importante que qualquer nova funcionalidade seja implementada. No TDD o código é
testado antes e depois de qualquer modificação. Quando existir algum erro, é
possível voltar ao que foi produzido anteriormente.
Entre os benefícios do TDD, destacam-se (1) as prevenções de defeitos devido
à utilização exaustiva de testes, (2) o pouco tempo gasto procurando pelos defeitos
no código de design, (3) a elaboração de um código simples, claro e coeso, (4) a
elaboração de testes para cada funcionalidade isoladamente, (5) a criação de testes
10

automatizados e (6) o aumento da coragem do desenvolvedor para modificar o
código se necessário e da confiança de que o código funciona corretamente.
Diversas ferramentas oferecem suporte a metodologia TDD, facilitando o
acompanhamento dos testes, o progresso das execuções e quais testes falharam,
através de interfaces com o usuário.

O JUnit é um framework de teste para a

linguagem de programação JAVA e está diretamente ligado com o TDD. Através da
interface do JUnit é possível 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 avanço da descoberta de novas tecnologias, a crescente utilização de
sistemas distribuídos e o grande número de usuários acessando informações de um
domínio específico, a busca pela qualidade dos serviços providos por um sistema
têm preocupado cada vez mais os desenvolvedores de software.
Entre os fatores que acarretam os maiores riscos à qualidade em um Projeto de
Software, está a ausência ou ineficiência de práticas de qualidade e testes que
validem o funcionamento correto do sistema e a boa aplicabilidade de suas
características.
Outro fator que implica na baixa qualidade do software é a não utilização de
Metodologias de Desenvolvimento de Software, que tornam o desenvolvimento mais
eficiente e previsível. Porém, devido ao alto índice de documentação requerida pelas
metodologias tradicionais, que algumas vezes não são utilizadas, são ineficazes e

11

dificultam o cumprimento do cronograma do projeto, elas são 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 também deve ser
avaliado freqüentemente, 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
explícitos e implícitos estabelecidos e obedece aos padrões especificados.
A preocupação 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 utilização de práticas de garantia da
qualidade e testes, são um esforço desnecessário. Outras pretendem utilizá-las para
verificar o correto funcionamento do sistema, mas devido à inexperiência de alguns
membros da equipe ou o término 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 necessária 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, Análise, Design,
Implementação, Testes,...) e tem como principal objetivo garantir a alta qualidade do
software através de atividades que possibilitam avaliar os produtos do software e
relatar as ocorrências de não-conformidades aos responsáveis pelo Projeto.
As principais atividades da SQA são:

a preparação do plano de garantia da qualidade para o projeto;

avaliação da descrição do processo de software do projeto;

revisão das atividades de Engenheira de Software do processo;
12

avaliação dos produtos do software elaborados;

documentação e correção das não-conformidades;

registrar e relatar aos superiores todas as não-conformidades;

aplicação de revisões técnicas formais;

3.1.3 Testes de Software

Teste de Software é o elemento que representa uma avaliação do projeto e
geração de código do software. As atividades de Garantia da Qualidade do Software
são importantes para a descoberta de erros, porém são insuficientes para o alcance
do correto funcionamento do software. Os testes têm um papel importante, e são
aplicados para que os erros sejam encontrados antes que sejam passados para a
próxima atividade de Engenharia de Software ou para o cliente.
Os testes garantem que o software está funcionando corretamente, atendendo
o

que foi estabelecido

na especificação, assim como os requisitos de

comportamento e desempenho.
É importante que (1) o objetivo de cada teste satisfaça os requisitos
especificados, (2) que eles sejam planejados anteriormente a geração de código, (3)
que sejam testadas as funcionalidades do software como também a correta
interação entre os diversos componentes e (4) que os testes sejam aplicados por
profissionais capacitados.
Como produto da atividade de testes, na criação dos testes do software são
criados diversos “casos de teste” que têm grande probabilidade de encontrar erros
com o mínimo esforço e tempo. Na execução dos testes, o responsável pela
qualidade simula a execução de um programa para encontrar os erros existentes.
Os produtos podem ser testados através de duas categorias de casos de teste:
(1) os testes de caixa- preta, que são utilizados para verificar se as funções do
software estão operando corretamente como foi especificado e (2) os teste de caixabranca que verificam se a interação 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
13

JAVA) individualmente, garantindo que a mesma funciona corretamente, (2) teste de
integração que verifica a qualidade de um pacote de software completo, onde estão
integrados diversos componentes, (3) testes de validação que garantem que o
software satisfaz todos os requisitos funcionais e não-funcionais e (4) os testes de
sistema que verificam se todos os elementos (hardware, software, pessoal,...) se
adequam e trabalham corretamente.

3.1.4 Padrões de Qualidade

As empresas “desenvolvedoras de software” têm se preocupado com padrões
de avaliação dos processos de desenvolvimento de software, visando a qualidade
geral dos produtos desenvolvidos, através da melhoria dos processos utilizados.
Entre os principais padrões e/ou modelos de qualidade de software estão:

ISO 9001: “indica o controle da não-conformidade de um produto e
recomenda ações corretivas e preventivas”. [Tsu, 1997]

ISO 12207: norma que caracteriza todas as atividades que deverão ser
utilizadas pela equipe durante todo o ciclo de vida do software.

ISO 15504 (SPICE): modelo que avalia os processos baseando-se nas
características de modelos com objetivos semelhantes;

CMM (Capability Maturity Model): modelo utilizado para avaliar a
maturidade dos processos utilizados por organizações 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 relação com as pessoas diretamente
ligadas ao desenvolvimento de software.

SA – CMM: (Software Acquisiton Capability Maturity Model): modelo que
avalia a maturidade dos processos de aquisição e gerenciamento de
software terceirizado.

14

CMMi (Integration Capability Maturity Model): integração dos diversos
modelos CMM, com o objetivo de verificar tanto a maturidade dos
processos como a maturidade da organização.

3.2 Metodologias Ágeis – Agile Methodology

Os Desenvolvedores de software utilizam as Metodologias de Desenvolvimento
de Software há muitos anos. A utilização dessas metodologias facilita o
desenvolvimento de Software e orienta a equipe sobre os papéis e atividades que
devem ser exercidas.
O desenvolvimento através das metodologias tradicionais possibilita o
desenvolvimento de software através de um processo detalhado com ênfase no
planejamento. Nesses processos pesados e longos são gastos muito tempo
planejando grande parte do processo. Quando houver mudanças, os processos
pesados procuram resistir a essas mudanças. Quanto mais o sistema cresce, mais
difícil torna-se incluir novas funcionalidades e mudanças no sistema.
Algumas pessoas costumam dizer que o grande problema que compromete os
Projetos de Software é que os requisitos mudam constantemente. Porém, a
mudança é a norma para garantir um produto com qualidade e que satisfaça as
necessidades do cliente. Os desenvolvedores de software precisam aceitar as
mudanças como um aspecto positivo de renovação do sistema. Nas metodologias
tradicionais as mudanças nem sempre são bem vindas e/ou aplicadas, e os fatores
que implicam essa apreensão é o grande número de documentos que precisam ser
formulados e consultados, e a falta de práticas que garantam a qualidade do
software. As metodologias tradicionais muitas vezes não 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 têm
aparecido nos últimos anos, como uma mudança de paradigma de métodos de
desenvolvimento de software. Essas metodologias trazem uma nova forma de
construir software com mudança de diversos conceitos.
15

Essas metodologias são conhecidas como Metodologias Ágeis e apareceram
para “enfrentar” a burocracia das metodologias tradicionais, que muitas vezes se
tornava inútil, isso porque as metodologias ágeis são pouco orientadas a
documentação, e sim a codificação e a equipe do projeto. Para as metodologias
ágeis, a comunicação é fundamental, contrariando a quantidade exagerada de
documentação que muitas vezes é produzida nas metodologias tradicionais.
As metodologias ágeis são identificadas como um meio termo entre nenhum
processo e processos pesados de desenvolvimento de software.
A adaptação é um desafio e uma característica forte nas metodologias ágeis
que muitas vezes são conhecidas como “Processos Adaptativos” ou Lightweight
Methodologies.
Os requisitos mudam bastante e é preciso adaptar essas mudanças ao projeto
para que o cliente receba o produto como foi requisitado, obedecendo ao prazo de
entrega e custo determinados. A característica de adaptabilidade provê aos
desenvolvedores liberdade para realizar mudanças sempre que necessário.
Por serem processos ágeis, adaptativos, o cliente acompanha todas as
iterações de perto, verificando se as mudanças requisitadas por ele foram aplicadas
e verificando o progresso do projeto.
No desenvolvimento iterativo, são produzidas diversas versões, sendo que
cada versão possui um conjunto de funcionalidades que são integradas e testadas
como uma versão final. A cada versão entregue, o cliente descobre mais rápido
novas mudanças para o sistema, tornando-se mais fácil implementá-las.
Uma característica das metodologias tradicionais, é que elas se preocupam em
congelar

os

requisitos.

Os

requisitos

devem

ser

totalmente

identificados

anteriormente à codificação do sistema. Algumas equipes de projeto não aceitam
modificações nos requisitos, e o planejamento é seguido rigorosamente. Porém essa
postura dificulta a construção de um sistema com todas as características que foram
requisitadas pelo cliente.
O custo de um projeto é um fator que também possui muitas diferenças em
metodologias ágeis. Em projetos que utilizam as metodologias tradicionais, os
clientes costumam pagar um preço fixo pelo sistema, pois os requisitos são estáveis.
Em projetos que utilizam as Metodologias Ágeis, os requisitos podem mudar
bastante, e portanto o cliente não pode pagar um preço fixo. Para isso o cliente deve
ter um controle do processo de desenvolvimento em cada iteração. O cliente
16

conhece mais rápido como o sistema funciona na realidade, com isso as mudanças
são descobertas mais rápido e portanto o preço 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
iteração o planejamento é refeito. As não-conformidades são descobertas à tempo e
a inclusão de novas funcionalidades pode ser realizada facilmente. Por isso as
iterações devem ser pequenas, verificando as variações e oportunidades para
elaborar o produto adequado.
A equipe de projeto em metodologias ágeis não 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 existência de novas
mudanças. Para isso necessita-se de pessoas confiáveis, que aceitam mudanças e
com conhecimento suficiente para liderar e trabalhar com as Metodologias Ágeis.
O importante para as metodologias ágeis é prover ao cliente “valor de negócio”.
Para o cliente, “valor de negócio” 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, não
atendem a um mercado em constante mudança.
Metodologias ágeis provêem um conjunto simples de regras, encorajando a
criatividade e produzindo melhores resultados que impondo regras complexas e
rígidas.
O interesse em utilizar metodologias ágeis é não querer voltar ao passado,
onde não existiam regras para desenvolver software e sim utilizar somente regras e
práticas 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
17

eficiente. Em março de 1996 Beck trabalhou no projeto “Chrysler Comprehensive
Compensation”, C3, da DaimlerChrysler, onde começou a utilizar novos conceitos de
desenvolvimento de software, que originaram a XP.
É uma metodologia ágil de desenvolvimento de software que trabalha criando
uma constante comunicação entre programadores e clientes, assumindo que os
requisitos vão mudar muitas vezes, priorizando funcionalidades de acordo com o
valor de negócio, de forma simples, entregando valores freqüentemente e testando o
sistema exaustivamente durante todo o desenvolvimento.
XP é uma metodologia leve, eficiente, de baixo risco, flexível e divertida que
possui poucas regras e práticas que são fáceis de seguir.
As metodologias tradicionais de desenvolvimento de software, também
conhecidas como processos pesados de desenvolvimento, possuem regras
complexas, difíceis de serem seguidas, procedimentos complicados e uma grande
quantidade de documentação a ser elaborada e consultada. Quando os
programadores ignoram as suas regras, provavelmente não as aceitam mais. A
utilização de metodologias ágeis de desenvolvimento de software encoraja os
programadores a seguir uma metodologia obedecendo todas as suas regras.
A XP não voltou ao passado quando não haviam regras para se desenvolver
software e também não ignorou as regras e práticas das metodologias tradicionais,
simplesmente as simplificou, tornando-as mais fáceis de se utilizar e entender,
visando produzir software com qualidade.
As mudanças no projeto são freqüentes. As especificações são alteradas
freqüentemente em todas as etapas do processo de desenvolvimento. Nas
metodologias tradicionais os programadores têm dificuldade em aceitar as
mudanças com o receio de que os produtos prontos deixem de funcionar devido as
mudanças que foram aplicadas, ou o produto final não seja igual ao que foi
requisitado pelo cliente. Essas inconformidades acontecem devido a não utilização
dos testes e práticas de qualidade e/ou da entrega tardia de produtos do software.
Na XP o cliente deve perceber a coragem dos programadores para realizar
modificações no software sempre que necessárias. Para isso os programadores se
preocupam em obter feedback do cliente e do sistema o mais cedo possível. É
preciso que os produtos do software sejam entregues com freqüência e não de uma
só vez. Quanto mais cedo o feedback for obtido mais fácil será implementar novas
funcionalidades ou modificações no sistema.
18

Entre as principais características da XP que a caracterizam como uma
metodologia ágil e de sucesso estão (1) a constante e pacífica comunicação entre
programadores e clientes, (2) a elaboração 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 tão cedo quanto possível e (5) a aceitação as mudanças.
Na Fig1. percebe-se que qualquer prática da XP não tem valor sozinha (com
uma possível exceção dos Testes). Todas as práticas necessitam uma das outras
para estarem balanceadas. [Bec, 2000]

Fig. 1 – Práticas XP [Bec, 2000]

A XP vem crescendo devido o alto custo gerado pela utilização das
metodologias tradicionais e o fracasso da maioria dos projetos de desenvolvimento
de software.

3.3.1 Valores da XP

A XP possui valores (princípios) 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 negócio. Os valores da XP são

19

fundamentais para que seja possível atingir todos os objetivos do Projeto. Tais
valores devem ser respeitados e seguidos por todos os membros da equipe,
inclusive o cliente. Das quatro dimensões da XP, uma poderá sempre melhorar um
projeto de software. [Don, 2003]

3.3.1.1 Simplicidade

Simplicidade é um dos princípios da XP que facilita o desenvolvimento de
software em projetos que utilizam a XP, melhora a compreensão da equipe de
desenvolvimento em relação aos produtos que estão sendo codificados e aumenta
as chances de obter um produto com melhor qualidade.
Pode-se caracterizar o princípio da Simplicidade como um conjunto de
precauções ou atividades que devem ser alertadas ou aplicadas durante o
desenvolvimento do software. O principal objetivo de produzir software com
simplicidade é evitar o desnecessário e produzir somente o necessário e na hora
certa. A criação de código sem valor para o cliente, em um determinado momento do
projeto pode aumentar as chances de produção de software sem qualidade.
Deve ser evitada a duplicação de funcionalidade, a adivinhação de
funcionalidades futuras, a criação de muitas entidades e operações (e.g., classes e
métodos) e a codificação complicada, dificultando o entendimento pelos outros
desenvolvedores.
Código simples tem menor chance de quebrar, principalmente em projetos que
mudam constantemente, ou seja, em projetos XP. Na existência de mudanças é
mais fácil implementá-las quando se trata de um código simples, fácil de trabalhar e
entender.
É melhor fazer uma coisa simples hoje e pagar um pouco mais amanhã para
mudá-la se necessário, ao invés de fazer uma coisa mais complicada hoje que
nunca será usada. [Bec, 2000]
A simplicidade tem relação com outros valores da XP. Simplicidade e
Comunicação melhoram o desenvolvimento do projeto, uma vez que quanto melhor
a comunicação entre os membros da equipe, mais fácil será implementar um
software de forma mais simples, evitando problemas futuros.
20

Algumas práticas da XP também estão relacionadas com a Simplicidade. Na
prática Collective Ownership os desenvolvedores precisam entender o código
facilmente para poder trabalhar com o mesmo, uma vez que nenhum programador é
proprietário dos códigos. Na prática de Testes, para que a criação dos testes seja
correta e eficaz é necessário um design simples, fácil de entender. A prática de
Testes e o Desenvolvimento Dirigido por Testes (TDD) são importantes e facilitam a
criação de código simples. No Refactoring o código é modificado, não excluindo as
suas funcionalidades, seu objetivo, visando simplificar o código porém garantindo
através dos testes que não existem “quebras.”

3.3.1.2 Comunicação

A Comunicação é outro valor importante para a XP. A importância que a XP dá
a interação entre os membros da equipe do projeto e o cliente, faz necessário que
exista uma “boa prática” que auxilie o desenvolvimento do Projeto.
A constante, fácil e pacífica comunicação entre os membros da equipe facilita a
descoberta de novos requisitos, auxilia as atividades de implementação, aumenta as
chances de propagação de conhecimento e provê conforto e diversão a equipe,
visando o bom andamento do projeto.
Entre os meios existentes de comunicação, o que mais interessa a projetos XP
é a comunicação face à face. A utilização de documentos formais, e-mails,
telefonemas são viáveis, mas a presença real dos envolvidos em um único ambiente
traz mais benefícios ao projeto e entendimento sobre o mesmo. Esta escolha reduz
a elaboração e consulta de inúmeros documentos que muitas vezes são difíceis de
entender ou são elaborados mas não utilizados, e também as chances de não
entendimento entre as pessoas e delas em relação aos requisitos do projeto.
A Comunicação quando combinada com os outros valores da XP facilita ainda
mais o desenvolvimento do projeto. Quando na necessidade de obter rápido
feedback, a boa comunicação entre a equipe do projeto e o cliente é fundamental
para a realização do mesmo.
Em relação as práticas da XP, a comunicação é explorada em práticas como
Pair Programming, onde os programadores precisam se comunicar para que um
21

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 elaboração de produtos do software podem ser
garantidos e explicitados através de diversas práticas e valores da XP e não 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 obtenção do feedback deve ser constante e deve
ser obtido tanto do cliente como do sistema.
Pequenas partes do software devem ser desenvolvidas e após cada
desenvolvimento o feedback deve ser obtido, garantindo o status de aceitação do
cliente em relação ao produto gerado, garantindo que o produto está em
conformidade com os requisitos e diminuindo os riscos de elaboração de um
software sem valor para o cliente.
Obter feedback constantemente facilita a descoberta de novas funcionalidades
ou mudanças mais cedo e assim a implementação das mesmas também se torna
mais fácil.
Feedback está relacionado a outros valores da XP, entre eles Comunicação e
Coragem. Uma boa comunicação 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 através de práticas que verifiquem se um serviço foi
implementado corretamente, o programador tem mais coragem para implementar
todas as mudanças que são necessárias.
Feedback também se relaciona com algumas práticas da XP. Na prática on-Site
Customer o cliente está presente no mesmo local que a equipe de projeto e portanto
é mais fácil obter feedback sobre os produtos elaborados. Na prática Testing é
possível obter feedback do sistema através da aplicação de testes freqüentes.
Obtendo rápido feedback o desenvolvimento do sistema começa mais cedo. O
programador tem a garantia de que se houver alguma não-conformidade, esta será
encontrada o mais rápido possível, tanto pelo cliente como pelo sistema. Assim,

22

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 produção de
software com qualidade.
Coragem é necessária nas horas em que a equipe precisa se comunicar,
principalmente quando as decisões não são agradáveis mas precisam ser tomadas.
Coragem na hora de desenvolver com simplicidade, mesmo que o programador não
possa mostrar todo o seu conhecimento, desenvolvendo apenas o que tem valor
para o cliente. Coragem para obter feedback constante, realizar todas as mudanças
necessárias, simplificar o sistema sempre que possível.

3.3.2 Práticas da XP

3.3.2.1 The Planning Game

Tanto em projetos XP como em projetos que utilizam metodologias tradicionais
de desenvolvimento de software é necessário que existam atividades para a
realização do planejamento do projeto. O Planejamento é importante para que
algumas variáveis e decisões sejam explicitadas ajudando a equipe a entender o
que precisa ser feito e como deve ser feito.
As atividades de planejamento em projetos XP são exercidas por dois grupos
de pessoas. O pessoal de negócio e o pessoal técnico. Porém algumas atividades
de negócio dependem de atividades técnicas de planejamento.

23

Entre as atividades exercidas pelo pessoal de negócio, estão a definição (1) do
escopo do projeto,

(2) prioridades e (3) composição e datas das versões de

produtos. Nas atividades realizadas pelo pessoal técnico estão (1) o estudo das
estimativas do projeto, (2) identificação das conseqüências e impactos técnicos e
financeiros, (3) o estudo e definição de como será o processo de desenvolvimento e
(4) a definição de um cronograma detalhado. É Identificado o tamanho do projeto e
em quanto tempo será realizado.
O planejamento não deve durar meses, mas é preciso um planejamento mínimo
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 também
sofrerá diversas mudanças. Devido ao relacionamento existente entre as práticas da
XP, é possível que as atividades de planejamento sejam suportadas por outras
práticas quando temos uma situação negativa. Com a realização de pequenas
versões (Small releases) as não conformidades do planejamento têm um impacto
muito menor no projeto. Com a presença do cliente (On-site customer) pode-se obter
feedback mais rápido sobre o planejamento elaborado e não-conformidades
existentes.
Você pode começar a desenvolver com um plano simples e continuamente
refiná-lo ao longo do projeto. [Bec, 2000]

3.3.2.2 Small Releases

“Toda versão de um produto do software deve ser a menor possível, contendo
os requisitos de negócio mais valiosos.” [Bec, 2000]

As releases (versões de entrega) são planejadas e devem ser pequenas, mas
principalmente ter valor de negócio significativo. Uma release implementada pela
metade não é uma release pequena, e sim uma release incompleta, sem significado.
Uma release não pode ser liberada enquanto não estiver completamente acabada.
[Ast, 2002]
Small releases tem suporte de algumas práticas XP. Com small releases é
possível planejar (The planning Game) o suficiente para uma versão de um produto
24

do software em menos tempo. Após a implementação da release, ela é testada
(Testing) e integrada (Contínuos Integration), fornecendo rápido feedback em
relação aos requisitos implementados. O design pode ser o mais simples (Simple
design), representando apenas os serviços necessários.
Com small releases algumas “variáveis” do projeto podem ser modificadas ao
longo do desenvolvimento, como escopo, datas de entrega, prioridades.

3.3.2.3 Metaphor

As metáforas são utilizadas pela equipe do projeto para ter um entendimento
comum do contexto do sistema. As metáforas ajudam cada membro do projeto a
entender os elementos básicos e suas relações. Ao longo do desenvolvimento do
projeto, a equipe encontrará nova inspiração através da compreensão da metáfora
escolhida para o projeto. [Bec, 2000]
A utilização de metáforas evita que os membros da equipe tenham diferentes
visões sobre o que deve ser implementado, e aumenta a produtividade da equipe,
uma vez que a metáfora definida é compreendida e utilizada para facilitar o
desenvolvimento. Porém a escolha de uma metáfora deve ser um processo
cauteloso, uma vez que muitos membros da equipe podem não aproveitar o seu
significado, o que dificultaria o desenvolvimento do projeto.
A idéia é que cliente e desenvolvedores tenham uma mesma visão do sistema
e sejam capazes de falar sobre o sistema utilizando uma mesma linguagem. [Hig,
2002]
O uso de metáforas está relacionado a alguns valores da XP. É possível obter
rápido feedback e fácil comunicação entre os membros da equipe se as metáforas
foram aceitas e estão sendo utilizadas pelos membros da equipe para facilitar o
desenvolvimento do projeto.
Entre as práticas da XP que fazem uso da metáfora do sistema estão o
Refactoring, que através da metáfora, é mais fácil realizá-lo para refinar o sistema; o
Pair Programming, onde um par de programadores irá desenvolver mais rápido e
fácil se apoiados em uma metáfora do sistema; e o Simple Design, onde os

25

membros da equipe desenvolvem com simplicidade quando utilizam a metáfora
escolhida e entendem através 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, não
tem lógica duplicada, demonstra a intenção dos programadores e tem o menor
número possível de classes e métodos. [Bec, 2000]
Elaborar um design simples é implementar o que é estritamente necessário e
somente no momento necessário. Um design simples deve conter somente as
informações necessárias para que o produto esteja em conformidade com o que foi
requisitado.
Simple Design tem um vínculo forte com outras práticas XP. Mantendo um
design simples, o Refactoring

torna-se ainda mais fácil. O Pair Programming

garante que o design implementado realmente está sendo o mais simples possível.
As Small Releases devem possuir um design simples com somente as
funcionalidades necessárias.
Simple Design e Testing possuem uma relação ainda maior. A criação dos
códigos de teste antecipadamente ao código de design, garante que no código de
design vão existir somente as funcionalidade necessárias (aquelas que foram
implementadas no código de teste), obtendo um design simples, com maior
qualidade e desenvolvendo no tempo estimado, já que funcionalidades futuras não
são implementadas e os testes provêem feedback em relação as nãoconformidades. Neste momento pode-se notar a importância e benefícios do
Desenvolvimento Dirigido por Testes (TDD).

26

3.3.2.5 Testing

A prática de testes – Testing – é a prática XP mais importante nesse trabalho,
devido a sua forte relação com a qualidade dos produtos codificados e com o TDD.
Além disso, a prática de testes é tratada como a “prática chave” da XP. [Hig, 2002]
A prática de testes é útil aos programadores em qualquer contexto de
desenvolvimento, e junto com o TDD são um ótimo ponto de partida para qualquer
programador que deseja torna-se um usuário XP. [Adaption]
Toda funcionalidade do sistema precisa ter testes automatizados. Os
programadores são responsáveis por elaborar os testes unitários, que testam
pequenas partes do software, enquanto o cliente é responsável pelos testes de
aceitação (teste funcionais) que são criados para validar as funcionalidades.
As metodologias tradicionais possuem práticas que suportam atividades para
certificar que um produto codificado tem qualidade e atende aos requisitos do
cliente. Porém, as práticas muitas vezes não são levadas a sério, assim como a
metodologia utilizada, ou são aplicadas após a integração do produto ao sistema, o
que torna a fase de correção bem mais difícil. O tempo gasto na correção de nãoconformidades é preocupante, mas o tempo gasto depurando o código geralmente é
bem maior e pode prejudicar o andamento do projeto.
O TDD, por ser uma metodologia de desenvolvimento utilizada na prática de
testes, possui as características da prática de testes da XP e em muitas bibliografias
o TDD é caracterizado como sendo uma das práticas da XP. Por esse motivo as
características adicionais e o funcionamento da prática de testes será descrito no
capítulo referente ao TDD. Neste momento vale ressaltar que a elaboração e
aplicação de testes devem ser exaustivas. Através dos testes programadores e
cliente obtém rápido feedback sobre os produtos gerados. Os testes precisam ser
elaborados, ou seja, codificados antes da elaboração do código de design. A
elaboração do código de teste antes da elaboração do código de design é vantajosa,
uma vez que criando o código de teste descobrimos quais são as verdadeiras
funcionalidades de uma parte do sistema. Se a cada alteração no código o teste for
executado, o programador tem total confiança de que o código está funcionando
corretamente.

27

A prática de Testes também tem relação com as outras práticas da XP. Com
um design simples (Simple Design) a elaboração dos códigos de teste se torna muito
mais fácil. Com o Pair Programming ambos os programadores podem incrementar
cada vez mais os testes. A integração contínua (Continuos Integration) dos produtos
é mais fácil e confiante uma vez que um produto só é integrado quando todos os
testes passarem 100%. Como os códigos não possuem proprietários (Collective
Ownership) é mais fácil entender o objetivo de um programa/código analisando pelo
código de teste. O refinamento do código através do Refactoring é feito sempre que
necessário e com coragem pelos desenvolvedores, pois os mesmos podem certificar
que as alterações não comprometeram o que estava funcionando corretamente,
através dos testes. O cliente acompanha o desenvolvimento (On-Site Customer) e
verifica que o projeto está em bom andamento através dos testes.

3.3.2.6 Refactoring

“Refactoring é o processo de alterar um sistema de software de tal forma que
ele não altere o comportamento externo do código e melhore a sua estrutura interna.
Essa é uma forma disciplinada de limpar o código que minimiza as chances de
introdução de bugs”. [Fow, 1999]

O Refactoring é um refinamento do código com o objetivo de torná-lo mais
simples porém sem excluir qualquer funcionalidade. O Refactoring é uma atividade
que deve ser executada a todo o momento, antes dos testes e de qualquer alteração
no código. Algumas vezes você codifica mais que o necessário para que uma
funcionalidade funcione corretamente. [Bec, 2000]
O Refactoring aumenta a qualidade do código, evitando redundâncias,
complexidade e tornando o código mais fácil de entender e modificar.
Através da propriedade coletiva de código (Collective Ownership) os
programadores podem fazer o Refactoring sempre que acharem necessário. Com
um design simples (Simple Design) é mais fácil fazer o Refactoring. Através dos
testes (Testing) é possível verificar se o Refactoring não comprometeu o correto

28

funcionamento do código, e com isso os programadores se sentem mais
encorajados para realizá-lo.

3.3.2.7 Pair Programming

Na XP, toda linha de código é 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
método implementado em uma classe. O “co-piloto” ajuda o “piloto” oferecendo
idéias e se achar necessário podem trocar de papéis.
A programação em pares muda constantemente, ou seja, um programador não
faz par com outro programador o dia todo. Quando um programador tem dificuldade
em um determinado domínio, o mesmo deve programar com um programador que
tenha mais experiência naquele domínio.
Respeitando a prática de 40 horas semanais (40 - Hour Week) os
programadores estarão descansados e dispostos para codificar em pares
produtivamente. A metáfora (Metaphor) utilizada ajuda os pares a terem uma mesma
visão 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 prática de propriedade coletiva (Collective Ownership) é utilizada na XP para
que qualquer pessoa possa alterar um código se achar necessário. Não é
necessário que um programador requisite uma permissão para alterar um código,
uma vez que não existem proprietários de código. Porém é necessária a utilização
de uma ferramenta de controle de código fonte (repositório).
29

Permitindo que muitas pessoas trabalhem com o código, faz com que cada
pessoa conheça um pouco de todo o sistema.
Como as práticas da XP suportam uma as outras, com a propriedade coletiva
não é diferente. É necessário

integrar o código continuamente (Continuos

Integration), para evitar problemas de versionamento. Qualquer um pode alterar os
códigos, uma vez que os Testes vão verificar se as mudanças não comprometeram
o correto funcionamento.

3.3.2.9 Continuous Integration

Na XP, a integração contínua é uma prática utilizada para facilitar a
manipulação e entrega dos produtos do software (principalmente as alterações),
evitar problemas de incompatibilidade, e verificar se os produtos que estão sendo
integrados não possuem falhas.
A freqüência com que a integração deve ser realizada é de no mínimo uma vez
ao dia, porém o ideal é que a integração seja realizada toda vez que uma tarefa for
concluída, e quanto mais vezes, melhor. Quanto mais integração, o produto sofrerá
menos quebras diminuindo o re-trabalho. É

indispensável que todos os

desenvolvedores trabalhem com a última versão do produto.
A integração contínua é uma prática que está relacionada com outras práticas
XP. Trabalhando com Small Releases, as funcionalidades implementadas são
menores e as atividades de integração se tornam mais fáceis. Os Testes são
utilizados para verificar se um produto está realmente pronto para ser integrado aos
demais, sendo necessário que todos os testes passem 100% antes da integração do
código, evitando o depósito de códigos com erro. Na propriedade coletiva (Collective
Ownership) é necessária a utilização de um repositório de código fonte para que os
desenvolvedores possam utilizar as versões finais dos produtos do software e
implementar as modificações necessárias, depositando/integrando o código ao
repositório.

30

As atividades de integração são mais facilmente realizadas quando são
utilizadas ferramentas automáticas para a “construção” do sistema (ANT[1]) e para a
realização dos testes (JUnit[2]).

3.3.2.10 40 – Hour Week

A prática de “40 horas semanais” é uma prática que aconselha a equipe de
projeto a não ultrapassar os seus limites de trabalho semanal. Os integrantes da
equipe são diferentes, produzem e têm rendimentos diferentes.
É importante que a equipe planeje corretamente para desenvolver o projeto no
tempo esperado, respeitando o limite dos desenvolvedores. Trabalhar por hora extra
freqüentemente, é uma prática desaconselhável em projetos XP. No começo do dia,
o desenvolvedor precisa estar bem, fisicamente e emocionalmente, para poder
exercer todas as suas tarefas diárias da melhor forma possível.
A prática 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 codificação é mais rápida e
segura.

3.3.2.11 On-site Customer

“A XP insiste em fazer um cliente real trabalhar diretamente no projeto.”
[Ast, 2002]

[1] ANT – Produto do Projeto Apache
[2] JUnit – framework para criação de testes automatizados;
criado por Kent Beck e Erich Gamma

31

Em projetos XP é importante que exista uma pessoa (Cliente), que represente o
usuário do sistema, para estar junto (fisicamente se possível) com a equipe de
projeto, pronta para resolver problemas referentes ao mesmo, solucionar dúvidas e
tomar decisões referentes a prioridades, escopo e risco.
A presença do Cliente junto a equipe de projeto traz benefícios e qualidade ao
mesmo. Entre os benefícios mais importantes, está o rápido e constante feedback
que o “cliente real” pode fornecer a equipe de projeto.

3.3.2.12 Coding Standards

Em um projeto XP, a prática Coding Standards é utilizada para definir um
padrão de codificação (comum no mercado) que deve ser adotado por toda a
equipe, buscando aumentar a produtividade e qualidade dos produtos gerados. A
utilização de diferentes práticas de codificação, pode prejudicar o entendimento dos
desenvolvedores em relação aos produtos codificados e prejudicar a realização de
algumas práticas XP.
A utilização de uma codificação padrão facilita a programação em pares (Pair
Programming), o Refactoring e a propriedade coletiva (Collective Ownership).

3.3.3 Os papéis na XP

Assim como nas metodologias tradicionais de desenvolvimento de software, na
XP os papéis desempenhados pelos integrantes da equipe do projeto são
importantes para que o projeto seja desenvolvido corretamente e com qualidade,
orientando cada um dos integrantes em relação as suas responsabilidades (alguns
integrantes têm mais de um papel) e mantendo um ambiente de desenvolvimento
comunicativo e agradável.
A participação do cliente no desenvolvimento do projeto é essencial para a XP,
mas ainda assim podemos dividir a equipe do projeto em duas equipes essenciais.
32

3.3.3.1 A equipe do cliente
A equipe do cliente representa o “usuário” do sistema e é responsável pela
caracterização dos requisitos e elaboração dos testes de aceitação. Entre os papéis
existentes na equipe do cliente estão:

Contadores de histórias: pessoas responsáveis pela elaboração das user
stories (representação breve dos requisitos do sistema, necessidades do
usuário).

Examinador/Aceitante: pessoas responsáveis pela realização dos testes
de aceitação, 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 tecnológica
que será utilizada para desenvolver o sistema e é responsável pelas estimativas
técnicas e o desenvolvimento do projeto. Entre os papéis existentes na equipe de
desenvolvimento estão:

Técnico: pessoa experiente, com a responsabilidade de guiar a equipe
quando necessário e tornar o desenvolvimento mais fácil.

Acompanhador/Tracker: pessoa responsável 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 necessário. [Ast, 2002]

Programador: o programador XP, responsável pela codificação, trabalha
de forma simples, comunicando-se constantemente com os membros da
33

equipe. Constrói os testes unitários, programa em pares e faz o
Refactoring.

“Com muito pouco processos é preciso ter pessoas extraordinárias para fazer
coisas ordinárias; com processos demais, nem mesmo as pessoas extraordinárias
conseguem fazer coisas extraordinárias.” [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 através
da aplicação de práticas e regras específicas de cada metodologia. Anteriormente,
já foi citado o problema dessas metodologias tradicionais
desenvolvedores em relação as suas práticas.

e a rejeição dos

Decorrente desse problema, as

metodologias ágeis de desenvolvimento de software estão cada vez mais ganhando
adeptos e espaço 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 práticas
simples, fáceis de serem seguidas e que realmente contribuem para o
desenvolvimento de um projeto de software (quando são seguidas corretamente).
As práticas da XP possuem um alto grau de dependência, suportando uma as
outras, e para que um projeto XP obtenha os benefícios da aplicação dessa
metodologia, é preciso que todas as práticas sejam aplicadas simultaneamente (com
exceção da prática de testes).
O Desenvolvimento Dirigido por Testes (TDD – Test Driven Development) é
uma metodologia de desenvolvimento utilizada em projetos de software através da

34

prática de Testes da XP, com o objetivo de facilitar o desenvolvimento
(principalmente a codificação) e garantir qualidade aos produtos gerados.
Em algumas bibliografias [Adaption], a prática de testes da XP é caracterizada
como o próprio TDD, e com isso percebe-se que a XP se “apropriou” do TDD e seus
benefícios. As práticas 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 técnica de Análise e Design, e
não uma técnica de Testes do processo de Engenharia de Software, pois a sua
grande contribuição está na percepção de “o que deve ser feito e como deve ser
feito”.
O TDD é uma descoberta recente e vem ganhando cada vez mais atenção dos
desenvolvedores de software devido aos seus benefícios em relação a qualidade do
software e produtividade no desenvolvimento.

3.4.1 Como funciona o TDD?

“O grande propósito do TDD é produzir testes automatizados para produzir
código, e através desse processo guiar o design e a programação.” [Adaption]

O TDD é uma metodologia de desenvolvimento que consiste na realização de
algumas atividades repetitivas (realizadas durante a programação do sistema) para a
codificação de produtos do software produtivamente e qualificadamente.
Testes unitários e Testes Funcionais são diferentes tipos de teste que verificam
diferentes visões do sistema. Em [Can, 2001], Jeff Canna utilizou uma metáfora
para caracterizar testes unitários e testes funcionais, imaginando-se a construção de
uma casa. Os testes unitários seriam semelhantes a visita de um inspetor geral na
casa, para verificar se as diversas partes internas que compõe a casa (fundação,
parte elétrica, parte hidráulica,...) irão funcionar corretamente, enquanto os testes

35

funcionais seriam uma vistoria dos futuros usuários da casa, verificando como seria
morar nessa casa.
Testes unitários são elaborados pelos programadores para verificar se todos os
serviços do sistema (e.g., todos os métodos, de todas as classes) estão operando
corretamente. Testes funcionais são elaborados pelo cliente (algumas vezes com a
ajuda de uma pessoa experiente) para verificar que o sistema faz o esperado.
As atividades que compõe o TDD são atividades que facilitam a elaboração da
análise, design e codificação dos produtos do software, e que encorajam os
programadores a simplificar e realizar todas as mudanças no sistema quando
necessário.
As principais atividades do TDD são: (1) a elaboração de testes unitários
automatizados, que representem uma pequena funcionalidade (e.g., um método de
uma classe), (2) a elaboração do código de design referente ao código de teste e (3)
o refactoring. Essas atividades são realizadas até que toda a funcionalidade seja
implementada, todos os testes passem 100% e o design seja o mais simples
possível. Nenhum código de design pode ser produzido antes que exista um código
de teste referente ao mesmo, e o não cumprimento dessa regra pode comprometer a
qualidade dos produtos do software e a utilização da metodologia TDD.
A elaboração de códigos de teste e códigos de design é alternada no TDD.
Com isso, os programadores não se cansam de escrever códigos de teste, pois eles
facilitam a elaboração dos códigos de design e tornam esse processo mais divertido.
A elaboração do código de teste anteriormente a elaboração do código de
design é um fator indispensável no TDD. Esta prática facilita o entendimento sobre o
que deve ser implementado e como deve ser implementado (análise e design). Além
disso,

a codificação terá o design mais simples possível, pois somente será

implementado o que foi explicitado no código de teste.
Na prática, quando o programador receber um novo serviço do sistema para ser
desenvolvido/codificado (em XP uma user story), o programador (1) elabora o código
de teste (testes unitários) para verificar as funcionalidades do código de design; (2)
após, o programador executa o código de teste para verificar o sucesso ou falha do
mesmo; (3) através do resultado da execução dos testes, o programador elabora o
código de design necessário, para que as falhas sejam corrigidas e o teste “passe”;
(4) o refactoring é realizado para que o código se torne mais simples; após o

36

refactoring os testes são executados novamente para verificar que as modificações
feitas não causaram nenhuma “quebra” e nem modificaram o comportamento.
No início da codificação, quando os testes forem executados, sempre ocorrerá
falhas/erros, pois a entidade (e.g., classe) e operações (e.g., métodos) que estão
sendo verificadas ainda não foram implementadas no código de design, portanto os
testes não os reconhece. Assim, descobrimos o que temos que implementar no
código de design e implementamos (e.g., quais métodos e em quais classes).
No TDD, assim como na XP, as mudanças são sempre “bem vindas”. É
importante que qualquer nova funcionalidade seja implementada quando necessária.
No TDD o código é testado antes e depois de qualquer modificação. Quando existir
algum erro, é possível voltar ao estado anterior.
Algumas práticas da XP têm bastante relação com o TDD e alguns “xispeiros”
dizem que a utilização do TDD é a “porta de entrada” para novos adeptos da XP,
pois a prática de Testes é a prática chave da XP e tem relação com as demais.
O Refactoring é uma prática XP diretamente ligada ao TDD, pois ele deve ser
realizado continuamente para garantir que o código tem o design mais simples
possível. Os testes são executados antes e após o refactoring. Pair Programming é
outra técnica da XP útil para o TDD, pois um desenvolvedor pode explicitar sobre
outras operações que deveriam constar no código de teste.
Outra questão importante no TDD, é “o que testar”? Tudo que possivelmente
possa “quebrar” deve ser testado. Todas as operações devem ser testadas, com a
exceção de métodos acessores (e.g., set(); e get();) e construtores simples.
“Se você tiver certeza que o seu código possivelmente não possui quebras, tem
um design perfeito, todos gostam da sua interface e é perfeitamente claro para
todos, então você não precisa testá-lo. Porém, SEMPRE existirá um erro em algum
código, você SEMPRE poderá melhorar o código, alguém SEMPRE faz perguntas
sobre como o código trabalha ou alguém SEMPRE reclama da sua interface”. [Ast,
2003]

37

3.4.2 Benefícios do TDD.

A utilização do TDD como metodologia de desenvolvimento provê diversos
benefícios para os projetos de software. Entre os principais benefícios estão:

Design mais simples, limitado: evita a implementação de serviços
futuros.

Melhor entendimento sobre o que deve ser desenvolvido.

Desenvolvimento rápido / produtividade.

Confiança: os testes dão confiança ao programador.

Coragem para realizar mudanças: qualquer alteração que gerar um
erro, logo será percebida.

Rápido feedback : após a implementação o programador verifica qual
é o resultado.

Programação mais divertida.

Menos depuração de código: os erros existentes são explícitos.

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 Importância de Ferramentas Automatizadas de Teste

No TDD a elaboração e a execução de Testes Unitários deve ser exaustiva, e
para que este processo seja o mais agradável e produtivo possível, é imprescindível
a utilização de ferramentas automatizadas de teste (e.i., frameworks de teste) que
auxiliem os programadores no desenvolvimento e acompanhamento dos testes.
A utilização de ferramentas de desenvolvimento e execução de testes é
extremamente necessária para que os objetivos do TDD sejam alcançados, e a não
utilização dessas ferramentas inviabiliza a utilização dessa metodologia.

38

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 metáfora utilizada por Willian Wake para
descrever o ciclo de desenvolvimento do TDD.

Luz Verde -

todos os testes passaram.

Luz amarela -

falha de compilação

Luz vermelha -

falha no teste

Para Willian, o ciclo de desenvolvimento consiste em:
1. Início (luz verde)
2. Escreva um código de teste.
3. Rode o teste; falha de compilação, a rotina ainda não foi definida. (luz
amarela)
4. Defina a nova rotina (assinatura).
5. Rode o teste novamente; erro, pois a rotina não tem funcionalidade. (luz
vermelha)
6. Forneça as operações para a rotina.
7. Rode o teste. Passou. (luz verde)
8. Comece o ciclo novamente.

Um framework padrão da linguagem JAVA para utilização no TDD é o JUnit,
que foi criado por Kent Beck (mesmo criador da XP) e Erich Gamma, e é um
framework opensource sob licença da IBM. Através do JUnit e da sua arquitetura é
possível a criação de conjuntos de testes unitários automatizados e o
acompanhamento da execução dos testes através de uma das suas interfaces de
apresentação.

[1] JUnit – framework para criação de testes unitários automatizados; [Bec, 2001]
[2] Cactus – framework para criar testes unitários em componentes J2EE [Cactus]
[3] HttpUnit – framework para criar testes funcionais para aplicações web [HttpUnit]
[4] JunitPerf – framework para criar testes de performance em Web sites. [JunitPerf]
39

Na criação dos testes são utilizados métodos 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.
Além da criação de testes unitários automatizados, o JUnit possibilita que o
programador adicione em uma única classe, diversos métodos de teste referentes a
classes diferentes.

3.5 Implementação de Casos de Teste

PROBLEMA: Elaborar uma aplicação para manipular o cadastro de algumas
disciplinas do 4º ano de Ciências da Computação, com os nomes dos respectivos
professores.
1º passo
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);
}
}
Fig. 2 - TestCadastro.Java
40

-

A classe de teste (TestCadastro) é implementada e é definido um conjunto
mínimo de operações (e.i., métodos) que devem ser testadas.

Fig. 3 – Compilando TestCadastro.Java

-

A classe TestCadastro é compilada e erros ocorrem pois a classe Cadastro
não foi identificada e precisa ser implementada.

public class Cadastro{
}
Fig. 4 - Cadastro.java

Fig. 5 – Compilando Cadastro.java

-

A classe Cadastro é implementada da forma mais simples possível e é
compilada com sucesso.

41

Fig. 6 – Compilando TestCadastro.java

A classe TestCadastro é compilada novamente e erros ocorrem, pois os

-

métodos que devem ser testados não foram identificados e portanto precisam
ser definidos.
public class Cadastro{
String prof;
public void cadastrar(String disciplina, String professor){
}
public String consultar(String disciplina){
return prof;
}
}
Fig. 7 - Cadastro.java

Fig. 8 – Compilando todas as classes

-

Os métodos da classe Cadastro são definidos da forma mais simples possível
e a classe Cadastro é compilada com sucesso.
42

-

A classe TestCadastro é compilada novamente, com sucesso.

Fig. 9 – Comando de execução do JUnit

-

O framework JUnit é executado utilizando a interface swingui.

Fig. 10 – Execução do JUnit

-

Os testes são executados e duas falhas ocorrem, pois os métodos não foram
implementados corretamente.

43

2º passo
import java.util.*;
public class Cadastro{
String prof;
Hashtable objHashtable = new Hashtable();
public void cadastrar(String disciplina, String professor){
objHashtable.put(disciplina, professor);
}
public String consultar(String disciplina){
prof = (String) objHashtable.get(disciplina);
return prof;
}
}
Fig. 11 - Cadastro.java

Fig. 12 – Compilando todas as classes e executando o JUnit

-

Os métodos da classe Cadastro são implementados corretamente e a classe
Cadastro e TestCadastro são compiladas com sucesso. O JUnit será
executado novamente.

44

Fig. 13 – Execução do JUnit

-

Os métodos foram testados novamente e passaram com sucesso, ou seja, as
operações cadastrar() e consultar() estão operando corretamente.

45

3º passo
import junit.framework.*;
public class TestCadastro extends TestCase{
String prof;
int tam;
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);
}
public void testTamanho(){
objCad.cadastrar("Sistemas Informacao","Joao Batista");
objCad.cadastrar("IA", "Andre");
objCad.cadastrar("BD", "Medina");
tam = objCad.tamanho();
assertEquals(3, tam);
}
}
Fig. 14 - TestCadastro.Java

-

Após os métodos, cadastrar() e consultar(), serem testados e verificados o
correto funcionamento dos mesmos, nova funcionalidade (testTamanho()) é
adicionada na classe de teste para que seja testada.

Fig. 15 – Compilando TestCadastro.java

46

-

A classe TestCadastro é compilada e ocorre um erro devido a não
identificação do método tamanho(); o método precisa ser definido na classe
Cadastro.

import java.util.*;
public class Cadastro{
String prof;
int tam;
Hashtable objHashtable = new Hashtable();
public void cadastrar(String disciplina, String professor){
objHashtable.put(disciplina, professor);
}
public String consultar(String disciplina){
prof = (String) objHashtable.get(disciplina);
return prof;
}
public int tamanho(){
return tam;
}
}
Fig. 16 - Cadastro.java

-

O método tamanho() é definido na classe Cadastro da forma mais simples
possível.

Fig. 17 – Compilando todas as classes e executando o JUnit

-

As classes Cadastro e TestCadastro após as alterações são compiladas com
sucesso e o JUnit é executado novamente.

47

Fig. 18 – Execução do JUnit

-

O JUnit foi executado novamente. Os testes testCadastrar e testConsultar
passaram com sucesso. O teste testTamanho gerou uma falha pois o método
tamanho() da classe Cadastro não foi implementado corretamente.

48

import java.util.*;
public class Cadastro{
String prof;
int tam;
Hashtable objHashtable = new Hashtable();
public void cadastrar(String disciplina, String professor){
objHashtable.put(disciplina, professor);
}
public String consultar(String disciplina){
prof = (String) objHashtable.get(disciplina);
return prof;
}
public int tamanho(){
tam = (int) objHashtable.size();
return tam;
}
}
Fig. 19 - Cadastro.java

Fig. 20 – Compilando todas as classes e executando o JUnit

-

Todas as classes foram compiladas com sucesso e o JUnit será executado
novamente.

49

Fig. 21 – Execução do JUnit

-

Todos os métodos passaram com sucesso.

50

4º passo
import junit.framework.*;
public class TestCadastro extends TestCase{
String prof;
int tam;
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);
}
public void testTamanho(){
objCad.cadastrar("Sistemas Informacao","Joao Batista");
objCad.cadastrar("IA", "Andre");
objCad.cadastrar("BD", "Medina");
tam = objCad.tamanho();
assertEquals(3, tam);
}
public void testRemover(){
objCad.cadastrar("Sistemas Informacao","Joao Batista");
objCad.remover("Sistemas Informacao");
tam = objCad.tamanho();
assertEquals(0, tam);
}
}

Fig. 22 - TestCadastro.java

-

Nova funcionalidade (testRemover()) foi adicionada na classe TestCadastro.

51

Fig. 23 – Compilando TestCadastro.java

-

A classe TestCadastro quando compilada gerou um erro pois o método
remover() não foi identificado na classe Cadastro.

import java.util.*;
public class Cadastro{
String prof;
int tam;
Hashtable objHashtable = new Hashtable();
public void cadastrar(String disciplina, String professor){
objHashtable.put(disciplina, professor);
}
public String consultar(String disciplina){
prof = (String) objHashtable.get(disciplina);
return prof;
}
public int tamanho(){
tam = (int) objHashtable.size();
return tam;
}
public void remover(String disciplina){ }
}
Fig. 24 - Cadastro.Java

52

Fig. 25 - Compilando todas as classes e executando o JUnit

Fig. 26 – Execução do JUnit

-

O método remover foi definido na classe Cadastro da forma mais simples
possível. Todas as classes foram compiladas com sucesso. O JUnit foi
executado e verificou-se uma falha no método testRemover(), pois na classe
Cadastro o método remover() ainda não foi implementado corretamente.

53

import java.util.*;
public class Cadastro{
String prof;
int tam;
Hashtable objHashtable = new Hashtable();
public void cadastrar(String disciplina, String professor){
objHashtable.put(disciplina, professor);
}
public String consultar(String disciplina){
prof = (String) objHashtable.get(disciplina);
return prof;
}
public int tamanho(){
tam = (int) objHashtable.size();
return tam;
}
public void remover(String disciplina){
objHashtable.remove(disciplina);
}
}
Fig . 27 - Cadastro.java

-

O método remover() é implementado corretamente.

Fig. 28 – Compilando todas as classes e executando o JUnit

-

As classes compilaram com sucesso e o JUnit será executado mais uma vez.

54

Fig. 29 – Execução do JUnit

-

Através do JUnit podemos certificar que todos os métodos passaram 100% e
portanto os métodos da classe Cadastro estão operando corretamente.

55

3.6 Conclusão

A garantia da qualidade do software abrange avaliações dos produtos do
Software e do processo utilizado para desenvolvê-los. A utilização de uma
metodologia de desenvolvimento é necessária para que os riscos e nãoconformidades do projeto sejam minimizadas e um nível de qualidade satisfatório
seja garantido.
A XP é uma das diversas metodologias ágeis de desenvolvimento de software
que têm ganhado espaço na comunidade de Engenharia de Software. A XP possui
práticas simples e fáceis de serem seguidas, que melhoram o desenvolvimento do
projeto em diversos aspectos.
O Desenvolvimento Dirigido por Testes (TDD) é uma metodologia de
desenvolvimento de software, utilizada através da prática de Testes da XP. O TDD
tem como objetivo criar conjuntos de testes automatizados para (1) facilitar o
desenvolvimento (produtividade), (2) produzir código com simplicidade e (3) garantir
qualidade aos produtos codificados. Além disso, a maior colaboração do TDD é que
através dele o desenvolvedor compreende melhor o que precisa ser feito e como
deve ser feito.
As práticas da XP, acrescentados os conceitos do TDD e ferramentas para
criação de testes automatizados, facilitam o desenvolvimento do software, dando
confiança aos desenvolvedores, diminuindo a necessidade de depuração de código
e aumentando ainda mais as chances de garantir um software com a qualidade
desejada.

56

BIBLIOGRAFIA

[Ast, 2002] D. Astels, G. Miller, M. Novak. Extreme Programming – Guia Prático.
Campus. 2002
[Bec, 2000] Kent Beck. Extreme Programming Explained – Embrace Change.
Addison Wesley. 2000
[Fow, 1999] Martin Fowler, “Refactoring: Improving the Design of Existing Code”,
Addison Wesley Longman – 1999

[Hig, 2002] R. Hightower, N. Lesiecki. Java Tools for eXtreme Programming. Wiley,
2002.
[Pres, 2001] Roger S. Pressman – Engenharia de Software 5ª edição

[Tsu, 1997] Alfredo N. Tsukumo, Claudete M. Rego, Clenio F. Salviano, etalii.
Qualidade de Software: visões de produto e processo de software

SITES VISITADOS

[Adaption] Adaption Software (consulta feita em 06/2003)
http://www.adaptionsoft.com

[Ast, 2003] The Coad Letter: Test-Driven Development Edition - Dave Astels
http://bdn.borland.com/coadletter/testdrivendevelopment/ (consulta feita em 07/2003)

[Bec, 2001] Kent Beck. JUnit, Testing Resources for Extreme Programming .
http://www.junit.org (consulta feita em 04/2003 e 05/2003)
[Bec1, 2001] Aim, Fire – Kent Beck

57

http://www.aanpo.org/articles/articles/AimFire.pdf (consulta feita em 07/2003 e
08/2003)

[Cactus] The Apache Software Foundation - Jakarta Cactus
http://jakarta.apache.org/cactus/index.html

(consulta feita em 10/2003)

[Can, 2001 ] Testing, fun? Really? – Jeff Canna - (consulta feita em 31/10/2003)
http://www-106.ibm.com/developerworks/library/j-test.html

[Cun, 2001] Manifesto for Agile Software Development - Ward Cunningham - 2001
http://agilemanifesto.org/

(consulta feita em 06/2003)

[Don, 2003] J. Donovan Wells. Extreme Programming: A gentle introduction.
http://www.extremeprogramming.org

(consulta feita em 03/2003)

[Fow, 2003] Martin Fowler - “The New Methodology” - (consulta feita em 06/2003)
http://www.martinfowler.com/articles/newMethodology.html

[HttpUnit] Russell Gold - HttpUnit
http://www.httpunit.org/index.html

[Jef, 1999]
Resource.

(consulta feita em 10/2003)

Ronald E Jeffries. Xprogramming.com – an Extreme Programming
http://xprogramming.com/ (consulta feita em 04/2003 e 05/2003)

[JUnitPerf] Clarkware Consulting, Inc. - JUnitPerf
http://www.clarkware.com/software/JUnitPerf.html

(consulta feita em 10/2003)

[Obj, 2003] Object Mentor – Test Driven Development
http://www.objectmentor.com/writeUps/TestDrivenDevelopment
(consulta feita em 07/2003)

[Wue, 2001] Klaus Wuestefeld. Xispê
http://www.xispe.com.br

(consulta feita de 04/2003 a 06/2003)
58