O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE

Transcrição

1 O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo aborda o tema sobre a relevância da metodologia TDD Test Driven Development e os tipos de testes que são utilizados no desenvolvimento de um sistema computacional. A finalidade é de apresentar a utilização da técnica de TDD na implementação de um produto de software. O Projeto desenvolvido usou a framework JSF, JPA, na linguagem JAVA e plataforma NetBeans. 1. Introdução TDD é uma das práticas de desenvolvimento de software sugeridas por diversas metodologias ágeis, como XP. A ideia é fazer com que o desenvolvedor escreva testes automatizados de maneira constante ao longo do desenvolvimento. Mas diferentemente do que estamos acostumados. TDD sugere que o desenvolvedor escreva o teste antes mesmo da implementação [ANICHE, 2012]. A ideia dessa técnica é desenvolver um caso de teste antes mesmo de começar a escrever o código de produção. Ao escrever os testes antes, garante que o desenvolvedor tenha uma boa parte ou todo o sistema funcionando. O objetivo desse trabalho é desenvolver uma aplicação web para uma empresa de varejo utilizando o paradigma de TDD para testar as validações das funcionalidades, como: regra de negocio, integração com sistemas externos, citando o banco de dados e servidor web. Os testes foram feitos em uma classe Java, sem persistir no banco, antes mesmo de criar as classes controller, dao, ou páginas web. 2. Metodologia O artigo foi desenvolvido por revisões bibliográficas em livros, artigos e sites da internet. 3. Test driven development A definição de TDD segundo Massol e Husted [2005] em seu livro JUnit em ação é uma prática de programação que ensina os desenvolvedores a escreverem novos códigos, somente se um teste automatizado falhar e a eliminar a duplicação, sendo que a meta dessa metodologia é o código limpo que funciona. É um processo de desenvolvimento de software que consiste em criar um código teste se o código real do projeto funciona como deveria. Isso significa que você cria os scripts de teste e depois o código de produção [LEMOS, 2014]. O funcionamento dessa metodologia segundo Aniche [2014] é bem simples, possui três ciclos: criar o teste que falha, faça o código passar no teste e por último

2 refatore o código. No primeiro ciclo, chamado de Test é onde o desenvolvedor cria um código que dê um erro, afinal as funcionalidades do teste ainda não foi implementada. No ciclo Code, que é a segunda etapa, o desenvolvedor escreve um código com as funcionalidades que consiga passar no Test. E por fim, refatorar o código, onde o objetivo é melhorar o mesmo que já está escrito e que está funcionando, atendendo os requisitos. A fim de escrever um código de qualidade, eliminando as redundâncias e deixando-o mais limpo. Assim que terminar de refatorar, o desenvolvedor passa para a próxima funcionalidade. Podemos conferir na figura 1 a representação do ciclo do TDD. Figura 1: Representação do Ciclo do TDD Fonte: [rafaelfranchi.wordpress.com/2012/01/25/o-que-e-tdd/] 4. Porque utilizar essa técnica? Conforme Aniche [2014], a utilização do TDD agrega várias vantagens e benefícios, o principal dele é a qualidade do produto de software. Todos os usuários de software já sofreram com algum erro no sistema, que aconteceu após uma atualização do mesmo. Isso acontece porque o desenvolvedor não está acostumado a testar, por achar o procedimento muito demorado, e financeiramente custoso para a empresa. A questão é que mesmo que seja demorado e poder gerar um gasto a mais, fazer teste antes promove uma segurança maior na funcionalidade da aplicação, evitando que o erro aconteça quando o sistema já estiver em uso, podendo causar um prejuízo superior do que o gasto com o uso da técnica, gerando um constrangimento, insatisfação e perder a confiança do cliente. 5. Teste automatizado Uma maneira de conseguir testar o sistema todo é automatizando os testes, utilizando frameworks, que executa um teste de um código de uma funcionalidade que foi escrita, esse tipo de teste chama-se teste de unidade [MASSOL e HUSTED, 2005]. Testes automatizados são programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verificações automáticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem, é que

