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.
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.
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
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
10 LISTA DE EXEMPLOS
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á
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
13
5.1.3 Projeto Chat ... 31
5.2 Resultados ... 31
6 CONCLUSÃO ... 38
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.
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
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:
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.
