Desenvolvimento guiado por testes e ferramentas xunit

Transcrição

1 Desenvolvimento guiado por testes e ferramentas xunit Carlos Eduardo Santin 1 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil cesantin@inf.ufrgs.br Abstract. This paper presents an overview about one of the development ways appeared in the methodology Extreme Programming (XP), the TDD (Test Driven Development). This methodology besides improving the software s quality through the application of tests, also aids in the system s development because the creation of tests before the development does the developer think about the classes that should be created as well as its methods and attributes. The TDD methodology is based on unit tests creation, which are small and independents, allowing on this way the fast location of bugs in the system and easy maintenance of this tests when necessary. Based on this idea appeared the concept xunit, which define how a test s tool should be implemented. This concept led off the development of unit tests tools for several programming languages as SUnit for SmallTalk, JUnit for Java, NUnit for.net, and several others. Resumo. Este artigo apresenta um visão geral sobre uma das formas de desenvolvimento surgidas na metodologia Extreme Programming (XP), o desenvolvimento guiado por testes (TDD - Test-Driven Development). Esta metodologia além de melhorar a qualidade do software através da aplicação de testes, também auxilia no desenvolvimento do sistema pois a criação de testes antes do desenvolvimento faz com que o desenvolvedor reflita sobre as classes que deverão ser criadas bem como seus métodos e atributos. A metodologia TDD baseia-se na aplicação de testes de unidade, testes estes pequenos e independentes permitindo desta forma a localização rápida de bugs no sistema e a fácil manutenção dos testes quando necessário. Baseado nesta idéia surgiu o conceito xunit, que define como uma ferramenta de testes de unidade deve ser implementada. Este conceito deu início ao desenvolvimento de ferramentas de testes de unidade para diversas linguagens de programação como a SUnit para SmallTalk, JUnit para Java, NUnit para.net, e diversas outras. 1. Introdução Atualmente as empresas desenvolvedoras de softwares para garantirem a sua permanência no mercado devem apresentar um certo grau de qualidade nos seus produtos. Uma das técnicas utilizadas para garantir esta qualidade é a aplicação de testes no software desenvolvido a fim de verificar se ele está satisfazendo completamente os requisitos do usuário e se não apresenta erros de codificação. No entanto, a aplicação de testes não é uma tarefa que visa apenas a busca de erros no código escrito, ela também pode servir como uma ferramenta para conduzir a implementação do software. Neste trabalho são exibidas as principais idéias do desenvolvimento guiado por testes e algumas ferramentas que possibilitam a execução dos testes criados, ferramentas da família xunit. Com este objetivo o

2 texto está organizado da seguinte forma: na seção 2 é dado uma breve explicação sobre o que é a tarefa de teste de software e como ela é realizada. Na seção 3 é explicada a metodologia de desenvolvimento guiado por testes e alguns exemplos de codificação são apresentados para uma melhor compreensão. Na seção 4 é mostrado o funcionamento dos testes de unidade através da descrição de algumas ferramentas utilizadas para este propósito. Na seção 5 são exibidos alguns dos principais benefícios ao ser adotada a metodologia TDD. Na seção 6 é dada uma explicação de como deve ser feita a migração de um processo de desenvolvimento para o TDD. Na seção 7 são apresentadas as conclusões do trabalho. 2. Teste de Software Teste de software é um processo utilizado para identificar defeitos no software e verificar se o sistema realmente satisfaz seus clientes em termos de efetividade e uso. Geralmente um software pode apresentar problemas devido a deficiências nas especificações ou deficiências no código do software. Desta forma, os testes podem ser vistos como um processo para descobrir erros e eliminá-los antes da entrega do sistema ao usuário. O teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projeto de casos de teste, execução e avaliação dos resultados dos testes [Pressman 1997, Myers 1979, Beizer 1990]. Em geral essas atividades concretizam-se em três fases de teste: de unidade, de integração e de sistema. O teste de unidade concentrase na menor unidade do projeto, ou seja, em cada módulo do software, separadamente. O teste de integração visa detectar erros associados às interfaces entre os módulos. Já o teste de sistema visa identificar erros de funções e características de desempenho que não estejam de acordo com a especificação. No entando, os testes nem sempre são aplicados de maneira correta e os principais motivos são os seguintes: Os testes geralmente são aplicados após toda a escrita do código ou após o programador que está realizando a escrita ser movido para outra tarefa. Quando você não está efetivamente envolvido com o código, leva mais tempo e mais trabalho retornar a estudar o código e trabalhar com os possíveis problemas existentes. Geralmente os testes não são criados pelo programador que escreveu o código. Desta forma o criador dos testes pode não entender todos os detalhes do código e conseqüentemente esquecer de criar testes importantes. Caso o responsável pela escrita dos testes se baseie em documentações ou outros artefatos para criá-los e não no código, uma desatualização nestes artefatos pode gerar problemas nos testes a serem criados. Se os testes não são automatizados eles podem não ser executados com freqüencia ou não serem executados da mesma maneira todas as vezes. Para evitar que ocorram estes problemas foi proposto por Kent Beck [Beck 2002] uma metodologia na qual o desenvolvimento do software é auxiliado através da geração e execução de testes, esta metodologia chama-se Desenvolvimento guiado por testes (TDD - Test-Driven Development), este é o tema da próxima seção. 3. Desenvolvimento guiado por testes (TDD - Test-Driven Development) Para a implementação de uma porção de um sistema, milhares de decisões devem ser tomadas e é muito difícil que essas decisões sejam tomadas de forma correta antes do