3 6. Tipos de testes todos os casos de testes podem ser facilmente e rapidamente repetidos a qualquer momento e com pouco esforço Na grande maioria das vezes, os testes automatizados são escritos programaticamente, por isso é necessário conhecimento de programação [BERNARDO e KON, 2008]. Testes são empregados no desenvolvimento do projeto com a finalidade de encontrar problema ou futuros problema em um código. Existem três tipos de teste, o de unidade, é aquele que garante que uma classe funciona de maneira isolada do resto do sistema, o teste de integração, é aquele que testa a integração entre duas partes do sistema e de sistema que garante que o sistema funcione como um todo [ANICHE, 2014] Teste de unidade O teste de unidade não funciona dessa forma, ele trabalha fazendo teste em pequenos trechos de códigos ou pequenas classes, quando se trata de softwares orientados a objetos. Ele está motivado a saber se aquela pequena parte do sistema realmente está funcionando da forma correta. O correto é utilizar uma bateria de testes de unidade para cada uma dessas classes [ANICHE, 2012]. Como diz Bernardo e Kon [2008], o teste de unidade é o tipo de teste mais importante, já que ele está focado em saber se aquele trecho de código produz o resultado esperado, como esse tipo de teste faz a validação em pequenos blocos, os erros são mais facilmente encontrados e facilita também propor uma solução mais rapidamente. Segundo Aniche [2012], uma vantagem desse tipo de teste é a facilidade de escrever e a rapidez de execução, uma desvantagem é que eles são simulam bem o mundo real Teste de integração Conforme Aniche [2012], teste de integração é utilizado quando o desenvolvedor sente a necessidade de fazer a integração da classe com um sistema externo, ou seja, banco de dados. Testar os códigos desenvolvidos nas classes DAO, como se os códigos SQL estão funcionando corretamente e garantir que as classes estão se comunicando bem com o serviço web. Vantagem é que se o teste for muito complexo, o teste automatizado pode facilitar, uma desvantagem desse teste é que ele pode se tornar complicado, caso um teste exija que o banco de dados deva conter informações pré-salvas Teste de sistema Teste de sistema é o teste que garante que o sistema funciona como um todo, já que ele é realizado com a aplicação em execução, se for um software web, o servidor de aplicação já deve estar rodando, com telas prontas e persistindo no banco de dados [ANICHE, 2014]. Um teste de sistema é aquele que é idêntico ao executado pelo usuário da aplicação. Levando em consideração que é uma aplicação web, esse teste deve então subir no browser, clicar em links, submeter a formulários, etc. A vantagem desse tipo de teste é que ele consegue encontrar problema que só ocorrem no mundo real, como problemas de integração entre a aplicação e banco de dados, e etc. Outra vantagem é que se a integração for muito complexa o TDD provavelmente ajudará a entender o problema, a desvantagem é que eles geralmente são mais difíceis de serem escritos e levam muito mais tempo para serem executados [ANICHE, 2012].

