Transcript
Page 1: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS

Anderson Yoshiaki Iwazaki da Silva

TDD – Test Driven Development: Uma investigação sobre a

utilização de TDD em projetos com framework JSF

TRABALHO DE CONCLUSÃO DE CURSO

Cornélio Procópio – PR

2015

Page 2: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

2

Anderson Yoshiaki Iwazaki da Silva

TDD – Test Driven Development: Uma investigação sobre a utilização

de TDD em projetos com framework JSF

Trabalho de Conclusão de Curso de graduação, apresentado a

disciplina de Trabalho de Conclusão de Curso 2, do Curso

Superior em Análise e Desenvolvimento de Sistemas do

Departamento de Computação (DACOM) da Universidade

Tecnológica Federal do Paraná – UTFPR, como requisito para

a obtenção do título de Tecnólogo.

Orientador: Prof. Dr. Willian Massami Watanabe

Cornélio Procópio – PR

2015

Page 3: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

3

FOLHA DE APROVAÇÃO

Page 4: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

4

Dedico este trabalho à minha família.

Page 5: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

5

AGRADECIMENTOS

Agradeço a Deus, por me dar força e vida todos os dias.

Ao meu Prof. Orientador Willian Massami Watanabe, que aceitou me auxiliar

e colaborar em meu trabalho de conclusão de curso.

Aos meus colegas de trabalho, que me recepcionaram de maneira

agradável, como Fabio Dutra, Marco Fabris e Romulo Neves.

A minha família, em especial a minha mãe que sempre esteve ao meu lado e

me acompanhando nesta jornada longa.

E aos meus colegas Airton Padilha Junior, Régis Stresser, Caroline Moliani,

Emileide Cardoso, Bruna Fernandez, Hugo Aguiar, José Carlos Moraes entre outros

não citados aqui, os meus sinceros agradecimentos, na qual me auxiliaram nos

momentos de dificuldades e assim como os momentos felizes.

Enfim, a todos que contribuíram para a realização deste trabalho de

conclusão de curso, os meus sinceros agradecimentos.

Page 6: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

6

RESUMO

DA SILVA, Anderson Y. Iwazaki. TDD – Test Driven Development: Uma investigação

sobre a utilização de TDD em projetos com framework JSF. 2015. Trabalho de

Conclusão de Curso – Graduação Tecnológica no Curso de Análise e

Desenvolvimento de Sistemas, Universidade tecnológica Federal do Paraná.

Cornélio Procópio, 2015.

O TDD possui como foco principal a programação orientada a teste, ou seja, o

desenvolvimento terá início com a elaboração de um caso de teste. É argumentado

que o uso de TDD leva ao desenvolvimento de um código mais simples e claro, além

de disponibilizar uma maior quantidade de feedback ao desenvolvedor durante a

etapa de codificação. Este trabalho tem como objetivo investigar as vantagens de se

utilizar a prática do Test Driven Development (TDD), introduzindo-a no

desenvolvimento de uma aplicação web. Foi realizado uma investigação no

desenvolvimento de sistemas web utilizando o framework JSF. Com essa

investigação foi possível identificar que a elaboração de testes pode ser crucial na

entrega de um produto, o software, pois é através dela que identificam problemas

que podem ocorrer em momentos de utilização do mesmo. Com relação a

elaboração de códigos mais simples e claros no uso de TDD, os resultados

apresentados não foram satisfatórios, visto que a complexidade do projeto que

utiliza o TDD foi maior que os demais projetos que não utilizam a prática, na

investigação.

Palavras Chave: Teste de Software, TDD, métodos de teste de software.

Page 7: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

7

ABSTRACT

DA SILVA, Anderson Y. Iwazaki. TDD - Test Driven Development: An investigation

into the use of TDD in projects with JSF framework. 2015. Work Completion of

course - Technology Graduation Course in Systems Analysis and Development,

Federal Technological University of Paraná. Cornelius, 2015.

TDD consists of test-oriented programming, ie, the development will start with the

development of a test case. It is argued that the use of TDD leads to the

development of a simple and clear code, in addition to providing a greater amount of

feedback to the developer during the encoding step. This paper aims to investigate

the advantages of using the practice of Test Driven Development (TDD). The authors

reporto n the conduction of na investigation within the development of JSF web

applications. With this research it observed that the test preparation can be crucial in

delivering a product, the software because it is through it that can identify problems

that can occur during times of use thereof. In the investigation, the results were not

satisfactory somewhat, since the complexity of the project is greater than the other.

Key word: Software Testing, TDD, Method Software Testing.

Page 8: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

8

LISTA DE GRÁFICO

GRÁFICO 1 – Número de Linhas .......................................................................... 32

GRÁFICO 2 – Complexidade ................................................................................ 33

GRÁFICO 3 – Complexidade por pacote .............................................................. 34

GRÁFICO 4 – Complexidade Ciclomática ............................................................. 36

Page 9: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

9

LISTA DE FIGURAS

Figura 1 – Defeito, Erro, Falha .............................................................................. 17

Figura 2 – Modelo V .............................................................................................. 21

Figura 3 – Ciclo desenvolvimento Vermelho-Verde-Refatora ............................... 26

Figura 4 – Ciclo da Pesquisa-ação ........................................................................ 28

Figura 5 – Fluxograma .......................................................................................... 35

Figura 6: Grafo de Fluxo ....................................................................................... 35

Figura 7 – Lógica Composta ................................................................................. 36

Page 10: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

10

LISTA DE EXEMPLOS

Exemplo 1 ............................................................................................................. 33

Page 11: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

11

