ESTÁGIO CURRICULAR I E II

Transcrição

1 ANDERSON GEISON BORGES ESTÁGIO CURRICULAR I E II UTILIZAÇÃO DE FERRAMENTAS E PRÁTICAS PARA TESTES DE SOFTWARE EMPRESA: FÚRIA CEREBRAL INFORMÁTICA LTDA. SETOR: DESENVOLVIMENTO SUPERVISOR: EDUARDO KRÜGER ORIENTADOR: VALMOR ADAMI JR. CURSO DE TECNOLOGIA EM SISTEMAS DE INFORMAÇÃO CENTRO DE CIÊNCIAS TECNOLÓGIAS - CCT UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC JOINVILLE SANTA CATARINA - BRASIL MAIO DE 2010

2 iii APROVADO EM.../.../... Valmor Adami Junior Bach. Em Ciência da Computação UDESC 2002 Mestre em Automação Industrial UDESC 2006 Professor Orientador Edson Murakami Licenciado em Educação Física FEFIL 1987 Tecnólogo em Processamento de Dados FPTE 1993 Especialista em Desenvolvimento e Gerência de Projetos de Software FPTE/IBM 1997 Mestre em Ciência da Computação UFSC 2002 Doutor em Engenharia Elétrica USP 2006 Marco Aurélio Wehrmeister Bach. Em Ciência da Computação FURB 2001 Mestre em Ciência da Computação UFRGS 2005 Doutor em Computação UFRGS (Brasil) e Uni. Paderborn (Alemanha) 2009 Pós-Doutorado em Eng. de Automação e Sistemas 2010 Eduardo Krüger Bach. Em Ciências da Computação UDESC 2005 Supervisor da CONCEDENTE

3 iv Carimbo da Empresa UNIDADE CONCEDENTE Razão Social: Fúria Cerebral Informática LTDA. CGC/MF: / Endereço: R. Lagamar, 19 Bairro: Bom Retiro CEP: Cidade: Joinville UF: SC Fone: Supervisor: Eduardo Krüger Cargo: Desenvolvedor ESTAGIÁRIO Nome: Anderson Geison Borges Matrícula: Endereço: R. Petrópolis 1725 Bairro: Petrópolis CEP: Cidade: Joinville UF: SC Fone: Curso de: Tecnologia em Sistemas de Informação Título do Estágio: Utilização de Ferramentas e Práticas para Testes de Software Período: 28/04/2010 a 30/06/2010 Carga horária: 270 AVALIAÇÃO FINAL DO ESTÁGIO I E II PELO CENTRO DE CIÊNCIAS TECNOLÓGICAS Representada pelo Professor Orientador: Valmor Adami Jr. CONCEITO FINAL DO ESTÁGIO I E II Excelente (9,1 a 10) Muito Bom (8,1 a 9,0) Bom (7,1 a 8,0) Regular (5,0 a 7,0) Reprovado (0,0 a 4,9) NOTA ETG I (Média do Processo) NOTA ETG II (Média do Processo) Rubrica do Professor da Disciplina Joinville / /

4 v Nome do Estagiário: Anderson Geison Borges QUADRO I AVALIAÇÃO NOS ASPECTOS PROFISSIONAIS Pontos QUALIDADE DO TRABALHO: Considerando o possível. 5 ENGENHOSIDADE: Capacidade de sugerir, projetar, executar modificações ou inovações. 5 CONHECIMENTO: Demonstrado no desenvolvimento das atividades programadas. 5 CUMPRIMENTO DAS TAREFAS: Considerar o volume de atividades dentro do padrão razoável. 5 ESPÍRITO INQUISITIVO: Disposição demonstrada para aprender. 5 INICIATIVA: No desenvolvimento das atividades. 5 SOMA 30 QUADRO II AVALIAÇÃO DOS ASPECTOS HUMANOS Pontos ASSIDUIDADE: Cumprimento do horário e ausência de faltas. 5 DISCIPLINA: Observância das normas internas da Empresa. 5 SOCIABILIDADE: Facilidade de se integrar com os outros no ambiente de trabalho. 5 COOPERAÇÃO: Disposição para cooperar com os demais para atender as atividades. 5 SENSO DE RESPONSABILIDADE: Zelo pelo material, equipamentos e bens da empresa. 5 SOMA 25 PONTUAÇÃO PARA O QUADRO I E II Sofrível - 1 ponto, Regular - 2 pontos, Bom - 3 pontos, Muito Bom - 4 pontos, Excelente - 5 pontos LIMITES PARA CONCEITUAÇÃO AVALIAÇÃO FINAL Pontos De 57 a SOFRÍVEL SOMA do Quadro I multiplicada por De 102 a REGULAR SOMA do Quadro II multiplicada por 3 75 De 148 a BOM SOMA TOTAL 285 De 195 a MUITO BOM De 241 a EXCELENTE Nome da Empresa: Fúria Cerebral Ltda. Representada pelo Supervisor: Eduardo Krüger CONCEITO CONFORME SOMA TOTAL EXCELENTE Rubrica do Supervisor da Empresa Local: Joinville Data : 19/06/2010 Carimbo da Empresa

5 vi UDESC UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS - FEJ PLANO DE ESTÁGIO CURRICULAR I E II ESTAGIÁRIO Nome: Anderson Geison Borges Matrícula: Endereço: R. Petrópolis, 1725 Bairro: Petrópolis CEP: Cidade: Joinville UF: SC Fone: (047) Endereço (Local estágio): R. Lagamar, 19 Bairro: Bom Retiro CEP: Cidade: Joinville UF: SC Fone: (047) ander.gborges@gmail.com Regularmente matriculado no semestre: 5 Curso: TSI Formatura (prevista) Semestre/Ano: 02/2010 UNIDADE CONCEDENTE Razão Social: Fúria Cerebral Informática LTDA. CGC/MF: / Endereço: R. Lagamar, 19 Bairro: Bom Retiro CEP: Cidade: Joinville UF: SC Fone: (047) Atividade Principal: Desenvolvedor Supervisor: Eduardo Krüger Cargo: Desenvolvedor DADOS DO ESTÁGIO Área de atuação: Desenvolvimento de software Departamento de atuação: Desenvolvimento Fone: (047) Horário do estágio: 08:00-14:00 Total de horas do Estágio: 6 Período: De 28/04/2010 à 30/06/2010 Total de horas semanais: 30 Nome do Professor Orientador: Valmor Adami Junior Departamento: Ciências da Computação Disciplina(s) simultânea(s) com o estágio Quantas: 6 Quais: GPR, MCI-SI, PES-SI, REC, TES-02, TES-09 OBJETIVO GERAL Implantar metodologias de desenvolvimento de softwares que priorizem a qualidade, utilizando testes unitários, testes de integração e a utilização de ferramentas que auxiliam nesse processo.