4 Visa verificar se o software que foi implementado atende exatamente o que o cliente solicitou. Para realizar esse tipo de teste é necessário a simulação das ações de um usuário interagindo com o programa. Esse tipo de teste é bem amplo, já que ele envolve todas as camadas do sistema, como a modelagem da estrutura da base de dados e também depende do funcionamento de outros módulos [BERNARDO e KON, 2008]. 7. Vantagens de utilizar essa técnica Sabemos que utilizar TDD pode ser muito produtivo, quando usado corretamente, e que o objetivo dessa técnica é produzir um software com qualidade. Em concordância com Ribeiro [2010], TDD é uma prática que visa aumentar a velocidade da entrega de produtos através da simplificação das atividades de desenho de software. Já Aniche [2012], cita algumas vantagens em seguir o ciclo do TDD, como: Foco no teste e não na implementação, quando se começa o projeto pelo teste o programador mantém o foco somente na classe que está sendo testada e esquece a implementação, fazendo com que ele consiga pensar em melhores possibilidades de teste para a classe sob desenvolvimento. Código nasce testado, se o ciclo de teste é praticado corretamente, o código de produção consequentemente já terá passado por um teste de unidade, verificando que a funcionalidade está funcionando corretamente. Simplicidade, como uma etapa do ciclo é refatorar código, o desenvolvedor busca sem pelo código mais simples constantemente e acaba por fugir de soluções complexas, comuns em todos os sistemas. Melhor reflexão sobre o design da classe, ao começar pelo teste, o desenvolvedor pensa sobre como sua deverá se comportar perante as outras classes do sistema. Sem causar a falta de coesão ou excesso de acoplamento no código, que acontece quando o individuo pensa somente na implementação. 8. Quando não utilizar o TDD Analisamos anteriormente que o TDD é muito útil em códigos com um grande grau de complexidade e também quando o desenvolvedor não sabe como lhe da com o presente problema, pois ele traz retornos constantemente a respeito do código, mas como todas as técnicas, ele também possui alguns pontos negativos. De acordo com Aniche [2012], TDD não se mostra tão eficiente durante uma implementação de um DAO, que é uma classe que faz integração com outros sistemas externos, melhor dizendo: banco de dados, servidor web, entre outros, onde não há necessidade de feedback em relação a qualidade do código e do projeto das classes, pois são códigos com funcionalidades simples. Um momento também que não convém a utilização do mesmo é quando o desenvolvedor já sabe como resolver o problema, tanto na implementação, quanto no design. Já para Lemos [2014], TDD é caro, porque segundo ele o desenvolvimento do projeto levará mais tempo e recrutará mais programadores. Escrever códigos de testes antes demora mais para o projeto ser lançado. Outro caso que pode tornar o dessa prática a inimiga de programadores é o código de produção, se esse estiver complicado, se não estiver nos padrões de qualidade o código de teste também se torna complicado, causando o grande ponto negativo dessa técnica, a lentidão no processo da equipe de teste e stress, por ter que refatorar o código. Testes não são funcionalidades. São apenas verificações. Para muitos desenvolvedores, gastar muito tempo escrevendo testes faz com que se

5 9. Considerações finais sintam muito menos produtivos, porque eles precisam gastar muito mais tempo para ver o resultado final [LEMOS, 2014]. A técnica de TDD é utilizada por programadores como estratégias para o desenvolvimento de software. Com os constantes feedbacks dos testes, o TDD contribui significativamente para a qualidade do projeto, podendo contar com frameworks para automatizar a manipulação de problemas complexos, quando se trata em debugar centenas ou milhares linhas de códigos. 10. Referência Aniche, M. (2012) Test-Driven Development: Teste e Design no Mundo Real. 1ª ed. São Paulo: Casa do Código. Massol, V.; Husted, T. (2005) JUnit em Ação. 1ª ed. Rio de Janeiro: Ciência Moderna. Bernardo, P. C.; Kon, F. (2008) A Importância dos Testes Automatizados. Disponível em: < Acesso em: 22/07/2015. Aniche, M. (2014) TDD. Disponível em: <tdd.caelum.com.br/>. Acesso em: 21/07/2015. Aniche, M. (2014) Unidade, Integração ou Sistema? Qual teste fazer? Disponível em: <blog.caelum.com.br/unidade-integracao-ou-sistema-qual-teste-fazer/>. Acesso em: 31/07/2015. Franchi, R. (2012) O que é TDD? Disponível em: <rafaelfranchi.wordpress.com/2012/01/25/o-que-e-tdd/>. Acesso em: 21/07/2015. Lemos, M. (2014) 7 Motivos Porque TDD Falhou em ser Mais Utilizado. Disponível em: <imasters.com.br/desenvolvimento/7-motivos-por-que-tdd-falhou-em-ser-maisutilizado/>. Acesso em: 03/04/2015. Ribeiro, C. L. (2010) A Relação Entre TDD e Qualidade de Software. Disponível em: < Acesso em: 03/08/2015.