3 início da escrita do código. O desenvolvimento guiado por testes (TDD) é uma metodologia que como o nome já diz, faz uso de testes para auxiliar os desenvolvedores a tomarem as decisões corretas no tempo correto. Desta forma, o TDD não pode ser visto como uma ferramenta para testes mas sim como a utilização de testes para a criação de software de uma maneira simples e incremental. Portanto além de melhorar a qualidade do software também simplifica o processo de desenvolvimento. O TDD evita que os testes sejam aplicados de maneira incorreta, principalmente pelos seguintes motivos [Astels 2003]: O programador é quem cria os testes, trabalhando neles enquanto o código do software ainda está bem presente em sua mente. Os testes são automatizados, garantindo uma maior freqüência na sua execução e garantindo também que o teste executado em um determinado momento será idêntico nas demais vezes em que ele for executado. O desenvolvimento guiado por testes é uma das principais práticas existentes em Extreme Programming (XP) [XP 2006] e sua idéia é que sistemas complexos podem ser desenvolvidos em pequenos passos incrementais através da utilização de testes para guiar o projeto e a implementação do software. A principal dificuldade na utilização do TDD está em modificar a forma de pensar do desenvolvedor, que não deve mais projetar para ter uma estrutura de como o código será gerado mas sim criar testes que definam como pequenas partes do sistema devem funcionar. Basicamente o TDD é um estilo de desenvolvimento onde [Astels 2003]: Nenhum código do sistema é escrito sem que haja um teste associado a ele; Escrevem-se os testes antes do código do sistema; Os testes determinam que código é necessário escrever. A metodologia de desenvolvimento guiado por testes é basicamente composta dos seguintes passos: 1. Escreva uma teste que defina como você pensa que uma pequena parte do sistema deve funcionar; 2. Faça o teste funcionar da forma mais rápida possível que você puder. Não se preocupe com detalhes de como implementar da maneira mais correta, apenas faça o teste funcionar; 3. Limpe o código. Agora que o teste está funcionando retorne e realize um refactoring do código gerado. Refactoring é o processo de realizar alterações na estrutura do código sem alterar o seu comportamento externo. O TDD é um processo iterativo portanto estes 3 passos anteriormente citados devem ser repetidos até que o desenvolvedor esteja satisfeito com o novo código gerado. A forma que o TDD trabalha é decompor os requerimentos do sistema em um conjunto de comportamentos necessários para cumprir estes requerimentos, sendo que para cada comportamento do sistema a primeira coisa a ser feita é escrever um teste de unidade para testá-lo. Por exemplo, supondo que deve ser escrito um software para uma academia de musculação para obter o peso dos clientes em uma determinada data e obter a média dos pesos de todos os clientes em uma determinada data. Pensando nas necessidades do sistema, chegamos aos seguintes comportamentos necessários: O software deve ser capaz de identificar cada cliente;

