Buster.js, um framework de testes para JavaScript

Transcrição

1 Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento de Sistemas para Web Buster.js, um framework de testes para JavaScript Obedi de Paula Ferreira Prof. Me. Gécen de Marchi Orientador Maringá, 2013

2 Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento de Sistemas para Web Obedi de Paula Ferreira Buster.js, um framework de testes para JavaScript Trabalho submetido à Universidade Estadual de Maringá como requisito para obtenção do título de Especialista em Desenvolvimento de Sistemas para Web. Orientador: Prof. Me. Gécen de Marchi Maringá, 2013

3 Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento de Sistemas para Web Obedi de Paula Ferreira Buster.js, um framework de testes para JavaScript Maringá, 12 de Abril de Prof. Flávio Uber Prof. Munif Gebara Junior Prof. Dr. Gécen de Marchi (Orientador) Ass.: Ass.: Ass.:

4 RESUMO Um dos principais desafios da Engenharia de Software é lidar com o aumento da complexidade do software e a diminuição dos prazos de entrega, dado que esta relação compromete diretamente a qualidade do software. No intuito de minimizar o impacto deste e de outros desafios, foram criados ao longo dos anos diferentes padrões e metodologias de desenvolvimento que pudessem proporcionar ganho de produtividade e garantir maior qualidade do software. Dentre essas metodologias, um conjunto conhecido como metodologias ágeis tem se destacado nos últimos anos. Uma destas metodologias ágeis, o Extreme Programming, ou XP, introduziu uma prática popularmente conhecida como Test- Driven Development, ou TDD, que consiste em implementar testes automatizados que irão guiar o desenvolvimento de cada funcionalidade do software. Escrever testes automatizados para JavaScript não é uma tarefa tão simples quanto nas demais linguagens de programação modernas, basicamente pelo fato de que existem uma série de fatores externos à linguagem que em alguns casos dificultam com que código JavaScript seja testado de forma apropriada. Dentre estes fatores está o fato de JavaScript depender diretamente do HTML, do CSS, e de como cada navegador renderiza estes elementos. Apesar de existirem diversos frameworks de testes para JavaScript disponíveis no mercado, a maioria deles ainda não alcançou o nível de maturidade necessário para se difundir como referência nesse domínio, assim como por exemplo, o JUnit é referência para testes automatizados para a linguagem Java. Sendo assim, após entender as peculiaridades pertinentes aos ambientes onde esse código é executado (os navegadores) e conhecer o estado atual dos frameworks de testes automatizados para JavaScript, encontrou-se o Buster.JS, um framework que apesar de encontrar-se em fase beta, se mostrou bastante robusto e completo, com funcionalidades que ajudam o desenvolvedor a focar seus esforços mais na qualidade dos testes e não na infraestrutura dos testes para diferentes navegadores. O Buster.JS possui instalação e configuração simples, e linguagem similar a frameworks de outras linguagens populares do mercado. Ele utiliza uma técnica baseada no conceito mestre x escravo para permitir que os testes sejam executados ao mesmo tempo em diversos navegadores diferentes, nas versões e plataformas escolhidas pelo desenvolvedor. Palavras-chave: JavaScript, Testes Unitários, Desenvolvimento Guiado por Testes, Testes Automatizados, Buster.JS.

5 ABSTRACT One of the main challenges of Software Engineering in is how to handle the growth of software complexity and the deadline shortenings, given that such relation jeopardizes directly the quality of the software. In an attempt of minimizing the impact of these and other challenges, a variety of patterns and software development methodologies were created throughout the years, that could help improve productivity and assure better quality of the software. Among these methodologies, the so called agile methodologies stood out in recent years. Among these methodologies, the Extreme Programming introduced a practice popularly known as TDD (Test-Driven Development), which consists in implementing automated tests that will guide the development of each functionality of the software. Writing automated tests for JavaScript is not a simple task as in other modern programming languages, primarily because there are a lot of factors external to language that in some cases make testing JavaScript code properly more difficult. Among these factors is the fact that JavaScript depends heavily on HTML, CSS, and how each browser renders these elements. Although there are many JavaScript frameworks available, most of them have not yet reached the necessary level of maturity to stand as an absolute reference in this domain, just like JUnit is a reference to automated tests for the Java programming language, for example. Therefore, after understanding the peculiarities relevant to the environments where this code is executed (the browsers) and after knowing the state of art of JavaScript testing frameworks, Buster.JS was highlighted. Buster.JS is tool that despite being beta, was found to be robust and complete, with features that can help developers to focus on the tests quality over the tests infrastructure for different browsers. Buster.JS installation and configuration is simple, and its language is quite similar to other popular frameworks from other languages. It uses a master x slave technique to allow tests to be executed simultaneously in different browsers, in the versions and platforms chosen by the developer. Keywords: JavaScript, Unit Tests, Test-Driven Development, Automated Tests, Buster.JS.

6 LISTA DE ILUSTRAÇÕES Figura 1 - Exemplo de documento HTML Figura 2 - Árvore DOM da figura anterior Figura 3 - Exemplo de um assert equals no framework JUnit, para Java Figura 4 - Exemplo de caso de teste em Buster.js Figura 5 Calculadora.js: Classe Calculadora, em JavaScript Figure 6 Calculadora-test.js: Teste da class Calculadora, em JavaScript Figure 7 - Exemplo de estrutura de um projeto Figura 8 Arquivo de configuração do Buster.js Figura 9 - Organização das classes e testes Figura 10 - Arquivo buster.html Figura 11 - Relatório de execução dos testes Figura 12 - Resultado de execução com falha Figure 13 - Comando buster static Figura 14 - Estrutura do exemplo validação de formulário Figura 15 - Conteúdo do arquivo test/fixtures/formulario.html Figura 16 - Configuração do Buster.js para uso de fixtures Figura 17 - Conteúdo da classe ValidaForm.js Figura 18 - Formulário de login do arquivo test/fixtures/formulario.html Figura 19 - Formulário de login apresentando erro Figura 20 - Clase de teste ValidaForm-test.js Figura 21 - Comando buster server Figura 22 - Página de captura de slaves Figura 23 - Relatório da execução dos testes Figura 24 - Tentativa de execução dos testes sem slaves capturados Figura 25 - Relatório de execução com falhas Figura 26 - Configuração do Buster.js no modo node Figura 27 - Classe Calculadora.js alterada para o modo node Figura 28 Classe Calculadora-test.js alterada para o modo node... 42