LISTA DE SIGLAS

TDD Test Driven Development

XP eXtreme Programming

MVC Model-View-Controller

JSF JavaServer Faces

UTFPR Universidade Tecnológica Federal do Paraná

APS Atividade Prática Supervisionada

Page 12: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

12

SUMÁRIO

1 INTRODUÇÃO ................................................................................................... 14

1.1 Objetivo Geral e Específico ............................................................................. 15

1.2 Justificativa ...................................................................................................... 15

1.3 Estrutura do Projeto ........................................................................................ 16

2 FUNDAMENTAÇÃO TEÓRICA ......................................................................... 17

2.1 Erros, Defeitos e Falhas .................................................................................. 17

2.2 Teste de Software ........................................................................................... 18

2.3 Estratégia de Teste de Software ..................................................................... 19

2.3.1 Teste de Unidade ......................................................................................... 19

2.3.2 Teste de Integração...................................................................................... 19

2.3.3 Teste de Sistema ......................................................................................... 20

2.3.4 Teste de Validação ....................................................................................... 21

2.3.5 Modelo V ...................................................................................................... 21

2.4 Abordagem de Teste de Software ................................................................... 22

2.5 Visões Interna e Externa do Teste .................................................................. 23

2.5.1 Teste Caixa-Branca / Estrutural ................................................................... 23

2.5.2 Teste Caixa-Preta / Funcional ...................................................................... 23

2.6 Métodos Ágeis ................................................................................................. 24

2.6.1 Extreme Programming (XP) ......................................................................... 24

2.6.2 TDD .............................................................................................................. 25

3 TRABALHOS RELACIONADOS ....................................................................... 27

4 MÉTODO ............................................................................................................ 28

5 COMPARAÇÃO DE PROJETOS QUE UTILIZAM TDD E PROJETOS QUE

NÃO UTILIZAM .................................................................................................... 30

5.1 Descrições dos Projetos .................................................................................. 30

5.1.1 Projeto Oral Web .......................................................................................... 30

5.1.2 Projeto Blog APS .......................................................................................... 30

Page 13: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

13

5.1.3 Projeto Chat ................................................................................................. 31

5.2 Resultados ...................................................................................................... 31

6 CONCLUSÃO .................................................................................................... 38

7 REFERÊNCIA BIBLIOGRÁFICA ....................................................................... 39

Page 14: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

14

1 INTRODUÇÃO

Nos dias atuais, percebe-se que muitos projetos de software têm sido

conduzidos em diferentes áreas de conhecimento, tais como as áreas exatas e

biológicas. No entanto, percebe-se também que muitos desses projetos não são

finalizados ou incompatíveis com o que se havia solicitado (Soares, 2004).

Em um estudo realizado por Soares (2004), foram analisados 8380 projetos

de software, dos quais apenas 16% foram entregues de acordo com o prazo e

custos estipulados, respeitando todas as funcionalidades específicas. Dentre as

demais, 31% dos projetos foram cancelados e 52,7% foram entregues acima do

prazo, com custos maiores e funcionalidades menores do que prometido.

Para resolver tais problemas de entrega, um grupo de engenheiros de

software elaborou os Métodos Ágeis, que buscam realizar todos os processos de um

método convencional em um curto espaço de tempo. Métodos ágeis tem como

objetivo o enfoque nas pessoas e não mais na documentação, ou seja, o

desenvolvedor se preocupa cada vez menos com a documentação, focando apenas

na implementação do projeto (Soares, 2004).

Considerando o contexto acima, percebe-se que a área de desenvolvimento

pode ser ampla, fazendo com que falhas humanas possam ser injetadas dentro do

desenvolvimento de um software. De acordo com Pressman (2002), a falta de

mecanismo que garantem a qualidade do software pode causar perdas

significativas, tais como a confiabilidade de um cliente ao sistema. Dessa forma,

torna-se necessário a realização de atividades de teste de software.

Para Pressman (2002), um teste software é a garantia de que a qualidade do

produto final possa representar a revisão da especificação, projeto e geração de um

software. Com isso, começam a surgir dois aspectos importantes para o teste de

software, a verificação e a validação, que abrangirá muitas atividades que garantem

a qualidade de um software.

Segundo Pressman (2002) a validação é um conjunto de atividades que

garantem que o software construído corresponde aos requisitos levantados pelo

cliente, já a verificação irá garantir que o software implemente corretamente uma

função em específico.

Page 15: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

15

Uma das práticas de desenvolvimento ágil que incentiva a realização do

teste é conhecida como Test Driven Development (TDD), que possui como principal

característica o desenvolvimento baseado em teste. Este trabalho irá demonstrar e

verificar os prós e contra da utilização do TDD em um projeto de software.

1.1 Objetivo Geral e Específico

Apesar da importância da realização do teste no desenvolvimento de um

software, o desenvolvimento orientado a teste, o TDD, busca a elaboração de um

código simples e de baixa complexidade. Sendo assim, o objetivo principal deste

trabalho é investigar os resultados obtidos de maneira quantitativa a utilização do

TDD no processo de desenvolvimento de software. Como objetivo específico, o caso

de estudo abordado nesse trabalho é o desenvolvimento de um software voltado

para consultórios odontológicos, em comparação a outros projetos que utilizaram a

maneira convencional de programação, como o Blog APS e o Chat, que para a

avaliação entre os projetos, foi utilizado métricas de complexidade ciclomática,

número de linhas, complexidade ciclomática por pacotes.

1.2 Justificativa

A utilização do TDD pode resultar na elaboração de códigos devidamente

testados, visto que os testes são elaborados antes mesmo da implementação dos