4 Deve permitir a entrada de dados do cliente para obtenção das informações requeridas; Deve permitir obter o peso de um determinado cliente numa determinada data; Deve permitir obter a média de peso de todos os clientes numa determinada data. Desta forma, podemos escrever o seguinte teste de unidade: //Obtém o cliente Carlos Cliente carlos = ClienteLista.getCliente( Carlos ); //Adiciona o peso do cliente Carlos no dia 01/01/2006 carlos.addpeso( 01/01/2006,73.0); //Adiciona o peso do cliente Carlos no dia 01/02/2006 carlos.addpeso( 01/02/2006,70.0); //Obtém o cliente Joao Cliente joao = ClienteLista.getCliente( Joao ); //Adiciona o peso do cliente Joao no dia 01/01/2006 joao.addpeso( 01/01/2006,78.0); //Adiciona o peso do cliente Joao no dia 01/02/2006 joao.addpeso( 01/02/2006,74.0); //Obtem o peso de Carlos no dia 01/02/2006 float pesocarlos = carlos.getpeso( 01/02/2006 ); //Obtem a media de pesos dos clientes no dia 01/02/2006 float mediapesos = ClienteLista.getMediaPesos( 01/02/2006 ); //Verifica se o retorno do peso de Carlos esta sendo feito de forma correta assertequals(70.0, pesocarlos); //Verifica se o retorno do peso médio dos clientes esta sendo feito de forma correta assertequals(72.0, mediapesos); Devido a escrita deste teste de unidade, agora sabemos que devemos ter uma classe ClienteLista e uma classe Cliente. A classe ClienteLista deverá possuir os métodos get- Cliente() e getmediapesos(), e a classe Cliente deverá possuir os métodos addpeso() e getpeso(). Além de descobrirmos as classes que devem ser implementadas e os métodos delas, também sabemos os parâmetros de entrada de cada método e seus tipos, bem como os parâmetros de saída e seus tipos. Desta forma um teste de unidade não apenas ajuda a verificar se o código esta corretamente implementado como também ajuda a definir as classes e métodos que devem ser implementados para determinado comportamento. Após a escrita do teste devemos executá-lo, é claro que o teste falhará pois não possuimos as classes Cliente e ClienteLista implementadas, mas este é um passo importante do teste pois ele nos fará ver que o teste de unidade está funcionando corretamente. Então, após a execução do teste e após obtermos a falha devemos implementar as classes necessárias e re-executar o teste para garantir que a implementação do software está se comportando como o esperado. A metodologia TDD ressalta que devemos realizar pequenos passos para chegarmos a um teste que realmente verifique o comportamento do sistema. No exemplo da academia, o primeiro passo que deve ser tomado após obtermos a mensagem de erro da execução do teste é implementar a classe Cliente. Logo implementaremos o seguinte código: public class Cliente{ }

5 Em seguida devemos implementar a classe ClienteLista: public class ClienteLista{ } Neste momento não teremos mais os erros devido a inexistência das classes mas ainda temos os erros devido aos métodos que não foram implementados, portanto o próximo passo é implementar os métodos getcliente() e getmediapesos() na classe ClienteLista, e os métodos addpeso() e getpeso() na classe Cliente: public Cliente getcliente(){ } return new Cliente(); public float getmediapesos(){ } return 72.0; public void addpeso(float peso){} public float getpeso(){ } return 70.0; Nos métodos criados muitas coisas não foram implementadas e podemos perceber que os métodos get estão retornando sempre o mesmo valor, mas esta é a idéia do TDD, devemos implementar de forma que o teste consiga obter sucesso, quando conseguimos isso então retornamos ao código, implementamos o que está faltando e alteramos o que deve ser alterado. Após este ciclo podemos passar para o próximo comportamento. Desta maneira os testes vão guiando o desenvolvimento do sistema através de uma forma simples e incremental, e esta metodologia de desenvolvimento garante que todo o código escrito está relacionado a algum comportamento e não teremos códigos que nunca serão utilizados. Durante a implementação do teste utilizamos o método assertequals para verificar a igualdade de dois parâmetros, estes métodos de afirmação de uma expressão são definidos na arquitetura xunit, uma arquitetura para implementação de softwares para testes de unidades proposto por Kent Beck, assunto da próxima secção. 4. Arquitetura xunit O conceito xunit foi criado por Kent Beck, que fez sua primeira implementação no início dos anos 90 usando a linguagem de programação SmallTalk, esta implementação ficou conhecida como SUnit. A versão original do SUnit baseava-se na criação de pequenos testes, um para cada classe, para que caso algum erro ocorresse durante a implementação, este fosse rapidamente detectado e corrigido. E devido a essa característica, de os testes serem implementados por classe, a alteração em uma determinada classe resulta na alteração do teste relacionado apenas aquela classe e não dos demais. Os testes realizados pelo xunit baseiam-se na comparação do resultado obtido ao se executar uma função com o resultado esperado. Atualmente a idéia do xunit foi adotada para testes em diversas linguagens, a seguir citaremos algumas das principais implementações realizadas, explicações sobre outras ferramentas xunit podem ser encontradas em [xunit 2006].