6 ATIVIDADES OBJETIVO ESPECÍFICO 1. Pesquisar sobre TDD Aplicar metodologia 1.1. Pesquisar como é utilizado TDD (Test Driven 1.2. Pesquisar JUnit Development) no 1.3. Pesquisar como funcionam os Mock Objects projeto Agil ERP para 2. Desenvolver algoritmos utilizando TDD aumentar a qualidade 2.1. Aplicar a Classes já existentes do código desenvolvido Implementar novas funções utilizando TDD 2.3. Implementar testes com JUnit 2.4. Implementar testes que utilizem Mock Objects 2.5. Criar uma forma de executar automaticamente os testes Pesquisar serviço de execução de testes unitários Instalar serviço HORAS vii Teste de interface 3.1. Pesquisar ferramentas para teste de interface 3.2. Gerar testes de interface de forma que sejam reaproveitáveis 3.3. Criar uma forma de executar automaticamente os testes Pesquisar serviço de execução de testes de interface Instalar serviço Criar testes de interface para os sistemas Agil ERP e RealBCMS para que novas funções e funções já existentes possam ser testadas automaticamente a cada nova liberação do sistema. 100 Rubrica do Professor Orientador Aprovação do Membro do Comitê de Estágio Rubrica do Coordenador de Estágio Rubrica do Supervisor da Empresa Data: Data: Data: Prof Malutta César Data: Carimbo da Empresa

7 viii

8 CRONOGRAMA FÍSICO E REAL PERÍODO (45 dias) PR ATIVIDADES 1.1. Pesquisar como é utilizado P R 1.2. Pesquisar JUnit P R 1.3. Pesquisar como funcionam os Mock Objects P R 2.1. Aplicar a Classes já existentes P R 2.2. Implementar novas funções utilizando TDD P R 2.3. Implementar testes com JUnit P R 2.4. Implementar testes que utilizem Mock Objects P R 2.5. Executar automaticamente os testes JUnit P R 3.1. Pesquisar ferramentas para teste de interface P R 3.2. Gerar testes de interface reaproveitáveis P R 3.3. Executar aut. os testes de interface P R

9 Aos meus colegas de trabalho, pela disposição de ensinar. Aos meus amigos, Pelo apoio nos períodos Mais difíceis.

10 xi AGRADECIMENTOS Contribuíram para a elaboração deste relatório, direta e indiretamente, algumas pessoas que ficarão marcadas para sempre tanto na minha vida profissional como pessoal. A todos os professores que lecionaram ao autor, durante toda sua vida acadêmica, pelo conhecimento e valores adquiridos. Aos funcionários e supervisores da empresa Fúria Cerebral e Informant Informática pela oportunidade dada e pelo apoio durante a execução das atividades deste estágio. Aos meus pais pelo incondicional apoio durante toda minha vida acadêmica e profissional, sempre presente nos momentos mais difíceis. Aos meus amigos que participaram dessa fase da minha vida e dividiram comigo das alegrias e tristezas no decorrer do curso de graduação e do estágio.

11 xii SUMÁRIO LISTA DE QUADROS... XIV RESUMO... XV 1. INTRODUÇÃO OBJETIVOS Geral Justificativa ORGANIZAÇÃO DO ESTUDO A EMPRESA FÚRIA CEREBRAL PRINCIPAIS PRODUTOS MISSAO DA EMPRESA PRINCIPAIS CLIENTES DESENVOLVIMENTO SITUAÇÃO DO PROCESSO DE DESENVOLVIMENTO NOVO MODELO DE DESENVOLVIMENTO TDD TIPOS DE TESTE Teste Unitário Testes de Integração Testes End-to-End TDD E METODOLOGIAS ÁGEIS Medotologias ágeis FERRAMENTAS UTILIZADAS JUnit Mockito Cruise Control CONSIDERAÇÕES FINAIS GLOSSÁRIO... XXX REFERÊNCIAS BIBLIOGRÁFICAS... XXXII

12 xiii LISTA DE FIGURAS Figura 1- Tela do sistema Ágil ERP... 4 Figura 2- Lista de itens levantados para serem trabalhados em um Sprint... 7 Figura 3 -Lista de bugs na ferramenta Basecamp... 8 Figura 5 - Painel de controle do Cruise Control Figura 5 - Como funciona o Selenium Figura 6 - Plugin do Selenium para Firefox Simples teste de login... 28

13 xiv LISTA DE QUADROS Quadro 1- Exemplo de código Quadro 2- Exemplo de assinatura de método Quadro 3- Exemplo de nome de classe Quadro 4- Exemplo de método de teste Quadro 5- Exemplo de método de teste Quadro 6- Utilização do Mockito Quadro 7 Declaração dos Mock Objects Quadro 8- Utilização do Mockito Quadro 9- Utilização do mockito Quadro 10- O método imprimirboletos... 23

14 xv RESUMO O presente relatório tem por objetivo detalhar as atividades realizadas no período de estágio curricular obrigatório do acadêmico Anderson Geison Borges. As atividades realizadas no desenvolvimento do estágio utilizam diversas técnicas e procedimentos aprendidos nas disciplinas do curso de Tecnologia em Sistemas de Informação da Universidade do Estado de Santa Catarina (UDESC), além de outras fontes bibliográficas que serviram como base para o aprofundamento nos assuntos trabalhados. O objetivo do estágio foi claramente voltado à aplicação de técnicas e ferramentas que possibilitassem o aumento da qualidade dos softwares desenvolvidos para o principal cliente da empresa Fúria Cerebral, a Informant, que já possuía um forte foco em qualidade no seu processo de desenvolvimento porém gostaria de reforçar ainda mais a qualidade no processo, utilizando para isso técnicas como TDD e ferramentas para criação de testes automatizados, reduzindo assim os custos com testes terceirizados e aumentando consideravelmente a qualidade do software.