códigos. Logo, percebe-se que uma das maiores preocupações na utilização do

TDD são os testes, deixando para o segundo plano a implementação. Beck (2004)

ressalta que a utilização do TDD pode resultar na elaboração códigos limpos e

funcionais. Além da obtenção de códigos limpos e funcionais, Aniche (2014) ressalta

a diferença da quantidade de feedback que um programador praticante de TDD tem

em comparação com o não praticante. Logo, a linha de raciocínio do TDD é que o

programador deve escrever um pouco de testes, um pouco da implementação e

receber o feedback da mesma, o que muitas vezes não ocorre aos que não utilizam

tal prática. Pois, em projetos que utilizam abordagens de desenvolvimento

convencional, o feedback de sua implementação só será observado no decorrer do

Page 16: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

16

tempo (muitas vezes levando um longo período de tempo). Sendo assim, o

recebimento de feedback o quanto antes possibilita que o programador corrija os

problemas a um custo menor que um programador que recebeu o mesmo feedback

após muito tempo.

Esta pesquisa tem como principal característica comparar os resultados

obtidos através de projetos que utilizam TDD e projetos que não utilizam TDD. Essa

comparação será realizada com o objetivo de identificar se os benefícios da prática

de TDD realmente podem ser observadas na prática.

1.3 Estrutura do Projeto

Este trabalho está subdivididos em 5 (cinco) partes, começando pela

fundamentação teórica, que dará todo o conceito relacionado a teste de software,

passando pelos trabalhos relacionados, que dará uma visão geral das conclusões já

obtidas.

Após todo o conceito, o trabalho apresentará o método utilizado na

pesquisa, para após apresentar os resultados obtidos através da pesquisa

abordada, finalizando pela conclusão.

Page 17: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

17

2 FUNDAMENTAÇÃO TEÓRICA

Nessa seção, são apresentados os principais conceitos associados a este

trabalho de diplomação.

2.1 Erros, Defeitos e Falhas

Segundo Koscianski e Soares (2007), há termos utilizados que podem

causar certa confusão, embora evoquem ideias parecidas, os termos erros, defeitos

e falhas são designados para designar conceitos diferentes.

Koscianski e Soares (2007) definem defeito como uma imperfeição existente

em um produto, isto é, o defeito é um código existente dentro de um programa o

qual está implementado de maneira incorreta.

Já Neto (2014), define erro como uma manifestação concreta de um defeito,

ou seja, qualquer atitude inesperada ou a obtenção de um resultado inesperado na

execução do programa constitui um erro.

Porém de acordo com Koscianski e Soares (2007) uma falha é o resultado

inesperado retornado através de um defeito ou também através de fatores externos

ao programa, como a invasão de memória por outros programas, ou a utilização de

base de dados danificados.

A Figura 1 demonstra que o conceito de defeito, erro e falha estão

interligados, ou seja, um universo está contido no universo do próximo conceito e

assim por diante, até chegar ao universo do usuário.

Figura 1 – Defeito, Erro, Falha

Fonte: Arllo Cláudio Dias Neto (2015)

Page 18: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

18

2.2 Teste de Software

O objetivo da atividade de teste de software é a busca de erros ou anomalias

que um sistema possa apresentar no momento de execução. Os testes podem ser

inseridos no início de seu desenvolvimento (até na fase de elaboração de conceitos

abstratos como modelos), até nas fases finais do processo (apresentando erros e

anomalias no produto final). Sendo assim, um bom caso de teste de software, é um

caso que identifica erros até então não reportados dentro de um projeto,

aumentando assim a confiabilidade de se utilizar o software.

Pressman (2002) ressalta que o teste de software deve ser projetado de

maneira que o maior número de erros seja encontrado, porém com uma quantidade

mínima de tempo e esforço.

Para isso, Pressman (2002) ressalta seis princípios que guiam a atividade de

teste de software que elevam a qualidade do produto final:

Elaborar os testes de acordo com o levantamento de requisitos elaborados

pelo cliente.

Planejar os testes que deverão ser realizados antes do desenvolvimento.

Incluir o princípio de Pareto nos testes de software, o qual descreve que

deve-se isolar o módulo que apresenta uma maior quantidade de falhas para

corrigi-las.

Elaborar os testes considerando diferentes estratégias, começando do

unitário, partindo para o sistema completo.

Cobrir adequadamente a lógica do programa, garantindo que todas as

condições tenham sido executadas.

Realizar os testes com indivíduos externos ao projeto.

Considerando os itens mencionados anteriormente, pode-se supor que as

identificações de erros fazem com que a manutenção do software seja cada vez

menor, pois o testes tem como principal função demonstrar que os erros estão

presentes em um software, e devem ser arrumados, aumentando assim a

operabilidade e confiabilidade de um software.

Page 19: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

19

2.3 Estratégia de Teste de Software

Na área de teste de software, podem ser identificados diferentes tipos de

teste, sendo assim, nesta seção serão descritas as estratégias de teste de software

existentes.

2.3.1 Teste de Unidade

Para Aniche (2014), o teste de unidade tem como características a

verificação de erros dentro de um componente ou módulo específico de um

software.

De acordo com Teles (2004), os testes de unidade deverão ser escritos

pelos desenvolvedores no momento de codificação, fazendo com que tal atividade

faça parte da programação desde a primeira classe que é escrita até a última.

Teles (2004) afirma que o teste de unidade deverá ser utilizado em cinco

casos:

Quando a interface de um método ainda não estiver clara.

Quando uma interface estiver suficientemente clara, porém há uma

complexidade dentro do método.