6 4.1. CPPUnit O CPPUnit [CPPUnit 2006] é um framework para testes de unidade em C++. A função principal existente neste framework é o CPPUNIT ASSERT, que recebe como parâmetro qualquer expressão que possua uma valor booleano e retorna se esta expressão é ou não verdadeira. Através desta função a maioria dos testes podem ser implementados. Além desta função, também estão presentes neste framework a função setup() para inicilização de variáveis e teardown() para liberação de qualquer recurso alocado no método setup(). Este framework também permite a criação de suites onde vários testes podem ser alocados e executados em conjunto DUnit DUnit [DUnit 2006] é um framework de testes para os programas desenvolvidos em Borland Delphi, suportando as versões superiores ou iguais ao Delphi 4. Este framework provê duas opções para execução dos testes: uma interface gráfica (Figura 4.2) que permite selecionar testes individuais ou grupos de testes a serem executados, e uma aplicação para execução em terminais. Figure 1. Ambiente gráfico para execução de testes da ferramente DUnit. Os testes de unidade a serem criados utilizando o DUnit devem utilizar a unit TestFrameWork que permite registrar os testes a serem executados, e devem estender a unit TTestCase que apresenta os métodos para verificação dos resultados. Basicamente os testes implementados devem fazer uso do método Check existente na unit TTestCase para fazer a comparação de resultados. Esse método recebe dois parâmetros, o primeiro é uma expressão que retorna um valor booleano e o segundo é uma String contendo uma mensagem a ser exibida no caso do teste falhar. Ao executar os testes, o DUnit cria instâncias separadas da classe para cada método existente nela, logo, os métodos não podem compartilhar dados. Para poder criar uma variável que poderá ser acessada por diferentes métodos da classe devemos fazer

7 uso do método SetUp(), para criar a variável, e do método TearDown() para liberar as variáveis criadas. O DUnit permite também a execução de uma seqüência de testes implementados em classes diferentes de forma automática. Para isso ele suporta a criação de test suites, que são testes que podem conter outros testes ou mesmo outros test suites JUnit JUnit é um framework para teste de softwares desenvolvidos em Java. Foi desenvolvido por Kent Beck e Erich Gamma, sendo um dos maiores sucessos entre os frameworks da família xunit. A figura 2 exibe um diagrama de alto nível do pacote framework, o pacote central do JUnit. Figure 2. Diagrama do pacote junit.framework A interface Test é a interface que todas classes de teste devem implementar. Atualmente no framework existem apenas duas dessas classes: a TestCase e a TestSuite. testes. TestCase é a classe que deve ser estendida quando queremos escrever os nossos TestSuite tem o propósito de juntar testes (classes que estendem TestCase) ou Test- Suites, para realização de execução em conjunto. Assert é a superclasse de TestCase que provê os métodos que estarão disponíveis para o programador criar seus testes.