15 1 1. INTRODUÇÃO Este relatório apresentará as atividades realizadas pelo acadêmico Anderson Geison Borges no período de estágio na empresa Fúria Cerebral. As atividades realizadas serão brevemente detalhadas abaixo OBJETIVOS Geral Implantar metodologias de desenvolvimento de softwares que priorizem a qualidade, utilizando testes unitários, testes de integração e a utilização de ferramentas que auxiliam nesse processo Específicos Pesquisar e aplicar a metodologia TDD (Test Driven Development) no projeto Agil ERP para aumentar a qualidade do código desenvolvido; Escrever testes utilizando JUnit; Utilizar a ferramenta Mockito para a criação de Mock Objects; Configurar servidor de integração Cruise Control; Pesquisar ferramenta para criação de testes de interface; Justificativa A empresa Informant possui um elevado gasto com testes externos, que são realizados com a empresa Quality Test e portanto criou-se a necessidade de reduzir esses custos automatizando os testes internamente para evitar que Bugs simples sejam liberados para um ambiente de produção. Além disso, a empresa aplica a metodologia de

16 2 desenvolvimento Xtreme Programming (XP), e segundo cita Kent Beck, criador do XP, "sacrificar a qualidade não é um meio eficaz de controle. Qualidade não é uma variável de controle. Projetos não andam mais rápido aceitando baixa qualidade. Eles não vão mais devagar porque exigem maior qualidade. Aumentar a qualidade normalmente resulta em entregas mais rápidas; enquanto reduzir os padrões de qualidade freqüentemente resulta em entregas mais tardias e menos previsibilidade." portanto, surgiu a necessidade de focar os esforços na aplicação do XP, e algumas dessas técnicas e ferramentas serão descritas no presente trabalho ORGANIZAÇÃO DO ESTUDO O relatório foi estruturado de acordo com as etapas abaixo: No primeiro capítulo, é informado o objetivo geral, os objetivos específicos e a organização deste trabalho. O segundo capítulo demonstra uma apresentação da empresa onde foi realizado o estágio pelo acadêmico, sendo apresentado o histórico da empresa, seus principais produtos, serviços e clientes. No terceiro capítulo serão abordadas as atividades desenvolvidas durante o estágio, tendo um detalhamento das atividades desenvolvidas e as ferramentas utilizadas. Por fim serão apresentados os resultados obtidos, as principais dificuldades encontradas nas etapas do estágio e as considerações finais do relatório.

17 2.A EMPRESA 2.1.FÚRIA CEREBRAL A empresa Fúria Cerebral é situada em Joinville, conta com 4 sócios e foi criada em 2009 com o objetivo de prestar serviços de desenvolvimento e análise de sistemas para a empresa Informant. A Informant é uma empresa de tecnologia da informação fundada em 2008 com o objetivo de fornecer soluções que atendam as necessidades das pequenas e médias empresas. Pelo fato do estágio ser diretamente relacionado com a Informant, adiante falarei mais desta empresa. 2.2.PRINCIPAIS PRODUTOS Ágil ERP O Ágil ERP é o principal produto da Informant que segue o modelo Software as a Service (Saas), ou seja, é disponibilizado pela Internet como um serviço. É um ERP com foco em usabilidade e simplicidade. Entre suas principais funcionalidades estão: Contas a Receber e a Pagar Propostas Comerciais Controle de Estoque Relatórios gerencias

18 4 Atualmente estão em desenvolvimento as funcionalidades de Nota Fiscal Eletrônica e Frente de Caixa. A principal vantagem do produto é que não exige investimento inicial, o cliente paga mensalmente pelo uso e utiliza um ambiente que está em constante melhoria. O baixo custo também permite que pequenas e médias empresas possam utilizá-lo. Figura 1- Tela do sistema Ágil ERP Bit Áudio Um dos primeiros produtos da Informant, o Bit Aúdio é um sistema para administração de clínicas auditivas que tem como funcionalidades a administração de consultas e alocação de recursos da clínica. Agile Outsourcing Como define o Manifesto Ágil (2010), Agile Outsourcing é a união da terceirização do desenvolvimento de sistemas com a utilização de metodologias ágeis, que segundo o Manifesto, são metodologias voltadas ao desenvolvimento em pequenos ciclos de forma que se adapte a mudanças de escopo e com presença constante do cliente. Incubadora de Produtos seguindo os conceitos de inovação aberta, é um tipo de serviço no qual a empresa fornece orientação estratégia e tecnológica para qualquer

19 5 indivíduo ou organização que possua uma idéia de um software inovador, e que queira viabilizar a sua construção para posterior oferta ao mercado. 2.3.MISSAO DA EMPRESA "Construir as melhores soluções tecnológicas em software de forma inovadora e rentável." A política da Informant é de trabalho transparente, visando a satisfação dos clientes e o ganho mútuo, dessa forma contribuindo com a sociedade PRINCIPAIS CLIENTES Balihai Grendene Daryus RealISO Interpira

20 6 3. DESENVOLVIMENTO Segundo o CMMI Product Team (2006, p.495), o objetivo da validação é que o componente ou produto atenda completamente o objetivo proposto para sua criação. Os testes de software fazem parte da validação e são importantes no processo de desenvolvimento. Segundo (Agile Testing and Quality Strategies, 2010), a automação dos testes traz a possibilidade de tornar o teste mais rápido e efetivo, desde que se tenha atenção quanto ao que automatizar e como deve ser feita esta automação SITUAÇÃO DO PROCESSO DE DESENVOLVIMENTO Atualmente o setor de desenvolvimento da empresa trabalha com iterações de uma a duas semanas em cada um dos seus projetos, essas iterações são chamadas de Sprints. Cada Sprint é iniciado após uma reunião com o cliente, que atua no papel de Gerente do Produto e decide o que será trabalhado dentre as funções levantadas no escopo total do produto. O tempo de cada tarefa que será realizada é orçado pela equipe que irá desenvolver e a partir desse orçamento as tarefas são encaixadas dentro do prazo estipulado para o Sprint. Os itens são lançados no sistema Basecamp (2010), que segundo consta em sua página inicial é uma ferramenta de colaboração baseada na Web. A figura 1 mostra uma tela de entrada de tarefas a executar do sistema.

