Académique Documents
Professionnel Documents
Culture Documents
___________________________________
Aluna: Tatiana Costa Rodrigues
____________________________________
Prof. Orientador: Joo Batista Carneiro
Resumo
Qualidade de Software um requisito que preocupa a maioria das empresas de
desenvolvimento de software. Todavia, muitas empresas no se preocupam em
aplicar esforos para garantir que os produtos do software sejam gerados com
qualidade. Geralmente essas empresas no utilizam processos de desenvolvimento
de software ou usam processos ineficazes, que comprometem o cronograma do
projeto e conseqentemente a qualidade do software.
As Metodologias geis foram criadas para enfrentar a burocracia das metodologias
tradicionais e assim conquistar desenvolvedores de software que rejeitam as
metodologias tradicionais.
A Extreme Programming
atravs da prtica de testes da XP, e consiste em criar cdigos de teste para guiar o
desenvolvedor na criao dos cdigos de design, desenvolvendo com simplicidade,
confiana e qualidade.
Palavras-Chave
Software, Qualidade, Processos, SQA, Testes, Metodologias geis, XP, TDD,
Anlise, Design, Simplicidade, Confiana, Produtividade, JAVA, JUnit
Abstract
Software quality is a requirement that worries most of the software development
companies. Still, much companies dont care in apply efforts to certify that the
software products have been produced with quality. Usually, these companies dont
use software development process or do it in a non-effective process that
compromise the projects schedule and consequently the softwares quality.
The Agile Methodologies were created to confront with the bureaucracy of the
traditional methodologies and then to conquer softwares developers that reject the
traditional methodologies.
The Extreme Programming (XP) is a software development agile methodology that
has simple practices and worries in delivering to the customer software with quality.
The Test Driven Development (TDD) is a methodology directed through XP test
practice and consists in produce test-code to guide the developer in the production of
design- code, developing with simplicity, confidence and quality.
Keywords
Software, Quality, Process, SQA, Test, Agile Methodologies, XP, TDD, Analysis,
Design, Simplicity, Confidence, Productivity, JAVA, Junit
Lista de Figuras
Fig. 1 Prticas XP [Bec, 2000] _____________________________________________________ 19
Fig. 2 - TestCadastro.Java __________________________________________________________ 40
Fig. 3 Compilando TestCadastro.Java _______________________________________________ 41
Fig. 4 - Cadastro.java ______________________________________________________________ 41
Fig. 5 Compilando Cadastro.java ___________________________________________________ 41
Fig. 6 Compilando TestCadastro.java ________________________________________________ 42
Fig. 7 - Cadastro.java ______________________________________________________________ 42
Fig. 8 Compilando todas as classes _________________________________________________ 42
Fig. 9 Comando de execuo do JUnit _______________________________________________ 43
Fig. 10 Execuo do JUnit ________________________________________________________ 43
Fig. 11 - Cadastro.java _____________________________________________________________ 44
Fig. 12 Compilando todas as classes e executando o JUnit ______________________________ 44
Fig. 13 Execuo do JUnit ________________________________________________________ 45
Fig. 14 - TestCadastro.Java _________________________________________________________ 46
Fig. 15 Compilando TestCadastro.java _______________________________________________ 46
Fig. 16 - Cadastro.java _____________________________________________________________ 47
Fig. 17 Compilando todas as classes e executando o JUnit ______________________________ 47
Fig. 18 Execuo do JUnit ________________________________________________________ 48
Fig. 19 - Cadastro.java _____________________________________________________________ 49
Fig. 20 Compilando todas as classes e executando o JUnit ______________________________ 49
Fig. 21 Execuo do JUnit ________________________________________________________ 50
Fig. 22 - TestCadastro.java _________________________________________________________ 51
Fig. 23 Compilando TestCadastro.java _______________________________________________ 52
Fig. 24 - Cadastro.Java ____________________________________________________________ 52
Fig. 25 - Compilando todas as classes e executando o JUnit ______________________________ 53
Fig. 26 Execuo do JUnit ________________________________________________________ 53
Fig . 27 - Cadastro.java ____________________________________________________________ 54
Fig. 28 Compilando todas as classes e executando o JUnit ______________________________ 54
Fig. 29 Execuo do JUnit ________________________________________________________ 55
Sumrio
1. Introduo _____________________________________________1
1.1 Contextualizao _____________________________________________________________ 1
1.2 Problema____________________________________________________________________ 3
1.3 Problematizao ______________________________________________________________ 3
1.4 Objetivos ____________________________________________________________________ 3
1.4.1 Objetivo Geral ____________________________________________________________ 3
1.4.2 Objetivos Especficos _______________________________________________________ 4
1.5 Relevncia ou Justificativa ______________________________________________________ 5
3. Projeto _______________________________________________11
3.1 A Garantia da Qualidade de Software ____________________________________________ 11
3.1.1 Qualidade de Software_____________________________________________________ 11
3.1.2 Garantia da Qualidade de Software - SQA _____________________________________ 12
3.1.3 Testes de Software _______________________________________________________ 13
3.1.4 Padres de Qualidade _____________________________________________________ 14
3.2 Metodologias geis Agile Methodology __________________________________________ 15
3.3 Extreme Programming - XP ____________________________________________________ 17
3.3.1 Valores da XP ___________________________________________________________ 19
3.3.1.1 Simplicidade _________________________________________________________ 20
3.3.1.2 Comunicao ________________________________________________________ 21
3.3.1.3 Feedback ___________________________________________________________ 22
3.3.1.4 Coragem ____________________________________________________________ 23
3.3.2 Prticas da XP ___________________________________________________________ 23
3.3.2.1 The Planning Game____________________________________________________ 23
3.3.2.2 Small Releases _______________________________________________________ 24
3.3.2.3 Metaphor ____________________________________________________________ 25
3.3.2.4 Simple Design ________________________________________________________ 26
3.3.2.5 Testing ______________________________________________________________ 27
3.3.2.6 Refactoring __________________________________________________________ 28
3.3.2.7 Pair Programming _____________________________________________________ 29
3.3.2.8 Collective Ownership ___________________________________________________ 29
3.3.2.9 Continuous Integration _________________________________________________ 30
3.3.2.10 40 Hour Week______________________________________________________ 31
3.3.2.11 On-site Customer ____________________________________________________ 31
3.3.2.12 Coding Standards ____________________________________________________ 32
3.3.3 Os papis na XP _________________________________________________________ 32
3.3.3.1 A equipe do cliente ____________________________________________________ 33
3.3.3.2 A equipe de desenvolvimento ____________________________________________ 33
3.4. Test Driven Development - TDD ________________________________________________ 34
3.4.1 Como funciona o TDD? ____________________________________________________ 35
3.4.2 Benefcios do TDD. _______________________________________________________ 38
3.4.3 A Importncia de Ferramentas Automatizadas de Teste __________________________ 38
3.5 Implementao de Casos de Teste ______________________________________________ 40
3.6 Concluso __________________________________________________________________ 56
BIBLIOGRAFIA ___________________________________________57
SITES VISITADOS ______________________________________________________________ 57
1. Introduo
1.1 Contextualizao
A Metodologia de Desenvolvimento TDD uma metodologia na qual
programadores utilizam as facilidades e benefcios de Tcnicas de Teste para
exercer suas atividades e implementar as funcionalidades do sistema.
O objetivo no TDD a produo de Software com qualidade, obedecendo as
regras de negcio e prazos estipulados. Espera-se tambm que o desenvolvimento
do sistema seja realizado de forma simples e rpida, e que as no-conformidades
sejam identificadas facilmente e no menor tempo possvel.
A criao de cdigos de teste para testar cdigo de design antes da criao
dos mesmos o elemento que caracteriza o TDD como uma metodologia que facilita
o desenvolvimento de software. O Programador deve comear (1) criando um teste
simples e pequeno, (2) codificar somente o que foi declarado no cdigo de teste e
(3) continuar com o prximo teste at que o cdigo esteja finalizado e limpo.
Entre os fatores que acarretam os maiores riscos qualidade em um Projeto de
Software, est a ausncia ou ineficincia de testes que validem o funcionamento
correto do sistema e a boa aplicabilidade de suas caractersticas.
A Garantia da Qualidade de Software ("Software Quality Assurance, SQA")
uma atividade importante e necessria em todos os projetos de Desenvolvimento de
Software e deve estar presente em todas as etapas do Processo de
Desenvolvimento (Anlise, Design, Implementao, Testes,...).
Muitas equipes de projeto acreditam que a utilizao de testes um esforo
desnecessrio.
Outras
pretendem
utilizar
testes
para
verificar
correto
diminui
risco
de
implementao
de
caractersticas
desconhecidas.
O TDD no uma tcnica de teste. A criao de cdigo de teste anteriormente
criao de cdigo de design, se d na fase de Codificao e pode ser
caracterizada mais apropriadamente como uma tcnica de anlise ou design, isso
porque a criao do cdigo de teste possibilita ao programador (1) decidir o que ele
ir programar no cdigo de design e o que no ir, (2) e tambm definir que
caractersticas de design vo possuir as funcionalidades que sero implementadas.
1.2 Problema
1.3 Problematizao
1.4 Objetivos
2. Reviso Bibliogrfica
devem ser avaliados tanto os produtos do software como o processo que est sendo
utilizado para desenvolv-lo.
Qualidade de Software em [Pres, 2001] definida como a conformidade com
requisitos funcionais e de desempenho explicitamente declarados, padres de
desenvolvimento explicitamente documentados e caractersticas implcitas, que so
esperadas em todo software desenvolvido profissionalmente.
A busca pela qualidade visa diminuir a quantidade de defeitos e se preocupa
ainda mais em certificar que a quantidade de erros foi minimizada de uma verso
para outra.
O Controle de Qualidade envolve um conjunto de atividades necessrias para
que sejam feitas revises e avaliaes ao longo do processo de desenvolvimento e
as no-conformidades sejam capturadas to cedo quanto possvel.
O Teste de Software o elemento que representa uma avaliao da
especificao, projeto e gerao de cdigo do software. Os testes tm um papel
importante, e so aplicados para que os erros sejam encontrados antes que sejam
passados para a prxima atividade de Engenharia de Software ou para o cliente.
importante que o objetivo de cada teste satisfaa os requisitos especificados,
que eles sejam planejados anteriormente a gerao de cdigo, que sejam testadas
as funcionalidades do software como tambm a correta interao entre os diversos
componentes.
Alguns padres de qualidade so utilizados pela comunidade de Engenharia de
Software para avaliar os processos de desenvolvimento utilizados pelas empresas
de desenvolvimento de software. Entre as normas e padres mais conhecidos esto:
ISO 9001, ISO 12207, ISO 15504 (SPICE) e os diferentes tipos do CMM.
3. Projeto
11
comportamento e desempenho.
importante que (1) o objetivo de cada teste satisfaa os requisitos
especificados, (2) que eles sejam planejados anteriormente a gerao de cdigo, (3)
que sejam testadas as funcionalidades do software como tambm a correta
interao entre os diversos componentes e (4) que os testes sejam aplicados por
profissionais capacitados.
Como produto da atividade de testes, na criao dos testes do software so
criados diversos casos de teste que tm grande probabilidade de encontrar erros
com o mnimo esforo e tempo. Na execuo dos testes, o responsvel pela
qualidade simula a execuo de um programa para encontrar os erros existentes.
Os produtos podem ser testados atravs de duas categorias de casos de teste:
(1) os testes de caixa- preta, que so utilizados para verificar se as funes do
software esto operando corretamente como foi especificado e (2) os teste de caixabranca que verificam se a interao entre os componentes externos est adequada.
Entre os tipos de teste existentes, destacam-se os (1) testes de unidade, que
verificam a qualidade de cada entidade (e.g., classe, Servlets, EJB em linguagem
13
ISO 12207: norma que caracteriza todas as atividades que devero ser
utilizadas pela equipe durante todo o ciclo de vida do software.
14
os
requisitos.
Os
requisitos
devem
ser
totalmente
identificados
conhece mais rpido como o sistema funciona na realidade, com isso as mudanas
so descobertas mais rpido e portanto o preo estipulado pode mudar no decorrer
do projeto.
Em algumas metodologias tradicionais, a qualidade do projeto medida pela
conformidade com o planejamento, o que dificulta a equipe a perceber quando foi
produzido um produto de baixa qualidade, resultando em desvios no cronograma do
projeto, devido procura pelo causador do erro. Nas metodologias geis a cada
iterao o planejamento refeito. As no-conformidades so descobertas tempo e
a incluso de novas funcionalidades pode ser realizada facilmente. Por isso as
iteraes devem ser pequenas, verificando as variaes e oportunidades para
elaborar o produto adequado.
A equipe de projeto em metodologias geis no difere muito das equipes que
utilizam as metodologias tradicionais para desenvolver software. Os requisitos do
projeto mudam constantemente e toda a equipe precisa saber a existncia de novas
mudanas. Para isso necessita-se de pessoas confiveis, que aceitam mudanas e
com conhecimento suficiente para liderar e trabalhar com as Metodologias geis.
O importante para as metodologias geis prover ao cliente valor de negcio.
Para o cliente, valor de negcio se resume a um software com a qualidade maior
que a esperada e um custo menor que o estipulado.
Escopo bem definido, contrato e distanciamento entre fornecedor e cliente, no
atendem a um mercado em constante mudana.
Metodologias geis provem um conjunto simples de regras, encorajando a
criatividade e produzindo melhores resultados que impondo regras complexas e
rgidas.
O interesse em utilizar metodologias geis no querer voltar ao passado,
onde no existiam regras para desenvolver software e sim utilizar somente regras e
prticas concisas e efetivas que garantam a qualidade do software.
3.3.1 Valores da XP
19
fundamentais para que seja possvel atingir todos os objetivos do Projeto. Tais
valores devem ser respeitados e seguidos por todos os membros da equipe,
inclusive o cliente. Das quatro dimenses da XP, uma poder sempre melhorar um
projeto de software. [Don, 2003]
3.3.1.1 Simplicidade
3.3.1.2 Comunicao
3.3.1.3 Feedback
Os resultados positivos da elaborao de produtos do software podem ser
garantidos e explicitados atravs de diversas prticas e valores da XP e no devem
se apoiar no otimismo da equipe. Feedback o valor da XP que possibilita a equipe
descobrir se um produto foi elaborado corretamente e se est em conformidade com
o que foi requisitado pelo cliente. A obteno do feedback deve ser constante e deve
ser obtido tanto do cliente como do sistema.
Pequenas partes do software devem ser desenvolvidas e aps cada
desenvolvimento o feedback deve ser obtido, garantindo o status de aceitao do
cliente em relao ao produto gerado, garantindo que o produto est em
conformidade com os requisitos e diminuindo os riscos de elaborao de um
software sem valor para o cliente.
Obter feedback constantemente facilita a descoberta de novas funcionalidades
ou mudanas mais cedo e assim a implementao das mesmas tambm se torna
mais fcil.
Feedback est relacionado a outros valores da XP, entre eles Comunicao e
Coragem. Uma boa comunicao entre o cliente e a equipe de desenvolvimento
possibilita obter feedback constante, verificando a conformidade do sistema com os
requisitos do cliente. Feedback e coragem se combinam, uma vez que obtendo
feedback do sistema atravs de prticas que verifiquem se um servio foi
implementado corretamente, o programador tem mais coragem para implementar
todas as mudanas que so necessrias.
Feedback tambm se relaciona com algumas prticas da XP. Na prtica on-Site
Customer o cliente est presente no mesmo local que a equipe de projeto e portanto
mais fcil obter feedback sobre os produtos elaborados. Na prtica Testing
possvel obter feedback do sistema atravs da aplicao de testes freqentes.
Obtendo rpido feedback o desenvolvimento do sistema comea mais cedo. O
programador tem a garantia de que se houver alguma no-conformidade, esta ser
encontrada o mais rpido possvel, tanto pelo cliente como pelo sistema. Assim,
22
3.3.1.4 Coragem
3.3.2 Prticas da XP
23
produtos. Nas atividades realizadas pelo pessoal tcnico esto (1) o estudo das
estimativas do projeto, (2) identificao das conseqncias e impactos tcnicos e
financeiros, (3) o estudo e definio de como ser o processo de desenvolvimento e
(4) a definio de um cronograma detalhado. Identificado o tamanho do projeto e
em quanto tempo ser realizado.
O planejamento no deve durar meses, mas preciso um planejamento mnimo
para saber onde estamos indo, como atingiremos os objetivos e quais os riscos que
podem ser encontrados. [Ast, 2002]
Os requisitos mudam constantemente e portanto o planejamento tambm
sofrer diversas mudanas. Devido ao relacionamento existente entre as prticas da
XP, possvel que as atividades de planejamento sejam suportadas por outras
prticas quando temos uma situao negativa. Com a realizao de pequenas
verses (Small releases) as no conformidades do planejamento tm um impacto
muito menor no projeto. Com a presena do cliente (On-site customer) pode-se obter
feedback mais rpido sobre o planejamento elaborado e no-conformidades
existentes.
Voc pode comear a desenvolver com um plano simples e continuamente
refin-lo ao longo do projeto. [Bec, 2000]
3.3.2.3 Metaphor
25
garante que o design implementado realmente est sendo o mais simples possvel.
As Small Releases devem possuir um design simples com somente as
funcionalidades necessrias.
Simple Design e Testing possuem uma relao ainda maior. A criao dos
cdigos de teste antecipadamente ao cdigo de design, garante que no cdigo de
design vo existir somente as funcionalidade necessrias (aquelas que foram
implementadas no cdigo de teste), obtendo um design simples, com maior
qualidade e desenvolvendo no tempo estimado, j que funcionalidades futuras no
so implementadas e os testes provem feedback em relao as noconformidades. Neste momento pode-se notar a importncia e benefcios do
Desenvolvimento Dirigido por Testes (TDD).
26
3.3.2.5 Testing
27
A prtica de Testes tambm tem relao com as outras prticas da XP. Com
um design simples (Simple Design) a elaborao dos cdigos de teste se torna muito
mais fcil. Com o Pair Programming ambos os programadores podem incrementar
cada vez mais os testes. A integrao contnua (Continuos Integration) dos produtos
mais fcil e confiante uma vez que um produto s integrado quando todos os
testes passarem 100%. Como os cdigos no possuem proprietrios (Collective
Ownership) mais fcil entender o objetivo de um programa/cdigo analisando pelo
cdigo de teste. O refinamento do cdigo atravs do Refactoring feito sempre que
necessrio e com coragem pelos desenvolvedores, pois os mesmos podem certificar
que as alteraes no comprometeram o que estava funcionando corretamente,
atravs dos testes. O cliente acompanha o desenvolvimento (On-Site Customer) e
verifica que o projeto est em bom andamento atravs dos testes.
3.3.2.6 Refactoring
28
Permitindo que muitas pessoas trabalhem com o cdigo, faz com que cada
pessoa conhea um pouco de todo o sistema.
Como as prticas da XP suportam uma as outras, com a propriedade coletiva
no diferente. necessrio
30
31
3.3.3 Os papis na XP
Patrocinadores:
2002]
Com muito pouco processos preciso ter pessoas extraordinrias para fazer
coisas ordinrias; com processos demais, nem mesmo as pessoas extraordinrias
conseguem fazer coisas extraordinrias. [Ast, 2002]
e a rejeio dos
34
do TDD
35
funcionais seriam uma vistoria dos futuros usurios da casa, verificando como seria
morar nessa casa.
Testes unitrios so elaborados pelos programadores para verificar se todos os
servios do sistema (e.g., todos os mtodos, de todas as classes) esto operando
corretamente. Testes funcionais so elaborados pelo cliente (algumas vezes com a
ajuda de uma pessoa experiente) para verificar que o sistema faz o esperado.
As atividades que compe o TDD so atividades que facilitam a elaborao da
anlise, design e codificao dos produtos do software, e que encorajam os
programadores a simplificar e realizar todas as mudanas no sistema quando
necessrio.
As principais atividades do TDD so: (1) a elaborao de testes unitrios
automatizados, que representem uma pequena funcionalidade (e.g., um mtodo de
uma classe), (2) a elaborao do cdigo de design referente ao cdigo de teste e (3)
o refactoring. Essas atividades so realizadas at que toda a funcionalidade seja
implementada, todos os testes passem 100% e o design seja o mais simples
possvel. Nenhum cdigo de design pode ser produzido antes que exista um cdigo
de teste referente ao mesmo, e o no cumprimento dessa regra pode comprometer a
qualidade dos produtos do software e a utilizao da metodologia TDD.
A elaborao de cdigos de teste e cdigos de design alternada no TDD.
Com isso, os programadores no se cansam de escrever cdigos de teste, pois eles
facilitam a elaborao dos cdigos de design e tornam esse processo mais divertido.
A elaborao do cdigo de teste anteriormente a elaborao do cdigo de
design um fator indispensvel no TDD. Esta prtica facilita o entendimento sobre o
que deve ser implementado e como deve ser implementado (anlise e design). Alm
disso,
36
37
38
Atualmente
existem
diversas
ferramentas
para
desenvolvimento
Luz Verde -
Luz amarela -
falha de compilao
Luz vermelha -
falha no teste
[1] JUnit framework para criao de testes unitrios automatizados; [Bec, 2001]
[2] Cactus framework para criar testes unitrios em componentes J2EE [Cactus]
[3] HttpUnit framework para criar testes funcionais para aplicaes web [HttpUnit]
[4] JunitPerf framework para criar testes de performance em Web sites. [JunitPerf]
39
41
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
44
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
46
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
47
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
49
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
51
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
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
As classes compilaram com sucesso e o JUnit ser executado mais uma vez.
54
55
3.6 Concluso
56
BIBLIOGRAFIA
[Hig, 2002] R. Hightower, N. Lesiecki. Java Tools for eXtreme Programming. Wiley,
2002.
[Pres, 2001] Roger S. Pressman Engenharia de Software 5 edio
SITES VISITADOS
[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
[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/
[Fow, 2003] Martin Fowler - The New Methodology - (consulta feita em 06/2003)
http://www.martinfowler.com/articles/newMethodology.html
[Jef, 1999]
Resource.