8 A classe TestFailure encapsula os erros e falhas que ocorram durante a execução do teste. A classe TestResult acumula o resultado da execução dos testes, ela é a responsável por informar as partes interessadas do início e fim dos testes, bem como de qualquer erro ou falha ocorrida. Esta classe permite a interface gráfica exibir os resultados dos testes. TestListener é a interface que é implementada pelas classes que desejam controlar o progresso dos testes. Para a escrita de testes devemos fazer uso dos métodos assert existentes na classe TestCase, estes métodos possuem sempre duas versões: uma que recebe como parâmetro um String contendo a mensagem a ser exibida em caso de falha e outro sem este String. Os métodos asserttrue e assertfalse verificam respectivamente quando uma expressão é verdadeira ou falsa. Por exemplo, o teste a seguir teria sucesso em sua execução: asserttrue((1 + 1) == 2); assertfalse((1+1) == 3); Os métodos assertnull e assertnotnull verificam respectivamente quando uma expressão retorna um valor nulo e não nulo. Por exemplo, no seguinte teste teriamos sucesso em sua execução: String str1 = null; String str2 = new String(); assertnull(str1); assertnotnull(str2); Os métodos assertsame e assertnotsame são utilizados para a comparação de dois objetos. Por exemplo: String str1 = new String( str ); String str2 = new String( str ); assertsame(str1,str1); assertnotsame(str1, str2); O método assertequals ao invés de comparar a igualdade entre dois objetos, como é o caso do assertsame, compara a igualdade dos valores de dois objetos. Por exemplo, o teste a seguir seria executado com sucesso: String str1 = new String( str ); String str2 = new String( str ); assertequals(str1,str2); Para a execução dos testes criados este framework disponibiliza uma interface gráfica contida na classe junit.swingui.testrunner (figura 4.3). Esta interface facilita a execução e análise dos resultados obtidos. No entanto, também é possível executar os testes criados a partir de um terminal. A classe que permite esta execução é a junit.textui.testrunner. 5. Benefícios do desenvolvimento guiado por testes O desenvolvimento guiado por testes apresenta uma grande quantidade de benefícios entre eles [Gold et al. 2005]:

9 Figure 3. Ambiente gráfico para execução de testes da ferramente JUnit. Desenvolvimento simples e incremental: um dos principais benefícios desta abordagem é que temos um software funcionando quase que imediatamente. A primeira iteração do software é simples e não tem muita funcionalidade, porém a funcionalidade irá melhorando conforme o desenvolvimento for progredindo. É uma abordagem menos arriscada do que tentar construir um sistema que somente funcionará quando colocarmos todas as partes dele juntas. Desenvolvimento menos estressante: Os desenvolvedores que utilizam TDD precisam se preocupar apenas em ter o próximo teste executado com sucesso. O desenvolvedor foca sua atenção em pequenas partes do software, faz com que ele funcione e parte para outra parte. As decisões de projeto e implementação vão sendo tomadas aos poucos, conforme os testes são criados. Testes constantes de regressão: No desenvolvimento de software muitas vezes passamos pelo efeito dominó, onde uma simples alteração num módulo do sistema pode ocasionar conseqüências nas demais partes do sistema. Na metodologia TDD a cada alteração realizada no código são executados todos os testes gerados para o sistema até o momento, desta forma qualquer alteração que ocasione um efeito indesejado em outras partes do código é detectado imediatamente. Outra vantagem é que a cada iteração sempre temos o código funcionando. Melhora da comunicação: Muitas vezes é difícil expressar em palvras como deve ser o funcionamento de uma parte do software. Os testes de unidade servem como uma linguagem que pode ser usada para comunicar o comportamento exato de uma parte do software. Melhora da compreensão do comportamento requerido do software: A escrita de testes de unidade antes da escrita do código ajuda a focar e entender o comportamento requerido do software. Centralização do conhecimento: Muitas empresas costumam deixar o desenvolvimento dos módulos de um software para uma única pessoa, desta forma todo o conhecimento a respeito da implementação daquele código está na cabeça de