21 7 Figura 2- Lista de itens levantados para serem trabalhados em um Sprint Segundo o procedimento interno da empresa, por padrão deve-se deixar de 2 a 3 dias fora do orçamento para que nesses dias sejam realizados testes e correções de Bug. O procedimento de testes é definido como segue: Os desenvolvedores concluem e sincronizam todas as suas tarefas através de uma ferramenta de versionamento de códigos fontes. Um desenvolvedor responsável monta uma versão a partir dos códigos fontes sincronizados e contacta a equipe da empresa Quality Test, mostrando quais itens foram trabalhados e que deverão ser testados. A versão é liberada em um ambiente de homologação em que a Quality Test realiza todos os testes. Na ferramenta Basecamp os Bugs encontrados são reportados como é demonstrado na figura 3 Na medida em que os Bugs são reportados, a equipe de desenvolvimento os corrige e, em intervalos que variam de 1 a 4 horas, as correções são liberadas novamente para a equipe de testes realizar testar novamente o sistema. Assim que nenhum Bug permanece aberto, o Sprint é considerado finalizado e é exibido ao cliente na próxima reunião de Sprint.

22 8 Caso não seja possível realizar algum dos Bugs abertos, ele é colocado em uma lista de "Bugs conhecidos" para que seja trabalhado no final do projeto ou assim que houver condições para tal. Figura 3 -Lista de bugs na ferramenta Basecamp Esta forma de trabalho procura garantir que seja entregue exatamente o que o cliente necessita pois ele acompanha semanalmente o andamento dos trabalhos e ele mesmo define quais serão os próximos passos. Com a reserva de alguns dias somente para testes, procura-se garantir a qualidade do que está sendo entregue. Apesar de todos estes pontos positivos, o processo falha na não automatização dos testes, fazendo com que toda a carga de testes fique para a empresa especializada e consequentemente o custo se eleve, além disso, uma funcionalidade sem teste automatizado deverá ser novamente testada na próxima liberação do software para garantir que continue funcionando NOVO MODELO DE DESENVOLVIMENTO No novo modelo proposto, os Sprints permanecem no processo e alguns elementos do XP que antes eram negligenciados são agora adicionados. Entre eles citamos: Programação em Par: Prática em que 2 desenvolvedores trabalham em um mesmo

23 9 computador revezando o teclado e que prima pela qualidade do código desenvolvido pois, enquanto um se concentra no escopo do código atual, o outro vai pensando no escopo geral da aplicação e orientando sobre melhorias na aplicação sendo desenvolvida. Desenvolvimento orientado a testes ou Test Driven Development (TDD): Prática em que o desenvolvedor escreve sempre um teste automatizado antes de desenvolver uma melhoria ou nova funcionalidade, depois, produz um código que possa ser validado pelo teste e por fim melhora o código escrito. O ciclo é repetido até que a funcionalidade esteja concluída. Os detalhes de utilização do TDD serão descritos mais a frente. Integração contínua: Consiste em integrar o trabalho realizado uma ou mais vezes ao dia, garantindo assim que o código permaneça consistente ao final de cada integração. A parte mais difícil na implantação destas técnicas é a adesão por parte dos programadores pois as técnicas demandam uma mudança muito brusca no modelo usual de desenvolvimento e de certa forma tira os desenvolvedores da "zona de conforto". O presente relatório foca principalmente na experiência obtida na utilização da técnica de programação orientada a testes (TDD) TDD Nesse capítulo será apresentada a metodologia de desenvolvimento orientado a testes e como é utilizada. Também serão mostrados alguns exemplos de testes e ferramentas utilizadas para automatizá-los. O conteúdo desse capítulo refere-se a testes na linguagem Java, portanto quando houver referências a termos como classes e métodos, é necessário estar familiarizado com esses termos para um total entendimento. TDD é uma metodologia de desenvolvimento de software, independe da linguagem de programação e tem como finalidade reduzir a quantidade de erros encontrados nos sistemas desenvolvidos. Segundo Astels (2003), A utilização de desenvolvimento oritentado a testes

24 10 implica, teoricamente, que você terá um conjunto exaustivo de testes. Isso porque não há código a não ser que exista um teste que necessite dele para passar, portanto o TDD é um estilo de desenvolvimento onde: Você mantém um conjunto completo de testes de programador; Nenhum código vai para produção sem um teste associado; Você escreve o teste antes de qualquer coisa; Os testes determinam o código que você irá escrever. O primeiro contato de um programador traz certa desconfiança, principalmente por ter de escrever primeiramente o teste, mas essa prática é na verdade semelhante a prática de procurar um erro no código (ou debugar, no jargão dos desenvolvedores) antes do erro acontecer. A prática leva a pequenos incrementos que estão menos sujeitos a erros, do que o código de uma funcionalidade quando escrito todo de uma vez e depois testado. Shore & Warden (2007, p. 285 e 286) reforçam, afirmando que TDD é a prática de vários ciclos de planejamento, codificação e refatoramento de código, em Baby Steps até que não exista nada a acrescentar ou remover e que alguns minutos de programação com TDD, principalmente se utilizarmos junto a programação em par, significam alguns trechos de códigos planejados e bem testados. Com o passar dos anos os sistemas vem ficando maiores e mais complexo, a expansão da Internet permitiu que fossem interligados tornado-os co-dependentes. Tornando assim a manutenção, alteração e ampliação dos mesmos cada vez mais complexa e crítica. Esse novo cenário tecnológico é certamente o motivo do surgimento do TDD, pois, como pode hoje um programador ter certeza de uma alteração ou incremento por ele feito no código de um sistema não ocasionou em erros em outras partes do mesmo? Justamente por ser muito difícil prever o comportamento de um sistema inteiro, o TDD tem como princípio, que não seja liberado nenhum código sem teste para a produção (sistema disponível ao cliente). Isso, somado ao processo de executar os testes antes da liberação de uma versão, traz outro nível de segurança ao programador e qualidade ao sistema.