7 SUMÁRIO CAPÍTULO 1. INTRODUÇÃO PROBLEMA JUSTIFICATIVA MOTIVAÇÃO OBJETIVO GERAL OBJETIVOS ESCPECÍFICOS LIMITAÇÕES DA PESQUISA ESTRUTURA DO TRABALHO CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA DESENVOLVIMENTO ÁGIL O MANIFESTO ÁGIL EXTREME PROGRAMMING (XP) TEST-DRIVEN DEVELOPMENT CICLO DE DESENVOLVIMENTO COM TDD A LINGUAGEM JAVASCRIPT ECMASCRIPT, O NÚCLEO DA LINGUAGEM JAVASCRIPT DOM BOM CARACTERÍSTICAS DA LINGUAGEM TESTES UNITÁRIOS EM JAVASCRIPT CAPÍTULO 3. FRAMEWORKS DE TESTES PARA JAVASCRIPT XUNIT TEST FRAMEWORKS BDD ESTRUTURA BÁSICA DE UM FRAMEWORK DE TESTES CASO DE TESTE, OU CENÁRIO DE TESTE ASSERÇÕES FIXTURES SUÍTE DE TESTES TEST RUNNERS RUNNERS IN-BROWSER RUNNERS HEADLESS CAPÍTULO 4. BUSTER.JS... 28

8 4.1. INSTALAÇÃO E CONFIGURAÇÃO MODO IN-BROWSER MODO HTML MODO ESTÁTICO MODO SERVIDOR MODO HEADLESS MODO NODE ASSERÇÕES ASSERT.SAME() ASSERT.EQUALS() ASSERT.GREATER() ASSERT.LESS() ASSERT.DEFINED() ASSERT.ISNULL() ASSERT.ISOBJECT() ASSERT.ISFUNCTION() ASSERT.ISTRUE() ASSERT.ISFALSE() ASSERT.ISSTRING() ASSERT.ISBOOLEAN() ASSERT.ISNUMBER() ASSERT.ISNAN() ASSERT.ISARRAY() ASSERT.EXCEPTION() ASSERT.CONTAINS() ASSERT.TAGNAME() ASSERT.CLASSNAME() CAPÍTULO 5. CONCLUSÃO REFERÊNCIAS... 48

9 8 CAPÍTULO 1. INTRODUÇÃO Uma das questões mais complexas no que diz respeito ao processo de desenvolvimento de software, é como garantir a qualidade do software (FEITOSA, 2007) Dos fatores que afetam a qualidade do software, alguns podem ser medidos diretamente, como por exemplo a relação quantidade de falhas por linhas de código, enquanto que outros apenas podem ser medidos indiretamente, como a usabilidade, por exemplo. São estes fatores que calculados, servem de indicadores da qualidade do software (PRESSMAN, 2005, apud FEITOSA, 2007). SOMMERVILLE (2003, apud FEITOSA, 2007) afirma que um dos principais desafios da Engenharia de Software neste século é lidar com o aumento da complexidade do software e a diminuição dos prazos de entrega, dado que esta relação compromete diretamente a qualidade do software. No intuito de minimizar o impacto deste e de outros desafios, foram criados ao longo dos anos diferentes padrões e metodologias de desenvolvimento de software que pudessem proporcionar ganho de produtividade e garantir maior qualidade do software. Dentre essas metodologias, um conjunto conhecido como metodologias ágeis vem se mostrando úteis na busca de software de melhor qualidade, produzidos em menos tempo e de uma forma mais econômica que o habitual. Em geral essas metodologias são regidas por um conciso conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software (TELES, 2008). No desenvolvimento de software, CIFANI (2011) cita como outro grande problema a manutenção do software em produção, pois a necessidade de mudança no software pode surgir a todo instante e uma pequena mudança em uma pequena parte do software pode ter impacto nas demais partes do mesmo. Torna-se então necessário uma forma de desenvolvimento que possa de alguma forma dar ao desenvolvedor a visibilidade do impacto de uma mudança no software.

10 9 O Desenvolvimento Guiado por Testes, ou TDD (do ingles, Test-Driven Development), é uma das práticas do XP que tem por objetivo antecipar a identificação e correção de falhas durante o desenvolvimento (TELES, 2008). Esta prática consiste em implementar testes automatizados para cada funcionalidade do software antes mesmo de implementá-la (FEITOSA, 2007). Dessa forma, após a implementação da funcionalidade propriamente dita, o desenvolvedor pode executar os testes automatizados e verificar se o código implementado está correto, pois se o teste passar, o desenvolvedor saberá que o código foi bem implementado (FEITOSA, 2007). De forma semelhante, após uma mudança em qualquer parte do software, o desenvolvedor saberá o impacto daquela mudança nas demais partes do sistema, verificando quantos testes não passaram PROBLEMA Atualmente as linguagens de desenvolvimento mais modernas e populares, como o Ruby, o Java, e muitas outras, possuem uma enorme gama de frameworks diversas ferramentas que dão suporte ao uso de testes automatizados. No entanto, apesar de a linguagem JavaScript estar massivamente presente no desenvolvimento web, existem muitos elementos a serem considerados e que dificultam os testes de JavaScript de forma apropriada. Um destes elementos é a interdependência entre HTML e CSS. Pode-se dizer que o problema em se testar JavaScript se resume aos navegadores. Existem diversos navegadores disponíveis, e cada um com suas peculiaridades. Linguagens de desenvolvimento tradicionalmente excelentes para testes unitários, geralmente tem seus testes rodando em um ambiente padronizado, previsível e estável, onde os efeitos de certas ações são facilmente compreensíveis (ZAKAS, 2009). Atualmente existem disponíveis diversos frameworks que dão suporte a testes automatizados em JavaScript, porém a maioria delas ainda não alcançou o nível de maturidade necessário para se difundir como referência nesse domínio, assim como por exemplo, o JUnit é referência para testes automatizados para a linguagem Java.

11 JUSTIFICATIVA NIST (2002, apud TELES, 2008) estima que falhas de software causem um prejuízo anual aproximado de mais de 60 bilhões de dólares para a economia americana. Um terço destes custos poderia ser eliminado se fossem utilizadas infraestruturas de testes mais adequadas, que permitissem identificar e resolver falhas mais cedo e de forma mais eficaz. Apesar desta realidade, grande parte dos desenvolvedores de software hoje, utilizam-se da premissa de que as bibliotecas JavaScript por eles usadas já foram previamente testadas por seus mantenedores, e com isso ignoram a importância de se ter testes que garantam o comportamento esperado dessas bibliotecas em suas aplicações. Aliado a este fato, o desconhecimento de frameworks de testes maduros contribuem para tal negligência em se testar código JavaScript. Sendo assim, para se caminhar em direção a uma cobertura de testes satisfatória no código JavaScript de uma aplicação, é importante entender as peculiaridades pertinentes aos ambientes onde esse código é executado (os navegadores) e conhecer o estado atual dos frameworks de testes automatizados para que se optar pelo mais indicado MOTIVAÇÃO O uso de testes automatizados é um domínio no qual muito tem se falado ao longo dos anos. A maioria das linguagens modernas possuem ferramentas robustas e maduras para suporte a testes, e em alguns casos essas linguagens já até possuem métodos nativos para teste, como é o caso da linguagem Ruby. No entanto, pouca importância tem-se dado aos testes de código JavaScript, e pouco se conhece sobre as ferramentas de teste existentes OBJETIVO GERAL Propor o uso de um dos frameworks de testes unitários disponíveis para JavaScript, que dê suporte robusto à construção de testes unitários, permitindo que desenvolvedores deem maior