Em situações incomuns nas quais o código deve funcionar da forma como

está escrito.

Ao localizar um problema no código que já está escrito no sistema.

Quando percebe a necessidade da realização de um refactoring em um

código.

Essa estratégia delimita a descobertas de erros, visto que o escopo é

bastante restrito (a um único componente), garantindo assim que as informações

estejam fluindo adequadamente dentro dos componentes.

2.3.2 Teste de Integração

Page 20: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

20

Conforme os testes de unidades forem concluídos, o passo seguinte é o

teste de integração. Esse teste verificará que a integração entre duas ou mais

interfaces não gere nenhum tipo de defeito, apesar das interfaces terem sido

testadas unitariamente.

Pressman (2002) define que o teste de integração é uma forma sistemática

para construir estruturas do programa e, ao mesmo tempo, para descobrir erros

associados às interfaces que nela integram.

O objetivo é fazer com que os componentes que forem testados

unitariamente tomem a forma de um programa que segue as especificações do

projeto.

Tais testes permitirão que os erros sejam isolados e de fácil identificação e

correção. Existem duas estratégias principais que podem ser utilizadas na

elaboração dos testes de integração:

Teste de integração descendente (top down), na qual serão definidos

módulos que deverão ser integrados de forma descendentes pela hierarquia

de controle, começando pelo módulo de controle principal até os módulos

subordinados.

Teste de integração ascendente (bottom up), na qual serão definidos testes

de módulos atômicos (componentes de níveis baixos do sistema) subindo na

hierarquia até o componente de alta relevância.

Com a integração do sistema com diferentes módulos, é destacada a

necessidade do teste de integração, para que ao final do desenvolvimento do

projeto, o software apresente uma estrutura de qualidade, reduzindo a probabilidade

de que um erro seja encontrado após a sua entrega.

2.3.3 Teste de Sistema

O teste de sistema tem como finalidade realizar a validação por completo de

um sistema, seja ela um hardware, pessoal e informacional.

Page 21: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

21

Pressman (2002) define que o teste de sistema deve exercitar por completo

o sistema baseado em computador, tendo em vista que cada teste tem uma

finalidade distinta, verificando se os elementos foram integrados e executados de

maneira adequada a funções por elas atribuídas.

Assim, o teste de sistema garantirá que o software seja adequadamente

testado por completo.

2.3.4 Teste de Validação

Para Pressman (2002), o teste de validação pode ter várias definições,

porém a mais simples (no entanto rigorosa), é que tal teste será bem sucedido

quando o software funciona de maneira esperada pelo cliente.

Logo, pode-se dizer que o teste de validação é realizado quando se obtém

uma resposta positiva de um cliente perante o software desenvolvido pela empresa.

2.3.5 Modelo V

O modelo V representa como cada estratégia de teste de software deve ser

utilizada para verificar ou validar diferentes artefatos gerados durante o processo de

desenvolvimento, como representado na Figura 2

Figura 2 Modelo V

Fonte: José Carlos Marcoratti (2014)

Page 22: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

22

A Figura 2 representa o modelo V, que de acordo com o Neto (2014),

descreve de forma paralela as atividades que envolvem a área de desenvolvimento

e os testes de software por ela validadas.

O modelo descreve que o planejamento e o projeto dos testes devem

ocorrer de cima para baixo, ou seja, o teste de aceitação é planejado considerando

os artefatos da especificação de requisitos, que passará ao planejamento de teste

de sistema a partir do projeto de alto nível, onde o teste de integração dependerá de

um projeto detalhado, que por fim o teste de unidade será planejado a partir da

codificação.

2.4 Abordagem de Teste de Software

Uma das boas práticas de teste de software segundo Pressman (2002), é o

planejamento antecipado dos testes, possibilitando assim a condução de maneira

sistemática dos mesmo.

Sendo assim, uma estratégia de teste de software irá definir um gabarito de

testes pré-definidos o qual deverá apresentar as seguintes características:

Os testes deverão iniciar em nível de unidade (classes ou objetos), chegando

ao sistema por completo.

Devem ser utilizadas técnicas diferentes adequando-a a diferentes

momentos.

Os testes deverão ser conduzidos pelo desenvolvedor, com exceção a

grandes projetos, os quais deverão ser conduzidos por um grupo

independentes de teste.

De acordo com Pressman (2002), o processo de depuração irá resultar na

remoção dos erros, possuindo assim uma definição diferente de testes.

Uma boa estratégia de teste deverá conter desde testes de baixo nível, que

devem verificar componentes isolados de código, até os de alto nível que irão validar

as principais funções do sistema, segundo os requisitos levantados pelo cliente.

Page 23: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

23

Pressman (2002) destaca que uma estratégia de teste deve fornecer

diretrizes tanto para o profissional, quanto para o gerente assim que a pressão para

a entrega do projeto começa a crescer, fazendo com que os problemas surjam tão

cedo quanto possível.

2.5 Visões Interna e Externa do Teste

Dentro da área de teste de software, percebe-se que há dois tipos de visões,

a interna e externa. A próxima seção apresentará cada uma dessas visões.

2.5.1 Teste Caixa-Branca / Estrutural

Para Pressman (2002), o teste de caixa-branca, também conhecido como

teste caixa de vidro, é um método que usa a estrutura de controle do projeto

procedimental para derivar casos de teste, ou seja, o código fonte.

Tal teste permite que o Engenheiro de Software selecione partes do código-

fonte nas quais serão executados uma série de testes, avaliando assim se a

execução de tal parte do código-fonte está funcionando de maneira correta.