25 11 Para poder entender como o TDD proporciona esses benefícios é preciso conhecer as diferentes tarefas, ou diferentes tipos de teste que definem o TDD. 1.2 Tipos de Teste Não existe apenas um tipo de teste no TDD. Serão apresentados a seguir os principais tipos de testes automatizados, entre eles estão os testes unitários, testes de integração e testes end-to-end Teste Unitário Teste unitário é sem dúvida a parte que causa maior resistência nos programadores ao adotarem o TDD como forma de desenvolvimento, porque influencia diretamente todo o código por eles desenvolvidos, e principalmente para programadores mais experientes, é uma quebra de paradigma, depois de anos de experiência, mudar sua forma de programar. Esse tipo de teste consiste em código escrito, previamente, para testar um outro trecho de código que será escrito. Eles testam a funcionalidade de um método, ou de uma classe, e rodam inteiramente na memória do computador (sem acesso a banco de dados por exemplo), o que os torna rápidos, podendo ser executados frequentemente durante o processo de codificação. Shore & Warden (2007, p. 298) assumem que não se deve confundir um teste unitário com um teste de integração. Um teste é de integração quando acessa o banco de dados, comunica-se através da rede, acessa o sistema de arquivos ou necessita que você altere alguma configuração para que ele seja executado. Para a utilização de testes unitários é necessário que o código seja desacoplado, ou seja, que pequenos trechos de códigos sejam independentes.

26 Mock Objects Em muitos casos, o código de uma classe ou método utiliza outros objetos dentro de sua lógica, o que dificulta a execução de testes unitários. Por exemplo, no seguinte trecho de código Quadro 1- Exemplo de código A variável pagamento pode ter seu valor alterado pelo método getvlmulta, isso faz com que um teste unitário para o método calculavalorpagamento precise ser independente da lógica do outro método, por exemplo, se o método da multa retornar um valor nulo, o teste irá falhar, mesmo que o código do método esteja correto e mesmo que o erro aconteça, não há certeza de que a lógica do método calculavalorpagamento está correta. Para contornar esse tipo de situação, pode-se utilizar os mock objects, que funcionam como objetos substitutos aos objetos dos quais o método que está sendo testado depende. Por exemplo, no código mostrado anteriormente, é possível criar um mock object que retorne valores pré definidos pelo programador quando o método gevlmulta for chamado. Assim pode-se testar o método calculavalorpagamento isoladamente com as várias possibilidades de retorno do método getvalormulta, que foram definidas previamente Testes de Integração São responsáveis por testar as partes do código que interagem com bancos de dados, sistema de arquivo e outros programas. Esse tipo de teste tende a ser menos numeroso, porque sua necessidade não está diretamente ligada ao tamanho do programa,

27 13 ao contrário dos testes unitários que são diretamente proporcionais ao tamanho do programa. Os teste de integração focados testam isoladamente uma interação do seu código com o mundo exterior. Por não serem executados diretamente na memória do computador esses testes tendem a ter um tempo de execução maior que os testes unitários, e por isso, são executados menos frequentemente durante o processo de codificação Testes End-to-End Para se ter maior segurança de que os testes unitários e de integração estão sendo efetivos em um sistema, existem os testes end-to-end, como reforçam Shore & Warden (2007, p. 299), testes end-to-end exploram várias camadas do sistema, podendo passar pela interface gráfica, camada de negócios, banco de dados e voltando a interface. Testes de aceitação, definidos pelas partes interessadas (stakeholders) como parâmetros de aceitação de que determinada funcionalidade está correta, e testes exploratórios, executados por uma pessoa que literalmente procura falhas no sistema, são exemplos de testes end-to-end, mesmo que alguns autores os citem como testes de integração. 1.3 TDD e metodologias ágeis O TDD, é, normalmente, utilizado como parte da aplicação de metodologias de desenvolvimento ágil Medotologias ágeis Metodologias ágeis, como é mencionado por Ambysoft (Agile Testing and Quality Strategies, 2010) são metodologias de desenvolvimento de software que possuem algumas práticas específicas em sua definição. As principais práticas dessas metodologias são:

28 14 Produção de testes paralelos ao desenvolvimento Os Stakeholders participam ativamente do processo de desenvolvimento Desenvolvimento colaborativo dividido em pequenos ciclos Existem outras práticas utilizadas por metodolgias ágeis, como integração contínua e programação em par, mas que fogem do escopo desse relatório Produção de teste paralelo ao desenvolvimento Significa que os testes não acontecem apenas após o término do sistema ou de uma parte dele, mas sim, durante todo seu desenvolvimento, Stakeholders participam ativamente do processo No caso das metodologias ágeis, os stakeholders, são os próprios clientes, um profissional terceirizado para acompanhar o processo ou até mesmo um gerente de produto da própria organização, que é responsável pelo sistema. A participação dos mesmos no desenvolvimento acontece para que seja possível identificar pontos no projeto que precisam ser mudados, antes que se tenha feito um grande esforço para desenvolvê-los Desenvolvimento Colaborativo em Pequenos Ciclos O desenvolvimento acontece em pequenos ciclos, normalmente uma ou duas semanas, chamados de Iteração, ou Sprint (quando se utiliza também a metodoliga SCRUM). Durante esses ciclos, tenta-se manter a equipe o mais comunicativa possível para que problemas possam ser tratados, e para que todos estejam cientes do andamento do projeto.

29 Ferramentas Utilizadas Neste capítulo serão apresentadas as principais ferramentas utilizadas para a prática do TDD durante o estágio. Elas são o Junit, Mockito, Cactus e Cruise control JUnit O JUnit é um framework open-source, criado por Eric Gamma e Kent Beck, com suporte à criação de testes automatizados na linguagem de programação Java. Esse framework facilita a criação de código para a automação de testes com apresentação dos resultados. Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão. O teste de unidade, conhecido como "caixa branca", testa o menor dos componentes de um sistema de maneira isolada. Cada uma dessas unidades define um conjunto de estímulos (chamada de métodos), e de dados de entrada e saída associados a cada estímulo. As entradas são parâmetros e as saídas são o valor de retorno, exceções ou o estado do objeto. Tipicamente um teste unitário executa um método individualmente e compara uma saída conhecida após o processamento da mesma. Algumas vantagens de se utilizar JUnit: Permite a criação rápida de código de teste que são executados rapidamente sem que, para isso, seja interrompido o processo de desenvolvimento e trazendo uma resposta imediata; Amplamente utilizado pelos desenvolvedores da comunidade código-aberto, possuindo um grande número de exemplos; Pode-se criar uma hierarquia de testes que permitirá testar apenas uma parte do sistema ou todo ele; Escrever testes com JUnit permite que o programador perca menos tempo depurando seu código;