12 11 atenção à construção de testes de qualidade, e não investir tempo demasiado na criação e manutenção de infraestrutura necessária para a execução dos testes em diferentes ambientes OBJETIVOS ESCPECÍFICOS Os objetivos específicos para se alcançar o objetivo geral traçado são: i. Estudar testes de unidade para compreender seu papel dentro do domínio dos testes de software; ii. Identificar e estudar outros níveis de testes automatizados de software; iii. Estudar frameworks de testes disponíveis para JavaScript; iv. Escolher um dos frameworks estudados para um aprendizado mais aprofundado; v. Implementar uma suíte de testes utilizando o framework escolhido para colocar em prática os conceitos estudados LIMITAÇÕES DA PESQUISA Este trabalho se limita a estudar os pontos fortes e fracos do framework a ser escolhido, sem a preocupação de sugerir melhorias ou tentar encontrar formas de mitigar as limitações da ferramenta. Quanto a abordagem e profundidade dos testes, serão abordados apenas testes unitários de software ESTRUTURA DO TRABALHO Este trabalho é dividido em cinco capítulos, conforme descrito abaixo: O Capítulo 2, Revisão Bibliográfica, apresenta a base teórica sobre Testes de Software, Desenvolvimento Ágil e Desenvolvimento Guiado por Testes. São também apresentados os fundamentos básicos da linguagem JavaScript. O Capítulo 3, Metodologia de Desenvolvimento, relata as etapas da metodologia de pesquisa utilizada.

13 12 No Capítulo 4, Frameworks de TDD para JavaScript, são apresentados alguns dos frameworks mais populares do mercado atualmente e são levantados os aspectos desejáveis a um framework ideal para este fim. Ao final é apresentada uma análise detalhada do framework que melhor satisfaz estes critérios. Finalizando o trabalho, o Capítulo 5, Conclusão, apresenta a conclusão geral do trabalho, bem como dificuldades, contribuições e possíveis trabalhos futuros.

14 13 CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA 2.1. DESENVOLVIMENTO ÁGIL Ao longo dos anos, alguns desenvolvedores acreditaram que os modelos tradicionais de desenvolvimento, como o modelo cascata, estavam errados, pois suas práticas burocráticas não se encaixavam na realidade dinâmica do mercado de software (CIFANI, 2011). O maior problema destas metodologias era o fato de existirem muitas etapas vitais e sequenciais, ao ponto de que se uma etapa atrasasse, todo o projeto sofreria impacto direto deste atraso (CIFANI, 2011). É neste contexto que com o tempo algumas metodologias foram surgindo com o intuito de minimizar estes problemas, priorizando interações mais constantes com os clientes e entregas de subprodutos em períodos mais curtos de tempo. Apesar de muitas dessas metodologias existirem há anos, o termo desenvolvimento ágil ganhou força após a criação do Manifesto Ágil, um conjunto de princípios a serem seguidos para se obter sucesso no desenvolvimento de software frente as necessidades do mundo atual O Manifesto Ágil O Manifesto Ágil (BECK et al, 2001) foi criado em Fevereiro de 2001 e surgiu a partir de um encontro de 17 profissionais veteranos no desenvolvimento de software que queriam discutir formas de melhorar o desempenho de seus projetos de software. Cada um dos envolvidos na criação do Manifesto Ágil possuía suas próprias práticas e teorias particulares sobre a melhor forma se desenvolver software, porém havia um consenso sobre um pequeno conjunto de 12 princípios que havia sido respeitado em todos os projetos de sucesso (TELES, 2008). Estes princípios se resumem nos seguintes valores descritos no manifesto (BECK et al, 2011): i. Indivíduos e interações mais que processos e ferramentas

15 14 ii. iii. iv. Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda (BECK et al, 2011). Sendo assim, o termo Desenvolvimento Ágil hoje descreve qualquer abordagem de desenvolvimento que siga estes princípios (TELES, 2008) EXTREME PROGRAMMING (XP) O Extreme Programming, ou XP, como é comumente conhecida, é uma das metodologias de desenvolvimento ágil mais populares atualmente. Sua origem vem de algumas práticas do desenvolvimento em Smalltalk, disseminadas principalmente por Kent Beck e Ward Cunningham em meados da década de 80. Dentre essas práticas, pode-se citar a programação em par, refatoração (melhoria no código), feedback constante do cliente e testes automatizados (TELES, 2005). Em projetos XP, o software é desenvolvido em um modo interativo e incremental, onde a cada semana os desenvolvedores se reúnem com o cliente para priorizar um conjunto fechado de funcionalidades que possam ser implementadas completamente no ciclo de uma semana (TELES, 2008). Após esse período, o cliente tem a oportunidade de utilizar e avaliar o que foi produzido e com base nessas experiências, sugerir melhorias e mudanças (TELES, 2008). Nesse ponto, o desenvolvimento guiado por testes torna-se essencial para que os desenvolvedores possam realizar mudanças com segurança, visto que os testes indicarão eventuais falhas decorrentes da alteração. Os testes podem também ajudar a garantir que o código desenvolvido atenda as necessidades levantadas pelo cliente (FEITOSA, 2007). Quatro valores regem o XP. São eles: i. Comunicação: XP mantém a comunicação fluente através do uso de práticas que não podem ser feitas sem se comunicar, tais como testes unitários, programação em par e estimativa de tarefas (BECK e ANDRES, 2004). O efeito dessas simples

