tdd test driven development: uma investigação sobre a...
Post on 18-Jul-2020
1 Views
Preview:
TRANSCRIPT
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
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
3
FOLHA DE APROVAÇÃO
4
Dedico este trabalho à minha família.
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.
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.
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.
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
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
10
LISTA DE EXEMPLOS
Exemplo 1 ............................................................................................................. 33
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
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
13
5.1.3 Projeto Chat ................................................................................................. 31
5.2 Resultados ...................................................................................................... 31
6 CONCLUSÃO .................................................................................................... 38
7 REFERÊNCIA BIBLIOGRÁFICA ....................................................................... 39
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.
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
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.
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)
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.
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
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.
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)
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.
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
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.
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:
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.
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.
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
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.
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á
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
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,
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:
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
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)
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
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.
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.
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.
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.
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.
top related