30 Configuração do JUnit A conifguração do JUnit é simples por se tratar de uma biblioteca, basta fazer o download do arquivo da biblioteca no site oficial do JUnit e incluí-lo no classpath da aplicação Exemplo de Utilização do JUnit Para utilizar o JUnit, basta criar uma classe Java que herde da classe junit.framework.testcase. Além disso, para que essa classe possa executar testes, é necessário criar os métodos de teste. Cada método deverá ter a anotação org.junit.test para que o framework do JUnit entenda que se trata de um método de teste. Na empresa, foi adotado como padrão que todos os métodos de teste escritos deverão seguir um padrão de nomenclatura que facilita a visualização do método. Esse padrão de nome foge dos padrões convencionais de desenvolvimento em Java, porém foi uma forma de visualizar melhor os testes no momento de sua execução, principalmente pelo fato do TDD gerar muitos casos de teste para cada método testado. Na figura 3, um exemplo de utilização do padrão. O método validapermissaosave irá receber por parâmetro um objeto que representa um usuário e um objeto que representa um evento, nesse caso, o método irá testar o que deverá ocorrer se for passado por parâmetro um usuário que não seja gerente e um evento que seja novo. Quadro 2- Exemplo de assinatura de método A classe criada também deve seguir um padrão de nomenclatura, não somente um padrão interno da empresa, mas um padrão recomendado pela comunidade de desenvolvedores. Toda classe de teste deve ter por padrão o nome TestNomeDaClasseQueSeraTestada.java. Na figura 4, essa nomenclatura é mostrada para uma classe que irá testar métodos da classe EventoServiceSession.java.

31 17 Quadro 3- Exemplo de nome de classe A classe de testes deverá ficar no mesmo pacote da classe a ser testada, principalmente para que os testes possam ter visibilidade dos métodos da classe a ser testada que podem ser protected por exemplo. Após a criação da classe e do método a ser testado, a implementação do método é simples. No caso descrito na figura 3, o comportamento correto é, quando um usuário não gerente e um evento novo são passados ao método validapermissaosave, o comportamento esperado é que o método lance uma exceção RegistroException. Na figura 5, é possível observar que se o método executar validapermissaosave e passar para a próxima linha, a chamada do método fail() vai fazer com que o teste fracasse, porém, caso validapermissaosave lançar uma exceção RegistroException, o teste passará sem problemas. Dentro do bloco de tratamento da exceção foi colocado uma chamada para o método asserttrue (que gera um erro caso o parâmetro passado seja false) com o parâmetro true. Na prática isso não muda em nada, é somente uma forma de deixar claro aos desenvolvedores que aquele é o comportamento correto do método testado. Quadro 4- Exemplo de método de teste Seguindo o padrão de desenvolvimento TDD, esse teste deve ser criado antes da própria implantação do método validapermissaosave que lança uma exceção no caso descrito. Após escrever o método, o teste deve ser executado, naturalmente irá fracassar, somente então o desenvolvedor poderá escrever o código que faz o teste passar. Para se ter uma idéia, somente no caso do método validapermissaosave, 10

32 18 testes foram escritos e após cerca de 2 semanas um cliente reportou um bug. Para esse bug foi escrito um novo teste, que falhou, comprovando a existência do bug, somente após isso foi implementado o código necessário para resolver o mesmo. Ao concluir a codificação, todos os testes foram novamente executados e o novo teste foi um sucesso, porém a alteração do código acabou fazendo com que outro teste fracassasse, obrigando-me a ler melhor o código e descobrir que a alteração que eu havia feito para corrigir o erro anterior iria causar outro erro, então, reescrevi o código até que todos os testes resultassem em sucesso. Esta é um das vantagens do TDD, encontrar o erro que o desenvolvedor falhou em encontrar antes mesmo de o código ser liberado no sistema de versionamento de códigos fontes. O exemplo anterior foi de um caso em que o esperado era que ocorresse uma exceção, o que talvez não tenha deixado muito claro qual o objetivo do JUnit. Na figura 6, um cálculo de valor de contrato está sendo testado, nele, o valor de um contrato depende do tempo de duração do mesmo, que pode ser proporcional dependendo da data em que ele foi criado e da data em que está sendo realizado o cálculo Quadro 5- Exemplo de método de teste O teste foi escrito usando um mês de 28 dias, um contrato criado no dia 20 no valor de 500 e o cálculo foi realizado no dia 28. O resultado esperado para esse teste é que o cálculo retorne 160,71, portanto, foi utilizado o método asserttrue(); Este foi um caso em que o método já existia antes do teste, pois foi criado antes da Informant ter adotado o TDD como padrão de desenvolvimento. Então, qual a forma correta de escrever testes para métodos já existentes? Optamos por sempre tentar entender qual o propósito do método em questão, o que se espera dele, quais suas entradas e saídas e então, excluir o código existente e iniciar a criação dos testes a partir dos itens levantados. Nesse caso, o método reescrito acabou ficando com menos linhas,

33 19 de 54 linhas foi para 38 linhas. Além disso, ficou perceptível a elevação na qualidade do código, pois se tornou menos suscetível a falhas, com mais tratamento de erros e os nomes de variáveis de escopo foram escritos de forma a tornar óbvio o seu objetivo. Este se tornou o padrão da Informant para criação de testes em códigos legados. A criação de testes utilizando o JUnit é simples e rápida, somando-se a prática do TDD, os códigos escritos tendem a serem menos suscetíveis a erros e consequentemente o nível de qualidade dos produtos se eleva, porém não é recomendável criar testes utilizando somente o JUnit pois haverão casos em que não será possível isolar totalmente a lógica de um método. São nesses casos que a utilização de Mock Objects se faz necessária, e é aí que entra a utilização do Mockito Mockito Mockito é um framework para criação de Mock Objects, criado no início de 2008, por um grupo de desenvolvedores liderado por Szczepan Faber. Entre as principais vantagens na sua utilização estão: A facilidade de configuração; A fácil integração com Junit; Código de fácil leitura por ele proporcionado; Configuração do Mockito Assim como no caso do JUnit, a configuração da ferramenta é simples, basta fazer o download do arquivo da biblioteca do mockito e incluí-la no classpath da aplicação, essa configuração varia de acordo com plataforma e estrutura do projeto. Aproveitando a tecnologia Java e as vantagens da Orientação a Objetos, no projeto Ágil ERP e em todos os projetos em Java da empresa, os testes são escritos em classes que herdam de uma classe que possui vários padrões para testes, é a classe InformantTestCase.java, que por sua vez herda da classe TestCase.java, do framework JUnit. Nessa classe, coloquei todos os métodos relacionados ao Mockito para que os