16 15 práticas é que desenvolvedores e gerentes tem que se comunicar sobre o que realmente é importante no projeto. ii. Simplicidade: Segundo BECK e ANDRES (2004), XP parte do princípio de que é melhor fazer algo simples no primeiro momento e caso necessário, investir tempo para que este algo seja alterado, do que fazer algo mais complexo e que talvez nunca venha a ser usado. Em outras palavras, os desenvolvedores devem codificar primeiro tudo que é claramente importante para o software, evitando desenvolver o que não é essencial (FEITOSA, 2007). Simplicidade e Comunicação possuem uma relação de suporte mútuo, pois quanto melhor a comunicação, mais claro é aos desenvolvedores o que exatamente precisa ser feito. E quanto mais simples o software, menos o desenvolvedor precisa comunicar sobre seu comportamento, o que tende a levar a uma comunicação mais completa (BECK e ANDRES, 2007). iii. Feedback: No desenvolvimento de software quanto mais cedo uma falha é detectada, mais barata é sua correção (FEITOSA, 2007). Portanto, o XP é organizado em ciclos curtos de feedback do cliente, onde o objetivo é apresentar uma nova funcionalidade ao usuário, de modo que ele possa o mais breve possível detectar eventuais falhas (TELES, 2005). Feedback por sua vez contribui diretamente com Comunicação e Simplicidade, pois quanto mais feedbacks, mais fácil de se comunicar (BECK e ANDRES, 2007). iv. Coragem: Desenvolvedores XP partem do princípio de que problemas irão ocorrer, inclusive aqueles mais temidos, e ter coragem em XP significa ter confiança nos mecanismos de segurança utilizados para proteger o projeto, mecanismos estes que ajudarão a reduzir ou eliminar as consequências destes problemas (TELES, 2005). Entretanto, valores são abstratos demais para guiar comportamentos. Eles indicam o propósito, algo em que se acredita, a razão pela qual age-se de determinada forma (TELES, 2008). Práticas, por sua vez, são aquilo que efetivamente se faz no dia a dia, guiando-se por um conjunto de valores e princípios. Identificá-las é útil pois são claras e objetivas (TELES, 2008). O XP possui uma série de práticas absolutas que servem como um portfólio de ações a disposição de uma equipe ágil de desenvolvimento. Segundo TELES (2008), aplicar essas práticas ou não, é uma escolha diretamente dependente da situação, do contexto. Se dada situação muda, seleciona-se práticas diferentes para abordar estas condições de mudança.

17 16 TELES (2008) também sugere que as práticas do XP sejam experimentadas como uma hipótese, onde aplica-se determinada prática, verificando-se o quanto esta prática ajuda no resultado do projeto. TELES (2008) complementa que embora esse conjunto de práticas tenha sido concebido para funcionar bem em conjunto, sua adoção uma a uma é o suficiente para se perceber benefícios. A medida que mais práticas passam a ser utilizadas em conjunto, mais nítidas são as melhorias. As práticas do XP são divididas entre: (i) primárias e (ii) corolárias (TELES, 2008). As práticas primárias são aquelas que podem gerar benefício imediato independente de qualquer outra que esteja-se utilizando. Já as corolárias tendem a ser mais difíceis de dominar sem que antes tenha-se colocado em uso as práticas primárias TEST-DRIVEN DEVELOPMENT O Desenvolvimento Guiado por Testes é uma das práticas primárias do XP e é nela que este trabalho irá se focar. Seu princípio básico é a inversão da sequência tradicional de: (i) projetar, (ii) implementar e enfim (iii) testar (SANTOS, 2010). Na prática, o desenvolvimento com TDD é constituído de pequenas iterações onde casos de testes são escritos contemplando uma nova funcionalidade, e depois, o código necessário para passar esses casos de teste é implementado. Diante de eventuais mudanças, basta que o software seja software seja refatorado de forma que os testes continuem passando (FEITOSA, 2007). Cada iteração possui um micro objetivo, que terá sido alcançado quando os testes escritos antes da implementação passarem. Dessa forma, o escopo da tarefa na qual o desenvolvedor deverá se focar fica reduzido, ao passo que se dedicará ao seu micro objetivo ao invés de se preocupar com todo software (FEITOSA, 2007), forçando o desenvolvimento a acontecer de forma e incremental (SANTOS, 2010). TDD não é sobre testes, é sobre como usar testes para criar software de maneira simples e incremental. Além de melhorar a qualidade e o projeto do software, ele também simplifica o processo de desenvolvimento (GOLD et al., 2004, apud SANTOS, 2010) Tal simplificação do processo de desenvolvimento, contribui para um aumento no nível de confiança do desenvolvedor no produto sendo construído SANTOS (2010).

18 Ciclo de desenvolvimento com TDD Como citado anteriormente nesta seção, o desenvolvimento com TDD é constituído de iterações. Kent Beck (BECK, 2003) resume o ritmo de desenvolvimento com TDD em 5 passos: i. Escrever um teste novo; ii. iii. iv. Rodar todos os testes e ver que o novo teste falha; Implementar o código necessário e suficiente para que o teste passe; Rodar todos os testes e ver que todos passam; v. Refatorar o código implementado para remover duplicações A LINGUAGEM JAVASCRIPT Desenvolvida pela Netscape Communications em 1994, o JavaScript é uma linguagem de script massivamente utilizada para dar mais dinamismo à páginas da web. Ela permite ao desenvolvedor manipular os elementos de uma página (HTML e CSS) para criar efeitos e aplicar conteúdo dinâmico. A linguagem de marcação HTML é utilizada para ajustar o conteúdo e a formatação de uma página na web, a linguagem de estilo CSS para estilizar como este conteúdo deve ser exibido, e o JavaScript é utilizado para criar efeitos e aplicações RIA (do inglês, Rich Internet Application, ou Aplicações de Internet Rica). Na prática, o JavaScript possui métodos que permitem aos desenvolvedores interagir com o HTML e o CSS para criar tais aplicações (MOZILLA, 2012). O JavaScript é constituído por três elementos, o ECMAScript, o DOM (do inglês, Document Object Model) e o BOM (do inglês, Browser Object Model) ECMAScript, o núcleo da linguagem JavaScript O núcleo da linguagem JavaScript é padronizado pelo comitê ECMA TC-39 sob o nome de ECMAScript (MOZILLA, 2012). É este padrão que define a sintaxe do JavaScript, suas palavras chaves, palavras reservadas, o controle de fluxo, tipos de dados, objetos, operadores,

19 18 dentre outros elementos. Atualmente o ECMAScript está em sua verão 5, porém a maioria dos navegadores modernos implementam a versão 3, com algumas partes apenas da versão 5 (MOZILLA, 2012). Além do JavaScript, outras linguagens também utilizam o ECMAScript como base, como o Action Script, por exemplo DOM O DOM é uma API (do inglês, Application Programming Interface) para manipulação de documentos XML e que foi estendida para documentos HTML. Essa API mapeia os documentos em uma hierarquia de nós, conhecida como DOM Tree, ou Árvore DOM, onde cada parte de um documento é representado por um tipo de nó contendo um tipo diferente de dado (ZAKAS, 2009). Figura 1 - Exemplo de documento HTML

20 19 Figura 2 - Árvore DOM da figura anterior A API do DOM permite aos desenvolvedores manipular toda a árvore, permitindo que qualquer nó seja facilmente removido, adicionado ou modificado BOM O BOM (do inglês, Browser Object Model) provê uma API que expõe elementos do navegador que estão fora do contexto da página sendo exibida. Segundo ZAKAS (2009), esta é a única parte da implementação do JavaScript que não é regulamentada, e devido a isso, cada navegador possui sua própria implementação, o que o torna potencialmente problemático. Basicamente, o BOM engloba as janelas e os frames do navegador, vem dele a capacidade de abrir janelas pop up, a capacidade de mover, redimensionar e fechar janelas, o suporte a cookies e etc. Além disso, ele disponibiliza alguns objetos que proveem informações detalhadas sobre o navegador, sobre a página sendo exibida e sobre a tela do usuário (ZAKAS, 2009) Características da linguagem Como principais características da linguagem JavaScript, pode-se citar:

21 20 i. É imperativa e estruturada ii. iii. iv. Possui tipagem fraca e dinâmica É baseada em objetos (ou baseada em protótipos) É interpretada, não compilada v. Permite funções aninhadas vi. vii. Permite funções anônimas Possui suporte a expressões regulares Testes unitários em JavaScript Segundo Wells (1999), testes unitários são um dos alicerces do Extreme Programming. Em um projeto de software, todas as classes do sistema deveriam ser testadas no nível unitário, e qualquer código sem tal cobertura mínima de testes não deveria ser considerado pronto para produção (Wells, 1999). Cunningham (2005) define uma unidade de software como sendo a menor parte possível de ser testada isoladamente em um sistema, onde tal isolamento significa que dada unidade possa ser testada separada do resto da aplicação e de todas as demais unidades. Conforme Wells (1999), ao criar os testes antes do código, espera-se que o desenvolvedor encontre mais facilidade ao criar o código. Wells (1999) afirma que o tempo necessário para criar um teste unitário e logo em seguida criar uma implementação para que o teste passe, é praticamente o mesmo quando iniciando-se pela implementação. Os testes unitários ajudam o desenvolvedor a pensar no que de fato deve ser feito, ou seja, os requisitos do software são satisfeitos sob uma base forte de testes que garantem o comportamento requerido (Wells, 1999). Outro benefício dos testes unitários é o feedback imediato enquanto se desenvolve. Em muitos casos, não fica claro quando o desenvolvedor terminou de fato toda a funcionalidade necessária, principalmente quando dada funcionalidade passa por constantes mudanças de escopo. Ao se criar testes unitários antes da implementação, fica claro ao desenvolvedor quando a funcionalidade está pronta: quando todos os testes passarem (Wells, 1999).

22 21 Enquanto que em metodologias tradicionais de desenvolvimento de software, primeiro constrói-se o software e depois testa-se o que foi construído, no XP, por utilizar-se o test first (criação dos testes antes mesmo da implementação), todo o design do software é influenciado pelo desejo de se testar tudo o que de fato gera valor para o cliente, deixando todo o sistema mais facilmente testável do ponto de vista de negócios (Wells, 1999). A maior resistência em se dedicar tanto tempo aos testes unitários são os curtos prazos para o desenvolvimento do software. No entanto, o custo da criação antecipada de testes automatizados não se compara ao custo de se criar testes após a descoberta de bugs (Wells, 1999). Wells (1999) afirma que o retorno que os testes automatizados proporcionam é muito maior que o custo de criá-los. Além disso, os testes automatizados reduzem as chances de um novo bug ser introduzido durante eventuais refatorações, pois a cada mudança nas unidades do sistema é possível ter-se feedback rápido se essa mudança afetou alguma funcionalidade existente do sistema (Wells, 1999), entretanto, a adição de novas funcionalidades ao sistema geralmente exige que os testes unitários sejam adaptados para refletir a nova funcionalidade.

23 22 CAPÍTULO 3. FRAMEWORKS DE TESTES PARA JAVASCRIPT Código JavaScript escrito para aplicações web tende a ter muitas dependências, pois JavaScript puro geralmente só é útil quando combinado com HTML e CSS e por meio do uso do DOM e do BOM (ZAKAS, 2009). Por este motivo, além de o desenvolvedor ter de se atentar às diferenças entre engines JavaScript, é necessário também se atentar às diferenças na forma em que uma página é renderizada e como os elementos DOM podem ser manipulados entre diferentes ambientes (ZAKAS, 2009). Isso por isso só já torna a tarefa de testar código JavaScript bastante onerosa. Testes unitários, por definição, devem ser implementados com base no menor elemento testável da funcionalidade do software a ser testada, e implica em testar a estrutura interna (fluxo lógico e de dados) sem nenhuma dependência externa (ZAKAS, 2009). Nesse contexto, os frameworks de testes auxiliam o desenvolvedor na preparação do ambiente propício aos testes, com o devido isolamento da unidades a serem testadas, a um baixo custo de manutenção xunit TEST FRAMEWORKS Um tipo de framework bastante popular entre os desenvolvedores é o xunit. O termo xunit refere-se a frameworks baseados nos conceitos do JUnit, o mais popular framework de testes para Java e o SUnit, o framework de testes do Smalltalk (ZAKAS, 2009). Kent Beck, o pai do Extreme Programming, é também um dos responsáveis pela criação de ambos frameworks. Atualmente, existem diversas variações de xunit para outras linguagens, como por exemplo o nunit, para C# e o JSUnit, para JavaScript. Embora o xunit possa ser considerado o tipo mais popular de framework de testes, os frameworks de BDD (do inglês, Behaviour-Driven Development, em português, Desenvolvimento Guiado por Comportamento) teve um forte crescimento em termos de popularidade nos últimos anos (ZAKAS, 2009).

24 BDD Zakas (2009) afirma que a prática do TDD não está só relacionada ao uso de testes automatizados, mas muito além disso, está relacionada ao design do software. Entretanto, Zakas (2009) também afirma que devido a terminologia utilizada para descrever este processo, muitos desenvolvedores acabam por se limitar a utilizar testes unitários para verificar o funcionamento do sistema, e por esse motivo, nunca experimentaram de fato o benefício de se usar os testes automatizados como ferramenta de design. É nesse contexto que surge o BDD, que introduz um vocabulário mais rico e focado nos aspectos comportamentais do sistema. Este vocabulário pode facilmente ser compartilhado entre desenvolvedores, analistas de testes e de negócio, e clientes. Este vocabulário permite que os aspectos importantes do sistema sejam transmitidos de forma satisfatória entre os envolvidos no desenvolvimento de uma funcionalidade, permitindo que requisitos e problemas sejam discutidos mais facilmente. O processo de desenvolvimento com BDD se baseia em "estórias", as quais descrevem uma funcionalidade que agregue valor ao cliente (Cohn, 2004), e que utilizam um vocabulário familiar a todos os envolvidos no projeto (ZAKAS, 2009). O Cucumber, um dos frameworks BDD mais populares, permite ao desenvolvedor utilizar estórias como testes executáveis, o que permite que os testes aceitação sejam construídos junto ao cliente, aumentando as chances de que as expectativas do cliente sejam completamente alcançadas com a entrega do software (ZAKAS, 2009) ESTRUTURA BÁSICA DE UM FRAMEWORK DE TESTES Frameworks de testes tem uma estrutura bastante similar, independente do tipo de framework. A estrutura básica de um framework de testes é composta pelos elementos a seguir Caso de teste, ou cenário de teste Cada teste unitário é um caso de teste focado em um aspecto específico do comportamento esperado de uma classe. Estes testes são na verdade métodos que irão exercitar o código sendo testado, garantindo que determinada entrada de dados produzirá sempre a mesma saída