Sendo assim, um dos principais objetivos é garantir que os caminhos sejam

exercitados pelo menos uma vez, passando por todas as decisões lógicas, sejam

elas verdadeiras ou falsas e podendo verificar também o limite do sistema.

2.5.2 Teste Caixa-Preta / Funcional

De acordo com Pressman (2002), o teste de caixa-preta, também conhecido

como teste comportamental, tem como foco validar os requisitos funcionais de um

software, permitindo assim que o Engenheiro de Software análise todos os requisitos

através da entrada de dados, gerando assim um conjunto de saídas de acordo com

suas especificações.

Para Pressman (2002) o teste de caixa-preta tenta localizar erros das

seguintes categorias: funções incorretas ou omitidas, erros de interface, erros de

Page 24: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

24

estrutura de dados ou de acesso a base de dados externa, erros de comportamento

ou desempenho e erros de iniciação e término.

Sendo assim, o teste deverá ser realizado no período em que a aplicação

está quase ou totalmente finalizada, pois ele despreza a estrutura de controle na

qual a sua atenção seja totalmente dedicada nas informações que são tratadas.

2.6 Métodos Ágeis

Soares (2004) descreve que métodos ágeis se tornaram popular no ano de

2001, quando desenvolvedores de software apresentaram os métodos Scrum,

Extreme Programming, entre outros, estabelecendo princípios comuns que foram

compartilhados entre métodos de desenvolvimento no chamado Manifesto Ágil.

O manifesto ágil destaca os seguintes princípios para o desenvolvimento de

software:

Indivíduos e interações, onde antes eram utilizados processos e ferramentas;

Software executável, onde antes era utilizado principalmente a

documentação;

Colaboração do cliente, onde antes as negociações eram feitas através de

contratos;

Respostas rápidas a mudanças, onde antes se cumpria metas;

Soares (2004) define ainda que o manifesto ágil não rejeita a forma como

era elaborada o software antigamente, mas demonstra que eles terão importância

secundária no desenvolvimento.

2.6.1 Extreme Programming (XP)

Soares (2004) define que o XP é uma metodologia para pequenas e médias

equipes que desenvolvem software baseado em requisitos vagos e que poderão se

modificar rapidamente.

Page 25: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

25

Dentre as principais características que a metodologia traz consigo, na qual

possibilita se diferenciar das demais, são seus feedback constantes, contendo uma

abordagem incremental em que a comunicação entre as pessoas envolvidas seja

maior.

Sendo assim, Teles (2004) afirma que o XP busca assegurar que o cliente

receba o máximo de valor da equipe de desenvolvimento, pois sua organização gira

em torno de valores e práticas que atuam de forma harmônica e coesa, assegurando

assim que o cliente receba um alto retorno de seu investimento.

O método XP além de enfatizar o desenvolvimento ágil, também visa

garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas,

proporcionando assim que seus seguidores tenham um agradável ambiente de

desenvolvimento, conduzindo-o aos quatro valores do método, a comunicação,

simplicidade, feedback e coragem.

Para que os valores do método XP sejam cumpridos, Teles (2004) afirma

que tal método possui práticas que auxiliam na evolução do software com segurança

e agilidade e essas práticas são: cliente presente, jogo do planejamento, stand up

meeting, programação em par, desenvolvimento guiados pelos testes, refactoring,

código coletivo, código padronizado, design simples, metáfora, ritmo sustentável,

integração contínua, releases curtos.

2.6.2 TDD

Para Aniche (2014) o TDD é uma prática de desenvolvimento de software,

sugerida por algumas metodologias ágeis, como o XP. Seu foco principal é fazer

com que o princípio de seu desenvolvimento seja guiado por meio de testes

automatizados. Sendo assim, o desenvolvedor deverá gerar o teste antes da

geração do software, na qual irá gerar um código simples e de qualidade. Tal

desenvolvimento, possui características cíclicas, conhecidas como ciclo do

vermelho-verde-refatora, como demonstrado na Figura 3:

Page 26: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

26

Figura 3 Ciclo Desenvolvimento Vermelho-Verde-Refatora

A Figura 3 demonstra que o desenvolvimento terá início com uma falha de

um teste automatizado, representada pela cor vermelha, seguindo pela passagem

de teste, representada pela cor verde, dando por finalizada a refatoração do código,

alcançando o melhor código.

O primeiro passo desse ciclo, é gerar um código de teste que falhará,

representado pela cor vermelha. Após gerar esse código, o programador deve gerar

o código-fonte que validará o teste, representado pela cor verde. Por fim, o código

deverá ser refatorado, assim como representado pela cor roxa.

Para Aniche (2014) a utilização de tal ciclo pode ser vantajosa no

desenvolvimento, visto que tal prática tem como foco o teste e não a implementação,

ou seja, o código surge por meio de testes.

Aniche (2014) destaca que o TDD maximiza a quantidade de feedback sobre

o código que está sendo produzido. Tal processo antecipa os problemas, e, por

consequência, diminuir os custos de manutenção.

No entanto, de acordo com Canfora, et al. (2006), a prática do TDD não é

uma garantia de que seu código possua qualidade, visto que, tal prática apresenta

resultados preliminares do seu código enquanto escrito.

Page 27: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

27

3 TRABALHOS RELACIONADOS

O trabalho de Hammont e Umphress (2012) apresenta um estudo sobre a

utilização da prática do TDD entre profissionais da área de TI de forma qualitativa.

Neste trabalho é apresentado que 53% dos 293 profissionais na área de TI, testaram

a prática do TDD e aproximadamente 50% indicariam o uso do TDD no processo de

desenvolvimento.