34 20 desenvolvedores que forem escrever novos testes não precisem ter contato direto com o Mockito e sim com métodos pré-definidos e reaproveitáveis. Abaixo está o código fonte da classe InformantTestCase.java. Os métodos ali definidos serão utilizados a seguir nos exemplos de utilização do Mockito. Quadro 6- Utilização do Mockito Exemplo de Utilização do Mockito Abaixo há um exemplo de utilização do Mockito em conjunto com o JUnit. Primeiramente, ao se utilizar o Mockito, é necessário criar os mocks que serão utilizados na classe de teste. Neste caso foram criados mocks para as classes

35 21 ImprimirBoletoAction, ContaReceberServiceLocal, ContaReceber, Usuario e Banco. Para criar um objeto mock basta fazer uma declaração comum, substituindo a parte à direita do sinal de igualdade pelo método mock(), passando como parâmetro a classe desejada, exemplo: Usuario u = mock(usuario.class); Quadro 7 Declaração dos Mock Objects No primeiro método de teste, fica claro como o código do mockito é de fácil leitura, o método when(), define o que acontecerá, quando, como o próprio nome do método sugere, for executada a linha de código passada por parâmetro. Neste caso, a lógica faz que quando (when), o trecho de código "ActionContext().getName()" for executado, o Mockito retorne (thenreturn) o valor "imprimirboletos". Quadro 8- Utilização do Mockito O primeiro método é simples, mas a mesma classe contém um exemplo mais completo de utilização do mockito. Neste exemplo o método testa a lógica de um método que imprime boletos e valida a mensagem retornada ao usuário caso ele não possua nenhum boleto. Se a mensagem for a definida no teste, a lógica está correta.

36 22 Quadro 9- Utilização do mockito No exemplo acima, é utilizado o método thencallrealmethod, que permite testar código de um objeto mock, nesse caso, foram criados comportamentos específicos para os métodos da classe ImprimirBoletoAction, com exceção do método imprimirboletos, que é o método que desejava-se testar. Existem ainda métodos testando as várias possibilidades de erros na lógica do método com a regra de negócio para a impressão de boletos, o que torna o código de teste mais numeroso que o próprio código de regra de negócio e ao se utilizar TDD, isso sempre acontecerá, como pode-se observar no código do método Imprimir boletos na figura abaixo.

37 23 Quadro 10- O método imprimirboletos Como foi possível observar, a biblioteca do Mockito é de extrema utilidade quando se está escrevendo códigos de testes unitários, ela permite que seja possível realmente testar a menor unidade possível dentro de um software, sem que qualquer outra lógica influencie no teste ou que seja necessário que o teste utilize outros recursos tais como Bancos de dados ou arquivos. A ferramenta peca um pouco no que diz respeito à documentação, acredito que principalmente pelo fato de ser um projeto relativamente novo, porém após a criação de alguns testes o Mockito mostra-se de fácil uso, principalmente pela nomenclatura intuitiva dos métodos Cruise Control Cruise Control é um framework de código aberto para a automatização de builds e integração contínua, que é a prática de metodologias ágeis que prega a fácil liberação de versões do sistema em que se trabalha a qualquer momento. Essa ferramenta, é escrita em Java, mas trabalha com diversas linguagens, possui uma interface Web para fácil administração. O cruise control pode ser obtido

38 24 gratuitamente no sítio oficial da ferramenta. Na opinião de Shore & Warden (2007, p. 183), o principal objetivo de se utilizar essas práticas é ser capaz de fazer a liberação do sistema a qualquer momento, ou seja, disponibilizar a última versão do software desenvolvido para um ambiente de homologação ou de produção. Além disso, o cruise control é uma ferramenta que possibilita a automatização de tarefas complicadas Funcionamento do Cruise Control O cruise control tem sua configuração toda feita através de arquivos no formato XML. Um arquivo de configuração básico contém no mínimo uma tag <cruisecontrol> e uma tag <project>. Esses arquivos de configuração contêm as tarefas que serão executadas, como por exemplo, enviar de notificação, atualizar código fonte do repositório, copiar um arquivo para outra máquina ou diretório, rodar testes automatizados, compilar os projetos importados do repositório, etc. Nesses arquivos de configuração você também pode definir quais as dependências de uma tarefa, por exemplo, a compilação do projeto não pode ser feita antes do download do código fonte atualizado do repositório. Um servidor pode ter várias rotinas diferentes configuradas (ou planos de build). Quando necessário liberar uma versão basta acessar sua interface web e escolher qual dos builds disponíveis deseja-se executar, ou ainda programar para que a aplicação o faça automaticamente em determinado período. No caso da Informant, os arquivos xml estão configurados de modo que quando acionadas as rotinas de build, o cruise control execute uma sequência de rotinas Ant, que são responsáveis por: Fazer o download do código atualizado; Reunir os arquivos necessários para a compilação dos projetos; Parar os servidores de aplicação, nesse caso o Jboss; Fazer o deploy do código fonte; Iniciar os servidores de aplicação novamente; Enviar s de notificação com resultado das operações;

39 25 Figura 4 - Painel de controle do Cruise Control Os testes, atualmente, não são executados automaticamente pelo cruise control pois o processo de implantação dessa funcionalidade está em andamento, mas o objetivo é que antes de fazer a liberação de uma versão, o cruise control rode todos os testes automaticamente e informe aos desenvolvedores caso algum teste falhe. Atualmente, os próprios desenvolvedores rodam todos os testes antes de enviar os códigos para o repositório. Abaixo está um trecho de código de um arquivo de configuração do cruise control na Informant. Quadro 11 - Arquivo de configuração do Cruise Control Esse trecho do arquivo faz com que seja executada uma rotina Ant. Passando alguns parâmetros como o arquivo que especifica o que a rotina fará "buildfile": O Build file é um xml com instruções sobre quais dependências precisam ser sanadas e quais