10 um único funcionário. A documentação e a implementação de um código limpo permite que outros programadores entendam como o código foi implementado, porém nem sempre isto é realizado. Com TDD, os testes de unidade constituem um repositório que provê informações sobre as decisões que foram tomadas para o projeto do módulo. 6. Como migrar o processo de desenvolvimento para TDD A mudança de um processo de desenvolvimento para o TDD deve ser feito de uma maneira controlada [Gold et al. 2005]. Se tentarmos mudar de um processo para outro de uma forma muito rápida, o processo de desenvolvimento se tornará um caos e será muito difícil recuperá-lo. Antes de executar a mudança de processo, é necessário perder um pouco de tempo pensando em como o TDD será usado no projeto atual. Devemos decidir coisas do tipo: Quais ferramentas e frameworks de testes serão usados; Como os desenvolvedores irão obter habilidades necessárias para aplicação do TDD; Como os testes serão organizados; Como os testes serão executados; Quais mudanças serão necessárias no processo atual para o uso do TDD; Como a inclusão do TDD afetará o processo atual de desenvolvimento. Algumas das decisões tomadas antes do início da prática do TDD podem mudar após, no entanto é interessante pensar a respeito antes de aplicar o TDD para ter um ambiente de desenvolvimento mais organizado. Antes de realizar a transição é necessário entender a fundo o funcionamento do TDD. O primeiro passo para obter este conhecimento é entender como utilizar o framework de testes escolhido para criação de testes de unidade efetivos. O segundo passo é entender como usar o processo TDD para guiar o desenvolvimento do software. A melhor maneira para obter este conhecimento é através da prática. Para entender o funcionamento de um framework de testes, a melhor maneira é ler a documentação existente para ele e executar os exemplos existentes. Desta forma o usuário do framework aprende como escrever e executar os testes, além de configurar o framework para o ambiente de desenvolvimento. Assim que o usuário tiver a confiança de que entendeu o funcionamento do framework, ele pode começar a escrever pequenos testes para o projeto de software que está atualmente sendo desenvolvido. A compreensão de como utilizar o processo TDD para guiar o desenvolvimento do projeto atual é um pouco mais complicado que a compreensão do funcionamento do framework de testes. Uma coisa que pode facilitar a compreensão do processo é ter um bom conhecimento sobre refactoring, pois esta é uma das práticas importantes aplicadas no TDD. Antes de começarmos a utilizar o TDD, temos que ter em mente que este processo é altamente iterativo, então não temos que obter o código correto na primeira iteração. Devemos deixar os testes nos mostrar como projetar o código e a descoberta disto deve ser feita em passos lentos e incrementais.

11 A aquisição do conhecimento necessário para aplicação da metodologia TDD pode acarretar temporariamente numa redução na velocidade do desenvolvimento, mas isto não pode ser visto como uma perda de tempo mas sim como um investimento futuro. Caso a equipe de desenvolvimento seja muito grande, é aconselhável que esta equipe seja dividida em pequenos grupos e estes obtenham o conhecimento necessário em tempos diferentes, evitando que o desenvolvimento do software atual seja totalmente interrompido. 7. Conclusão A tarefa de teste de software é algo que deve estar presente em qualquer processo para desenvolvimento de software, pois ela é uma peça fundamental para garantir a qualidade do produto final. Por mais que tenhamos uma modelagem muito bem feita do sistema, alguns erros podem surgir como por exemplo no momento da codificação e este tipo de erro pode ser facilmente detectado através da criação e execução de testes apropriados. Os testes podem ser basicamente aplicados de duas formas diferentes: podemos criá-los e executá-los após a escrita do código do sistema, para garantir que o código foi implementado de maneira correta, ou podemos criá-los antes da implementação e executálos conforme formos escrevendo o código, idéia que é a base da metodologia TDD. Como vimos na seção 5, a metodologia TDD e a aplicação de testes de unidades podem trazer uma série de benefícios no processo de desenvolvimento de software. No entanto a migração de um processo de desenvolvimento para o TDD não pode ser realizado de uma hora para outra, alguns passos devem ser seguidos para que os desenvolvedores adquiram o conhecimento necessário e evitem que o processo de desenvolvimento se transforme num caos. Por se tratar de uma prática derivada da metodologia XP, o desenvolvimento guiado por testes não é indicado para o desenvolvimento de projetos complexos que envolvam uma equipe muito grande pois geralmente neste tipo de projeto há a necessidade de uma extensa e detalhada documentação para a redução de riscos, porém em equipes menores os testes de unidade em conjunto com o código escrito para o sistema podem servir por si só como uma boa documentação para a compreensão das decisões tomadas para o projeto do software. References Astels, D. (2003). Test-Driven Development: A Pratical Guide. Prentice Hall PTR. Beck, K. (2002). Test-Driven Development By Example. Addison Wesley. Beizer, B. (1990). Software Testing Techniques. Van Nostrand Reinhold Company, New York, 2nd edition. CPPUnit (2006). Cppunit - a unit test framework for c++. Disponível em: cookbook.html/ Acesso em: 15 abr DUnit (2006). Dunit - unit test for borland delphi. Disponível em: Acesso em: 15 abr Gold, R., Hammel, T., and Snyder, T. (2005). Test-Driven Development: A J2EE Example. Apress.

12 Myers, G. J. (1979). The Art of Software Testing. Wiley, New York. Pressman, R. S. (1997). Software Engineering A Practitioners Approach. McGraw-Hill, 4th edition. XP (2006). Extreme programming. Disponível em: Acesso em: 15 abr xunit (2006). xunit - wikipedia. Disponível em: Acesso em: 15 abr