Porém Canfora, et al.(2006) destacam em suas pesquisas quantitativas que

comparam a utilização do TDD com o testes após implementação, que apesar da

prática do TDD ser mais precisa do que a metodologia do teste após a programação,

o TDD requer mais tempo de programação do que a forma convencional.

Já pesquisas realizadas por Aniche e Gerosa (2012) apontam de maneira

qualitativa, que diferentemente do esperado, a maioria dos profissionais, que

realizaram exercícios elaborados pelos autores, na qual os participantes se

submetiam a problemas do cotidiano a classes e métodos em diversos projetos de

software, afirmam que as classes e métodos originários pela prática da programação

orientada a testes, o TDD, não seriam diferente do que a forma convencional de

programação.

Em uma outra pesquisa realizada por Adan Causevic, et al. (2011), é

apresentado de maneira qualitativa que a adaptação industrial na utilização da

prática do TDD requer uma melhor organização para a adoção de tal prática, visto

que dentre 18 efeitos identificados em diversas áreas pelos autores observadas, 7

representam fatores limitadores para a utilização do TDD.

Uma das pesquisas refletiram diretamente no desenvolvimento deste

trabalho, como o tempo abordada por Canfora, et al.(2006). Neste trabalho, era

necessária a implementação de testes antes do desenvolvimento do software para

clínicas odontológicas, o que necessitou um tempo maior para a implementação.

Page 28: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

28

4 MÉTODO

Para a condução do trabalho, foi utilizado o método de pesquisa-ação, a

qual Tripp (2005) estabelece um processo cíclico que aprimora a prática por meio da

execução das atividades de agir, descrever, avaliar e planejar. Esse método é

ilustrada na Figura 4.

Figura 4 Ciclo da Pesquisa-Ação

Fonte: David Tripp (2005)

A Figura 4 demonstra o método de pesquisa-ação formado por quatro

passos, e a cada término de uma volta, aprimora-se a prática das atividades

relacionadas.

Neste trabalho, o ponto inicial do método foi a condução da etapa de

estudo, ou em outros termos, o planejamento, cujo o foco central foi a

compreensão dos diferentes tipos de estratégias de teste de software, assim como a

compreensão da utilização do método TDD dentro do processo de desenvolvimento

e de frameworks de testes automatizados como JUnit e Mockito.

Logo após a etapa inicial, foi conduzida a etapa de ação que, utilizou-se de

três projetos de software implementados com a linguagem de programação Java,

distintos entre si, porém com características em comuns, como na utilização do

padrão de projeto Model-View-Controller (MVC), e do framework JavaServer Faces

Page 29: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

29

(JSF) e um desses projetos utiliza todo o conceito estudado sobre o TDD em um

processo de desenvolvimento baseado em scrum, conforme apresentado na Seção

5.

Assim que a etapa de ação foi finalizada, foi realizada a etapa de avaliação.

Nesta etapa o principal foco foi a comparação dos três projetos. Esses projetos

conforme dito acima, utilizou o modelo MVC de programação, facilitando assim a

análise e a comparação. Uma maneira que possibilitou a comparação dos resultados

quantitativo, foi a utilização de métricas, isto permitiu realizar a comparação entre os

projetos. Tais métricas são: número de linhas, complexidade ciclomática, a

complexidade ciclomática por pacote e a qualidade de se utilizar o TDD.

Após a avaliação, foi realizada a etapa da descrição dos resultados. Nesta

etapa o principal foco foi descrever os resultados obtidos, ou seja, os resultados.

Tais resultados foram apresentados de maneira quantitativa e foi investigado se eles

eram desejado ou não e a dedução dos mesmos, conforme serão apresentados no

próximo capítulo.

Page 30: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

30

5 COMPARAÇÃO DE PROJETOS QUE UTILIZAM TDD E PROJETOS QUE NÃO

UTILIZAM

Nessa seção são reportados os resultados obtidos por meio da condução

desta pesquisa.

5.1 Descrições dos projetos

Nessa sub sessão serão apresentadas as características de cada projeto

utilizado para a pesquisa.

5.1.1 Projeto Oral Web

O Oral Web é um projeto de software voltado para clínicas odontológicas,

com o objetivo de organizar dados cadastrais de cliente e dentistas, além dos

horários de atendimento e o histórico de cada consulta feito pelo dentista aos seus

pacientes.

A implementação de tal projeto, foi baseada nas pesquisas realizadas sobre

o desenvolvimento guiado por teste de software, isto é, foi utilizado o método TDD,

no qual os testes são elaborados antes do código fonte.

Tal projeto teve como desenvolvedor o aluno Anderson Yoshiaki Iwazaki da

Silva, autor do trabalho.

5.1.2 Projeto Blog APS

O Blog APS, tem como funcionalidades a publicação de posts, possibilitando

que usuários que utilizam o mesmo programa realizar comentários, demonstrando a

sua opinião.

Esse projeto foi elaborado pelos alunos Anderson Y. Iwazaki da Silva e Hugo

Henrique Derney de Aguiar, da Universidade Tecnológica Federal do Paraná

Page 31: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

31

(UTFPR), referente a uma Atividade Prática Supervisionada (APS) da matéria de

Tópicos de Computação.

Tal projeto não contém classes que realizam testes de validação dos

códigos, ou seja, tal projeto foi programado na forma convencional de programação,

primeiro a elaboração de linha de códigos e depois a realização de testes via uso

manual do programa.

5.1.3 Projeto Chat

O Chat tem como característica a elaboração de um programa que

possibilita que pessoas se comuniquem umas com as outras através de uma linha