40 26 ações devem ser executadas após o término da mesma. Nesse caso o nome do arquivo é recebido de outra rotina como parâmetro( ${project.name}), porque essa rotina é utilizada em outros projetos. Antes da utilização do Cruise Control, eram necessários 15 a 20 minutos para se realizar cada liberação de versão, agora esse tempo foi reduzido para 3 a 5 minutos, nos quais o funcionário pode estar executando outras tarefas enquanto aguarda o resultado. Isso obviamente gera um ganho tanto no tempo economizado para a tarefa quanto pela redução dos erros que são comuns quando um processo complexo é executado manualmente. O maior ponto negativo observado da ferramenta está na dificuldade de configuração, por requerer alto nível de conhecimento técnico e pela falta de documentação final e simples. Para se chegar ao nível atual, foram necessárias várias horas de pesquisa não somente no sítio oficial da ferramenta, mas também em diversos fóruns, blogs e outros sítios na internet Selenium Além dos testes dos códigos fontes, a Informant necessita também de testes de interface pois quase todos os seus produtos são disponibilizados na internet e utilizam interfaces em HTML. Para a criação dos testes de interface, foi escolhida a ferramenta Selenium, disponível para download gratuito no seu sítio oficial. O Selenium não é uma ferramenta única e sim um conjunto de ferramentas que auxiliam o desenvolvedor a criar testes de interface. Na figura 11, obtida a partir do Sítio do Selenium, está uma visão geral de como as ferramentas interagem para a criação dos testes de interface.

41 27 Figura 5 - Como funciona o Selenium [Sítio oficial] É disponibilizado um plugin para o navegador Firefox que permite "gravar" um teste de interface. Basta criar um novo teste e iniciar a gravação, então realizar o teste. O plugin então vai gravando os passos. Depois de escrito os testes, o plugin permite que o

42 28 teste seja gerado em linguagens como C#, Java, Pearl, PHP, etc. para que seja posteriormente acoplado em um servidor independente, o Remote Control Server (RC Server), que cria e destrói instância de navegadores Web e executa os testes automaticamente. Com isso é possível por exemplo testar um sistema tanto no navegador Firefox quanto no navegador Internet Explorer por exemplo. Na figura a seguir é possível ver no canto superior direito o botão que inicia a gravação e uma tabela com os procedimentos já gravados. Figura 6 - Plugin do Selenium para Firefox Simples teste de login O presente trabalho não abordou a implementação do RC Server por que, dado o tempo elevado na pesquisa que o RC Server iria demandar, a Informant acabou optando por investir o tempo no servidor de integração Cruise Control e os Mock Objects.

43 CONSIDERAÇÕES FINAIS As atividades desenvolvidas no estágio foram focadas principalmente no processo de desenvolvimento do principal cliente da empresa Fúria Cerebral, a Informant. Como explicado anteriormente, o processo de desenvolvimento antigo separava aproximadamente 20% do tempo de desenvolvimento somente para testes, o que já demonstra que já era um processo muito preocupado com a qualidade do que é desenvolvido, qualidade que a longo prazo agrega valor aos produtos e serviços e diminui os riscos de atraso do projeto. Além de continuar a realizar os testes exploratórios que antes já eram realizados, o processo de desenvolvimento em si dos códigos também sofreu mudanças, principalmente nos hábitos dos programadores pois, se antes eles somente codificavam diretamente as funcionalidades, agora tornou-se padrão a criação de testes antes de qualquer codificação, e a utilização constante das ferramentas JUnit e Mockito, além da técnica TDD. Uma das dificuldades encontradas no estágio foi a criação dos testes de interface utilizando a ferramenta Selenium, pois a configuração do servidor de testes acabou tornando-se mais demorada do que de fato estava previsto, tornando inviável a continuação da pesquisa. Outro ponto de dificuldade foi a aceitação por parte dos desenvolvedores em aplicar todas as técnicas, principalmente pelo fato de se tratar de mudanças bruscas na forma comum de se trabalhar. Outro fato importante que ocorreu, é que antes todo o processo de liberação das versões para homologação ou produção era feito manualmente pelo gerente de cada produto e com a instalação e configuração da ferramenta Cruise Control, o processo foi automatizado, o que além de reduzir o tempo gasto nas liberações, garantiu mais confiança por se tratar de um processo automático, ou seja, não suscetível a falhas humanas. Além dessas mudanças, outras práticas foram adotadas pelas equipes, tais como reuniões mais freqüentes e programação em par e que ajudaram a melhorar muito a qualidade tanto dos softwares quanto do processo de desenvolvimento.

44 GLOSSÁRIO Os conceitos básicos apresentados a seguir estão baseados em diversas fontes bibliográficas. Ant Biblioteca Java para criação de scripts com funcionalidades de linha de comando Baby Steps Passos de bebê, para o TDD, é o processo de só dar continuidade quando o teste anterior for um sucesso Bug Falha de sistema Builds Código fonte compilado de forma que seja executável pelo computador Classpath Variável de ambiente que indica à máquina virtual Java e a toda a tecnologia Java, onde se encontram as bibliotecas a usar Debugar Depurar Deploy Processo de expedição de um Build Download Descarregar ou Baixar end-to-end. Ponta a ponta ERP Enterprise Resource Planning Firefox Navegador de Internet, livre e multi-plataforma desenvolvido pela Fundação Mozilla Framework Conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação

45 Internet Explorer Navegador de Internet de licença proprietária desenvolvido pela Microsoft Java Linguagem de programação orientada a objeto JUnit Biblioteca Java para a automação de testes Mock Objects Para os testes unitários, é o conceito de falsificar objetos Java para que eles se comportem de uma maneira definida Mocks Ver Mock Objects Plugin Extensão de um software Protected Em Java, é um modificador de acesso que define a visibilidade de um atributo de uma classe SAAS Software as a Service Sprint Para as metodologias ágeis, é um período de tempo de desenvolvimento com um escopo definido Stakeholders Partes interessadas Tag Palavra-chave XML Extensible Markup Language