25 24 esperada. Por exemplo, o método de teste chamado testsomar() seria o teste unitário para o método somar() da classe Calculadora. Para garantir que o código testado produzirá sempre a mesma saída, dado o mesmo contexto, são utilizadas fixtures para se criar o contexto do teste, e asserções para avaliar o resultado obtido Asserções Os frameworks xunit permitem ao desenvolvedor criar um conjunto de métodos de teste que podem ser executados e irão gerar um relatório da execução, exibindo as falhas nos testes quando houver. O coração dos métodos de teste dos xunit são as asserções, que são chamadas de método que servem para garantir que o resultado da execução de determinada parte do código produziu a saída esperada. Um método de asserção bastante comum nos frameworks xunit é o assert equals, que possui dois parâmetros obrigatórios; o primeiro é o valor esperado, o segundo é o valor atual, que geralmente é o retorno de uma a expressão. Caso o valor dos dois parâmetros sejam diferentes entre si, uma exceção é lançada, quebrando o teste em questão (Zakas, 2009). Figura 3 - Exemplo de um assert equals no framework JUnit, para Java A sintaxe deste método possui inúmeras variações de acordo com a linguagem e o framework utilizados. Asserções serão abordadas mais afundo no Error! Reference source not found Fixtures As fixtures separam o contexto de um teste. É uma convenção que os frameworks disponibilizem métodos opcionais para que o desenvolvedor preencha as pré-condições de um

26 25 teste. Esses métodos são conhecidos como setup() e teardown(), onde o primeiro é usado para criar o contexto do teste e o segundo é usado para retornar o ambiente ao seu estado original. Ambos os métodos são independentes, ou seja, o desenvolvedor pode escolher utilizar apenas o método setup() ou vice-versa. Embora a nomenclatura destes métodos varie de acordo com o framework, e em alguns casos existam mais métodos além destes dois, o conceito de setup e teardown permanece o mesmo. Em testes unitários de JavaScript, é comum que uma fixture seja uma extração de código HTML com o qual o código JavaScript irá interagir Suíte de testes Uma suíte de testes geralmente engloba os cenários de teste que utilizam a mesma fixture, no entanto, em alguns frameworks é possível se utilizar em uma mesma suíte, vários conjuntos de cenários, cada conjunto com suas fixtures. Na prática, uma suíte de testes é um arquivo com a mesma extensão de uma classe da linguagem sendo utilizada (.java para Java,.js para JavaScript, e etc), e que possui vários métodos de teste (casos de teste). Por exemplo, o arquivo TestCalculadora.java seria uma suíte de testes unitários para a classe Calculadora, e dentro desse arquivo, estariam os métodos testsomar(), testdividir(), e etc, e opcionalmente os métodos setup() e teardown() TEST RUNNERS Zakas (2009) afirma que a parte mais importante em uma ferramenta de testes é o test runner, pois é ele que determina o workflow quando se está desenvolvendo guiado por testes. O papel do test runner é basicamente executar todo o código de teste, criado utilizando-se um framework de testes unitários, e após a execução, apresentar um relatório da mesma. Feedback rápido e claro sobre o resultados dos testes é uma exigência quando se está trabalhando com testes unitários. O desenvolvedor precisa ter feedback rápido, pois o processo de execução dos testes é algo que acontece inúmeras vezes durante o workflow, e quando os testes falham, é necessário que o relatório de erros apresente o nível de detalhes necessário para que o desenvolvedor identifique de forma rápida qual o motivo da falha.

27 26 Geralmente os frameworks da família xunit possuem uma barra de progresso que mantem-se verde enquanto os testes sendo executados estão passando, e a partir da primeira falha, ou erro, a cor muda para vermelho, indicando que há um problema. A partir daí, o desenvolvedor pode visualizar mais detalhes sobre a mesma, geralmente contendo a saída esperada e a saída atual, ou uma stacktrace, em caso de exceções não tratadas (o caminho de uma exceção não tratada através das camadas da aplicação). No caso dos testes em JavaScript, existem dois tipos de test runners, os runners inbrowser, que são aqueles executados dentro de uma instância do navegador, e os runners headless, que são aqueles que executam os testes em modo linha de comando, sem abrir uma instância real de um navegador Runners In-Browser Muitos frameworks possuem um runner in-browser nativo. Basicamente, o test runner é invocado através de uma página HTML que carrega o framework e os testes unitários a serem executados. Assim, o desenvolvedor pode acessar essa página no navegador desejado e verificar se seu código JavaScript funciona naquele navegador. A grande vantagem desses test runners é o fato de os testes rodarem em uma instância real do navegador e a facilidade com que o desenvolvedor pode verificar o funcionamento do código testado em diferentes navegadores e versões. Em contrapartida, abrir uma instância do navegador e carregar manualmente a página do runner nos navegadores desejados é uma tarefa onerosa e não atende a necessidade de feedback rápido no workflow com TDD. Entretanto, é possível automatizar este processo. Alguns exemplos frameworks de testes que possuem test runner in-browser nativo são o YUI Test, mantido pelo time de desenvolvimento do Yahoo! (YAHOO, 2012) e o QUnit, mantido pelo time de desenvolvimento do jquery (JQUERY, 2012) Runners Headless Test runners headless por sua vez, não instanciam nenhum navegador, ao invés disso, disponibilizam um utilitário de linha de comando que simula o comportamento de um

28 27 navegador real. O funcionamento deste tipo de test runner é muito semelhante aos dos frameworks de testes das linguagens server-side. As principais vantagens deste tipo de runner são (i) a velocidade com que os testes são executados e (ii) a facilidade com que a execução dos testes pode ser automatizada e integrada a um ambiente de Integração Contínua. Um exemplo de runner headless é o env.js (ENVJS, 2012), desenvolvido originalmente pelo criador do framework jquery. Este runner possui sua própria implementação de navegador (APIs DOM e BOM, etc) baseada no Rhino (MOZILLA, 2012b), uma implementação do JavaScript em linguagem Java (ZAKAS, 2009). A combinação env.js + Rhino permite que os testes de JavaScript sejam executados via linha de comando sem a utilização de um navegador real. Um problema apresentado por Zakas (2009) é que utilizando-se essas implementações, os testes serão executados em um ambiente muito diferente de um ambiente de produção (os navegadores dos usuários finais, por exemplo). Não somente o DOM é emulado, mas também o JavaScript utilizado é uma implementação diferente. Sendo assim, essa combinação por si só não é suficiente para garantir que o código alvo de testes irá funcionar em qualquer navegador real.