de amizades existentes.

Tal programa também foi uma APS da matéria de Tópicos de Computação,

porém seus desenvolvedores são os alunos Luciano Henrique Quintino e Renato

Zeola Moselli, ambos da UTFPR.

Assim como o projeto do Blog APS, o Chat também é um sistema que

utilizou a forma convencional de programação, os testes sendo feito após o término

da programação e de forma manual.

5.2 Resultados

Conforme dito em seções anteriores, os resultados apresentados neste

trabalho se baseou em resultados quantitativos, que por sua vez foram

representados em forma de gráficos. Tais gráficos representam resultados obtidos

através de métricas, que de acordo com Pressman (2002) são utilizados tais

medidas para compreender melhor o que se foi elaborado, possibilitando avaliar a

qualidade dos produtos construídos.

O primeiro framework utilizado para calcular as métricas definidas

anteriormente, ou seja, o número de linhas, a complexidade ciclomática e o

complexidade ciclomática por pacotes, é denominado SonarQube, possibilitou a

obtenção das métricas de quantidade de linhas de cada projeto e a complexidade

Page 32: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

32

por pacotes. Já o segundo framework conhecido como Java NCSS possibilitou a

obtenção da métrica de complexidade ciclomática.

A utilização da métrica de número de linhas, tem como principal foco é

compreender o tamanho de determinados produtos de um software (Duarte, Falbo;

2000). Sendo assim, a análise a seguir apresenta número total de linhas que cada

projeto utilizou para o seu funcionamento, desconsiderando os códigos associados

aos testes implementados no projeto Oral Web, conforme demonstrado no Gráfico a

seguir.

Gráfico 1 Número de Linhas

No Gráfico 1, percebe-se que o projeto que utiliza o TDD, apresenta um

número maior de linhas do que apresentado no Blog APS e no Chat. Tal resultado

significa que o projeto que utiliza a prática é maior que as demais, podendo resultar

em uma maior complexidade, conforme Pressman (2002) que demonstra de maneira

teórica que o tamanho de um software são concebidas através da normalização das

medidas de qualidade e/ou produtividade.

De acordo com Racadon (2015), a complexidade de um projeto é

incrementada de acordo com as chamadas “palavras-chaves”, como: if, else, while,

Page 33: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

33

case, catch, throws, return (quando não utilizado no final do método), &&, ||, ?,

conforme apresentado no Exemplo 1 a seguir:

Exemplo 1 – Cálculo da Complexidade

Fonte: David Racadon (2005)

O resultado da complexidade dos projetos, é ilustrado no Gráfico a seguir:

Gráfico 2 Complexidade

No Gráfico 2 é ilustrado que a complexidade do projeto que utiliza o TDD é

maior do que a complexidade em que o TDD não é utilizado. Isso também pode ser

percebido no gráfico apresentado a seguir, que demonstra a complexidade de cada

pacote:

Page 34: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

34

Gráfico 3 Complexidade por pacote

No Gráfico 3 é apresentado que a complexidade do pacote Util do projeto

que utiliza o TDD é maior que os demais, porém nos pacotes seguintes há uma

variação na complexidade, onde o Chat apresenta a maior complexidade no pacote

Dao e o Blog APS apresenta uma complexidade maior no pacote controller.

A complexidade ciclomática de cada projeto, que de acordo com Pressman

(2002), é a métrica que representa a medida quantitativa da complexidade lógica de

um programa, cujo o seu valor definirá o número de caminhos independentes

demonstrando que o mesmo tenha sido validado ao menos uma vez.

Pressman (2002) relata três maneiras para a realização do cálculo da

complexidade ciclomática:

O primeiro é contagem do número de regiões do grafo de fluxo

correspondente a complexidade ciclomática;

A segunda forma de realizar o cálculo é através da seguinte fórmula:

V(G) = E – N + 2, visto que V(G) corresponde a complexidade

ciclomática, E representa o número de atrestas do grafo e o N

representa o número de nós.

A última forma de realização do cálculo da complexidade ciclomática

se dá através da fórmula V(G) = P + 1, visto que V(G) novamente

Page 35: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

35

representa a complexidade ciclomática e P representa o número de

predicados contido no grafo do fluxo G.

Para uma melhor compreensão de como tais cálculos são realizados, as

Figura 5, 6 e 7 demonstram o fluxograma, o grafo de fluxo e lógica composta:

Figura 5: Fluxograma

Fonte: Roger S. Pressman (2002)

Figura 6: Grafo de Fluxo

Fonte: Roger S. Pressman (2002)

Page 36: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

36

Figura 7: Lógica Composta

Fonte: Roger S. Pressman (2002)

Através das Figuras 5, 6 e 7, pode-se perceber que há 4 regiões, possui 11

arestas, 9 nós e 3 nós predicados, sendo assim os resultados dos cálculos dito

anteriormente o resultado de tais cálculos ficaram da seguinte forma:

O grafo de fluxo apresentaram 4 regiões;

V(G) = 11 – 9 + 2 = 4;

V(G) = 3 + 1 = 4;

Com isso o resultado de tal métrica nos projetos implementados neste

trabalho é ilustrado na figura a seguir:

Gráfico 4 Complexidade Ciclomática

Page 37: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

37

No Gráfico 4, é ilustrado que o projeto que apresenta a maior complexidade

ciclomática é o Blog APS, e o projeto que utilizou o TDD, apresentou a menor

complexidade ciclomática.

Com isso, pode-se dizer que os resultados obtidos suportam que o uso do

TDD não favoreceu o desenvolvimento de códigos com maior qualidade, pois tanto a