29 28 CAPÍTULO 4. BUSTER.JS Testes in-browser são difíceis de integrar a um workflow de desenvolvimento guiado por testes, e testes headless por sua vez são mais fáceis de se trabalhar, neste contexto. No entanto, testes headless geralmente não dão muita segurança quanto ao funcionamento em um ambiente real (ZAKAS, 2009). O Buster.js (BUSTERJS, 2012) é um framework de testes e test runner que se encontra em fase beta, mas que já se mostra eficiente em abordar ambos os modos de execução, em um ambiente de fácil configuração e poucas dependências externas. O Buster.js é um pacote para o Node.js (NODEJS, 2012), um ambiente JavaScript para servidores, portanto não é necessário baixar nenhum arquivo JavaScript, nem referenciar nenhum arquivo JavaScript do Buster em páginas HTML. A única dependência deste framework, é o Node.js instalado. Entretanto, é também possível utilizar o Buster.js como um arquivo JavaScript simples, sem a necessidade de instalação do Node.js, como apresentado na seção 4.2. A sintaxe do Buster.js é muito similar à do RSpec, o popular framework BDD para Ruby. Sua configuração é simples e sua sintaxe não requer que o desenvolvedor constantemente referencie módulos nativos da linguagem, e isso deixa o código do teste mais limpo. Figura 4 - Exemplo de caso de teste em Buster.js A Figura 4 é um exemplo de um caso de teste simples. Em Buster.js, casos de teste são chamadas ao método testcase do objeto buster, que por sua vez é uma instância do framework de testes. Como mostrado na Figura 4, o método testcase recebe como primeiro parâmetro o nome uma String, que geralmente contém apenas o nome da classe alvo do teste, a partir daí, o

30 29 desenvolvedor adiciona os métodos de teste e os métodos setup e teardown, todos separados por vírgula. A Figura 5 e a Figure 6 mostram um caso de teste para uma classe Calculadora, escrita em JavaScript. Por motivos didáticos, a classe Calculadora possui apenas o método soma, e recebe apenas dois parâmetros, que são os números que devem ser somados. Figura 5 Calculadora.js: Classe Calculadora, em JavaScript Figure 6 Calculadora-test.js: Teste da class Calculadora, em JavaScript Na Figure 6, a primeira linha contém uma variável declarada no escopo global do arquivo Calculadora-test.js, essa variável calc é initializada no método setup com uma instância da classe Calculadora. Por ter sido declarada em um escopo global, essa variável estará acessível a todos os métodos de testes que forem criados nesta classe de teste. O arquivo Calculadora-test.js contém um único teste, que testa o funcionamento do método soma da Calculadora apresentada na Figura INSTALAÇÃO E CONFIGURAÇÃO Por ser um pacote para Node.js, sua instalação é bastante simples e possível por meio do utilitário de linha de comando npm, que é um gerenciador de pacotes para Node.js. Sendo assim, para instalar o Buster.js, utiliza-se o comando npm install -g buster em um prompt de linha de comando. A instalação do Node.js não será abordada neste trabalho.

31 30 O Buster.js requer apenas um arquivo de configuração, onde são apontados os diretórios que contém as classes de teste, as classes testadas, e quaisquer outras bibliotecas que sejam dependências para os testes. Figure 7 - Exemplo de estrutura de um projeto A Figure 7 mostra a estrutura de um projeto de exemplo. A pasta src contém as classes de negócio, e a pasta test contém as classes de teste. Segundo a convenção do Buster.js, para cada classe X.js, haverá uma classe teste X-test.js Para que o Buster.js consiga carregar as classes de suas pastas corretas, é necessária a presença do arquivo arquivo de configuração test/buster.js. O conteúdo deste arquivo é mostrado na Figura 8. Figura 8 Arquivo de configuração do Buster.js No arquivo de configuração apresentado na Figura 8, rootpath, na linha 4, diz respeito ao diretório base, relativo ao arquivo atual (test/buster.js), de onde os demais arquivos a serem referenciados serão carregados. Caso omitido, é necessário adicionar o caminho relativo em cada entrada de diretório subsequente (../lib,../src, etc). Na linha 5, environment diz respeito ao ambiente no qual os testes serão executados. Este ambiente pode ser browser ou node. A diferença será explorada nos items a seguir.

32 31 Na linha 6, libs indica de onde o Buster.js irá carregar quaisquer bibliotecas que são dependência para os testes, por exemplo, o jquery. Nas linhas 7 e 8, sources e tests indicam o local onde se encontram as classes de negócio e as classes de testes respectivamente. Após configurado, para executar os testes, basta executar o comando buster test a partir da raíz do projeto, que no exemplo da Figure 7 seria a pasta meu_projeto_js MODO IN-BROWSER O Buster.js oferece três diferentes formas de se executar testes in-browser, descritas a seguir Modo HTML A forma mais simples de se executar testes no Buster.js é criando-se um documento HTML, onde dentro de tags script, o desenvolvedor referencia a biblioteca do Buster.js e todos os arquivos de teste, não sendo necessária a criação de um arquivo de configuração do Buster, como mostrado na Figura 10. O exemplo desta seção utiliza as classes Calculadora.js e Calculadora-test.js das figuras Figura 5 e Figure 6. Figura 9 - Organização das classes e testes

33 32 Figura 10 - Arquivo buster.html Feito isso, basta abrir o arquivo buster.html no navegador desejado para visualizar o relatório dos testes, onde pode-se ver a quantidade de testes executados, a quantidade de sucessos, asserções, falhas, erros, timeouts e o tempo total de execução, como mostrado na Figura 11. Figura 11 - Relatório de execução dos testes A Figura 12 apresenta um exemplo de falha durante a execução dos testes. É possível além da contagem de sucessos e falhas, uma stack trace da falha, para auxiliar o desenvolvedor na identificação o problema.

34 33 Figura 12 - Resultado de execução com falha Embora este modo seja o modo mais simples e rápido de se obter feedback sobre os testes, ele é demasiado manual para um workflow com TDD. Além disso, caso o desenvolvedor quisesse verificar o funcionamento em outro navegador, seria necessário abrir o arquivo buster.html manualmente no navegador desejado. É importante ressaltar que o exemplo da calculadora não faz uso do DOM, então não haveria muito ganho em se executar estes testes em diferentes navegador. Mais adiante será apresentado um exemplo mais completo, em que o feedback em diferentes navegadores se torna mais importante Modo estático O modo estático é bastante parecido com o modo anterior, a diferença é que no modo estático uma página HTML parecida com a da Figura 11 é remotamente servida pelo endereço do servidor>:8282.

35 34 Para utilizar este modo, é necessário criar um arquivo de configuração como o da Figura 8 e em um terminal de linha de comando, executar o comando buster static, como mostra a Figure 13. Figure 13 - Comando buster static Acessando a url tem-se a mesma página HTML da Figura 11. Neste modo, não é necessário criar manualmente o arquivo buster.html mostrado na Figura 10, pois a página com os resultados é gerada automaticamente pelo Buster.js. Entretanto, este modo ainda não é o ideal em um workflow com TDD, pois de forma semelhante ao modo HTML, no modo estático o desenvolvedor precisa abrir manualmente a url com o relatório ons navegadores desejados e recarregar a página a cada alteração no código Modo servidor O modo server permite a automatização dos testes em diferentes navegadores. Este modo se baseia no conceito master x slave, onde diferentes navegadores, em diferentes versões e sistemas operacionais podem ser utilizados como slaves, onde os testes serão executados cada vez que o desenvolvedor executar o comando buster test. Nesta seção, será utilizado como exemplo uma classe JavaScript para validação de formulários. Foi criado um formulário de login, com os campos usuário e senha, em que apenas o campo usuário é obrigatório. A Figura 14 apresenta a estrutura do projeto utilizado no exemplo.

36 35 Figura 14 - Estrutura do exemplo validação de formulário Na Figura 14 pode-se observar o diretório test/fixtures. Este diretório contém os arquivos HTML que serão utilizados nos testes. Estes arquivos de fixtures contém apenas uma extração do HTML da página real, o suficiente para que o JavaScript sob teste possa ser exercitado por completo. A Figura 15 exibe o conteúdo da fixture formulario.html. Figura 15 - Conteúdo do arquivo test/fixtures/formulario.html Para configurar o Buster.js de forma que as fixtures sejam carregadas corretamente, é necessário adicionar a entrada resources ao arquivo buster.js, como mostra a Figura 16 na linha 9.

37 36 Figura 16 - Configuração do Buster.js para uso de fixtures Para que a classe de validação da Figura 15 funcione, é necessário que o formulário a ser validado possua o atributo validate= true, e os campos obrigatórios precisam ter a classe required como mostrado na linhas 1 e 3 da Figura 15, respectivamente. Outro ponto a se observar na Figura 14 é a presença do arquivo jquery.min.js no diretório lib. Este arquivo é necessário para que seja possível utilizar os helpers do jquery para manipulação do DOM. A Figura 17 apresenta a classe de validação criada para o exemplo em questão.

38 37 Figura 17 - Conteúdo da classe ValidaForm.js As figuras a seguir ilustram o efeito da classe de validação da Figura 17. Na Figura 18 é apresentado o formulário em seu estado original, e na Figura 19, o mesmo formulário após detectado erro na validação. Figura 18 - Formulário de login do arquivo test/fixtures/formulario.html

39 38 Figura 19 - Formulário de login apresentando erro O intuito da classe de validação é fazer com que os formulários que possuem o atributo validate= true (Figura 18, linha 16) sejam validados ao clicar no botão submit, e fazer com que quaisquer campos que possuam a classe required sejam validados ao deixar o campo (evento blur, Figura 18, linha 23). O teste para a classe ValidaForm.js é apresentado a seguir, na Figura 20. Figura 20 - Clase de teste ValidaForm-test.js

40 39 Para automatizar a execução do teste da Figura 20, é necessário iniciar o serviço do Buster.js e capturar os navegadores onde se deseja que os testes sejam executados. A inicialização o serviço do Buster se dá através do comando buster server em um terminal de linha de comando, como mostra a Figura 21. Figura 21 - Comando buster server A partir daí, para que o navegador desejado seja capturado. É necessário acessar a url exibida na Figura 21 e clicar no botão de captura, como mostra a Figura 22. Figura 22 - Página de captura de slaves O inconveniente deste modo, é a necessidade de acessar a página de captura em todos os navegadores desejados e capturá-los um a um. Porém, após feito isso, basta executar o comando buster test a partir do diretório raiz do projeto e ver o resultado no terminal de linha de comando, como mostra a Figura 23.

41 40 Figura 23 - Relatório da execução dos testes É possível se observar no relatório de execução, em quais navegadores os testes foram executados e em quais sistemas operacionais. No caso da Figura 23, os testes rodaram nas versão 19 do navegador Firefox, na versão 25 do navegador Chrome, e na versão 6 do navegador Safari. Caso não hajam slaves capturados, uma mensagem informativa é exibida, como mostra a Figura 24. Figura 24 - Tentativa de execução dos testes sem slaves capturados A Figura 25 mostra um exemplo de execução com falhas. Figura 25 - Relatório de execução com falhas Uma grande vantagem deste método é a fácil integração no workflow com TDD, onde a cada alteração de código, e a cada vez que o desenvolvedor desejar ter feedback sobre o

42 41 funcionamento do mesmo em diferentes navegadores, basta invocar o comando buster test e aguardar a execução terminar MODO HEADLESS Em um modo headless, os testes são executados sem que seja necessária nenhuma instância real de um navegador, como descrito no item No entanto, como citado no início deste capítulo, o Buster.js encontra-se em versão beta, e na versão atual, está funcionalidade ainda não está disponível, embora a própria documentação oficial apresenta métodos alternativos MODO NODE Além do modo headless, o modo Node permite que os testes sejam executados sem a presença de navegadores, no entanto, neste modo o cenário de teste de fato não requer a presença de um navegador, como no exemplo do teste da calculadora do item Para se executar os testes neste modo, algumas alterações são necessárias ao arquivo de configuração do Buster.js. A primeira delas é alterar o valor da entrada environment, de browser para node, como mostra a Figura 26, na linha 6. Figura 26 - Configuração do Buster.js no modo node Neste modo é necessário apenas indicar o diretório onde estão os arquivos de teste, não sendo necessário utilizar as entradas lib e src (conforme visto na Figura 8), pois as classes que forem dependência para os testes serão carregadas diretamente nos testes, utilizando o método require, do Node.js. Até mesmo a biblioteca do Buster precisa ser carregada através do método require, como pode ser visto na linha 2 da Figura 26.

43 42 São necessárias também mudanças tanto nas classes de negócio quanto nas classes de teste, como mostram as figuras Figura 27 e Figura 28. Nas classes de negócio, é necessário utilizar o método module.exports, para que a classe fique disponível fora do contexto do arquivo em que a classe foi definida (Figura 27). Figura 27 - Classe Calculadora.js alterada para o modo node Nas classes de teste é necessário utilizar o método require para se carregar a classe de negócio sendo testada (Figura 28). Figura 28 Classe Calculadora-test.js alterada para o modo node 4.5. ASSERÇÕES Os exemplos apresentados até aqui contém apenas o método de asserção assert.equals. No entanto, o Buster.js conta com uma variada gama de métodos de asserção, que visam dar mais valor semântico aos testes. Os principais métodos de asserção do Buster.js são brevemente apresentados a seguir.