complexidade quanto a complexidade de cada pacote permite observar que com a

prática do TDD o projeto se apresentou mais complexo.

O fato de apresentar tal resultado, pode ser tanto pelo fato de que o projeto

pode ter um maior número de linhas, ou então, conforme apresentado no Gráfico 2,

o pacote Util carregar a maior complexidade do sistema.

Page 38: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

38

6 CONCLUSÃO

Neste trabalho foi apresentado o conceito de teste de software e a

importância de se utilizar esse conceito em prática dentro do desenvolvimento de

software, pois quanto mais cedo houver a localização de falhas no desenvolvimento,

menor será a manutenção de um software.

A utilização de métodos de desenvolvimento ágeis podem garantir que a

manutenção realmente possa ser menor que as demais, como o método XP, na qual

a participação do cliente é tão importante no desenvolvimento do software, visto que

o levantamento de requisitos podem ser vagos.

Para que possa se obter um feedback sobre o andamento do

desenvolvimento, a prática do TDD pode ser uma boa escolha perante a falhas de

sistema, visto que a elaboração de testes é realizada antes da elaboração do

código.

No entanto, tal prática não fornece garantia de que o software não

apresentará problemas futuros e muito menos que a qualidade do software será

melhor que a de um outro software que não utilizou a prática do TDD, pois isto pode

depender da experiência de cada programador.

Tal fato se reflete na pesquisa, que demonstra que os resultados obtidos não

eram compatíveis com os benefícios do uso de TDD mencionados em trabalhos

relacionados. A prática do TDD, conforme reportado em trabalhos relacionados,

busca a simplicidade e uma menor complexidade dos códigos, um resultado um

tanto quanto inverso ao observado no estudo de caso conduzido neste trabalho, que

demonstrou que a complexidade do mesmo foi maior que a dos demais projetos

abordados.

Uma das limitações deste trabalho é o fato de ela se encontra muito isolado,

visto que ela está sendo abordado encima de três projetos que possuem as mesmas

características. Isto pode resultar em um trabalho mais elaborado baseado em

outros projetos com o mesmo os mesmo requisitos, possibilitando uma melhor

analise abordado sobre esta pesquisa.

Page 39: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

39

7 REFERÊNCIA BIBLIOGRÁFICA

ANICHE, Maurício. Test-Driven Development – Teste e Design no Mundo Real

com Java. São Paulo: Casa do Código, 2014.

ANICHE, Maurício F.; GEROSA Marco Aurélio. How the Practice of TDD

Influences class Design in Object-Oriented Systems: Patterns of Unit

Tests Feedback. In 26th Brazilian Symposium on Software Engineering

(SBES). pp. 1-10, 2012.

BATER, Bert; SIERRA, Kathy. Use a Cabeça! – Java. 2ª ed. Rio de Janeiro: Alta

Book Editora, 2009. Aldir José Coelho (trad.).

BECK, Kent. TDD desenvolvimento guiado por testes. Porto Alegre: Bookman,

2010. Jean Felipe P. Cheiran (trad.).

CANFORA, Geraldo; CIMITILE, Aniello; et al. Evaluating Advantages of Test

Driven Development: a Controlled Experiment with Professionals. In

Empirical Software Engineering and Measurement (ESEM). pp. 364-371, 2006.

CAUSEVIC, Adan; SUNDMARK, Daniel; et al. Factors Limiting Industrial

Adoption of Test Driven Development: A Systematic Review. In 4th

International Conference on Software Testing, Verification and Validation

(ICST). pp. 337-346, 2011.

DE MELO, Alexandre Altair; LUCKOW, Décio Heinzelmann. Programação Java

para a Web. São Paulo: Novatec, 2010.

Page 40: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

40

DUARTE, Katia Cristina; FALBO, Ricardo de Almeida. Uma Ontologia de

Qualidade de Software. Workshop de Qualidade de Software, João Pessoa.

pp. 275 – 285, 2000.

HAMMOND, Susan; UMPHRESS, David. Test Driven Development: The State of

the Practice. In Proceedings of the 50th Annual Southeast Regional

Conference (ACM-SE ‘12). pp. 158-163, 2012.

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software –

Aprenda as metodologias e técnicas mais modernas para o

desenvolvimento de software. 2ª ed. São Paulo: Novatec, 2007.

NETO, Arilo C. Dias. Introdução a Teste de Software. Disponível em: <

http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-

de-software/8035>. Acessado no dia: 14/10/2015.

PRESSMAN, Roger S.. Engenharia de Software. 5ª ed. Rio de Janeiro: McGraw-

Hill, 2002. Tony Coelho, Sandra B. de Carvalho (trad.).

RACADON, David. Metrics – Complexity. Disponível em:

<http://docs.sonarqube.org/display/SONAR/Metrics+-+Complexity>. Acessado

no dia: 19/11/2015.

SOARES, Michel dos Santos. Metodologias Ágeis Extreme Programming e

Scrum para o Desenvolvimento de Software. Revista Eletrônica de Sistemas

de Informação. vol. 3, p. 8-13, 2004.

Page 41: TDD Test Driven Development: Uma investigação sobre a ...repositorio.roca.utfpr.edu.br/jspui/bitstream/1/... · torna-se necessário a realização de atividades de teste de software

41

TELES, Vinicius Manhães. Extreme Programming – Aprenda como encantar

seus usuários desenvolvendo software com agilidade e alta qualidade.

São Paulo: Novatec, 2004.

TRIPP, D. Pesquisa-ação: uma introdução metodológica. Educ. Pesqui., v.31, n.

3, 2005.


Recommended