Buster.js, um framework de testes para JavaScript

Tamanho: px
Começar a partir da página:

Download "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.

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

5 Detalhes da Implementação

5 Detalhes da Implementação Detalhes da Implementação 101 5 Detalhes da Implementação Neste capítulo descreveremos detalhes da implementação do Explorator que foi desenvolvido usando o paradigma MVC 45 e o paradigma de CoC 46 (Convention

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Introdução ao Javascript

Introdução ao Javascript Programação WEB I Introdução ao Javascript Apresentação da Disciplina,Introdução a linguagem Javascript Objetivos da Disciplina Apresentar os principais conceitos da linguagem Javascript referente à programação

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

Dominando Action Script 3

Dominando Action Script 3 Dominando Action Script 3 Segunda Edição (2014) Daniel Schmitz Esse livro está à venda em http://leanpub.com/dominandoactionscript3 Essa versão foi publicada em 2014-05-02 This is a Leanpub book. Leanpub

Leia mais

Especificação e Automação Colaborativas de Testes utilizando a técnica BDD

Especificação e Automação Colaborativas de Testes utilizando a técnica BDD Especificação e Automação Colaborativas de Testes utilizando a técnica BDD Rafael Chiavegatto¹, Vanilton Pinheiro¹, Andréia Freitas Vieira¹, João Clineu¹, Erbett Hinton Oliveira¹, Ellen Barroso¹, Alexandre

Leia mais

SELENIUM 28/03/2011. Márcio Delamaro Harry Trinta

SELENIUM 28/03/2011. Márcio Delamaro Harry Trinta 1 SELENIUM 28/03/2011 Márcio Delamaro Harry Trinta O que é a Selenium? Selenium é uma ferramenta desenvolvida para a automação de testes em aplicações Web Suporta diversos browsers: Firefox Internet Explorer

Leia mais

Linha Silk: a maneira leve para testar, desenvolver e gerenciar

Linha Silk: a maneira leve para testar, desenvolver e gerenciar Linha : a maneira leve para testar, desenvolver e gerenciar Leve Criado apenas com a funcionalidade que você precisa Barato Do uso gratuito ao licenciamento flexível Eficiente Software fácil de usar e

Leia mais

UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO

UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO Robson L. Nascimento 1, Késsia R. C. Marchi¹ 1 Universidade Paranaense (UNIPAR) Paranavaí-PR-Brasil robsonluisn@yahoo.com.br,

Leia mais

BCValidador VALIDAÇÃO DE ARQUIVOS XML RECEBIDOS PELO BANCO CENTRAL DO BRASIL

BCValidador VALIDAÇÃO DE ARQUIVOS XML RECEBIDOS PELO BANCO CENTRAL DO BRASIL BCValidador VALIDAÇÃO DE ARQUIVOS XML RECEBIDOS PELO BANCO CENTRAL DO BRASIL Deinf/Dine4 Versão 1.3 20/05/2013 Histórico de Revisão Data Versão Descrição Autor 06/11/2007 1.0 Elaboração da primeira versão

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Google Web Toolkit* Clério Damasceno Soares, Daniel da Silva Filgueiras e Fábio Figueiredo da Silva

Google Web Toolkit* Clério Damasceno Soares, Daniel da Silva Filgueiras e Fábio Figueiredo da Silva Google Web Toolkit* Clério Damasceno Soares, Daniel da Silva Filgueiras e Fábio Figueiredo da Silva Universidade Federal de Juiz de Fora UFJF-MG Campo Universitário Bairro Marmelos Juiz de Fora MG Brasil

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Algoritmos em Javascript

Algoritmos em Javascript Algoritmos em Javascript Sumário Algoritmos 1 O que é um programa? 1 Entrada e Saída de Dados 3 Programando 4 O que é necessário para programar 4 em JavaScript? Variáveis 5 Tipos de Variáveis 6 Arrays

Leia mais

Uso de servlets nas aplicações web desenvolvidas para a plataforma java 1

Uso de servlets nas aplicações web desenvolvidas para a plataforma java 1 Uso de servlets nas aplicações web desenvolvidas para a plataforma java 1 Resumo Em uma interação feita em uma aplicação Web existem tarefas que devem ser executadas no servidor, tais como processamento

Leia mais

Evolução do Design através de Testes e o TDD

Evolução do Design através de Testes e o TDD c a p a Lucas Souza (lucas.souza@caelum.com.br): é bacharel em Engenharia da Computação pela Universidade de Ribeirão Preto, possui a certificação SCJP e trabalha com Java há 4 anos. Atualmente é desenvolvedor

Leia mais

Aula 9: Fundamentos do JQuery Fonte: Plano de Aula Oficial da Disciplina

Aula 9: Fundamentos do JQuery Fonte: Plano de Aula Oficial da Disciplina Programação para Internet Rica 1 Aula 9: Fundamentos do JQuery Fonte: Plano de Aula Oficial da Disciplina Objetivo: Capacitar o aluno para o trabalho com o framework JQuery. INTRODUÇÃO JQuery é uma biblioteca

Leia mais

7HVW'ULYHQ'HYHORSPHQW

7HVW'ULYHQ'HYHORSPHQW 81,9(56,'$'()('(5$/'25,2*5$1'('268/,167,7872'(,1)250È7,&$ 7HVW'ULYHQ'HYHORSPHQW Otávio Gaspareto REJDVSDUHWR#LQIXIUJVEU,QWURGXomR 7HVWGULYHQGHYHORSPHQW, ou TDD, também conhecido por WHVWILUVWGHYHORSPHQW,

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

TESTE DE SOFTWARE COM XP. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

TESTE DE SOFTWARE COM XP. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com TESTE DE SOFTWARE COM XP Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Contexto Inúmeros processos de software Evolução das formas/metodologias de desenvolvimento de software Dificuldades encontradas

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Associação Carioca de Ensino Superior Centro Universitário Carioca

Associação Carioca de Ensino Superior Centro Universitário Carioca Desenvolvimento de Aplicações Web Lista de Exercícios Métodos HTTP 1. No tocante ao protocolo de transferência de hipertexto (HTTP), esse protocolo da categoria "solicitação e resposta" possui três métodos

Leia mais

Estratégias para testes: a metáfora da pirâmide alimentar

Estratégias para testes: a metáfora da pirâmide alimentar Estratégias para testes: a metáfora da pirâmide alimentar Jorge Diz Instrutor Globalcode Kleber Xavier Instrutor Globalcode 1 Agenda > O que são testes? > Tipos de testes > A pirâmide de testes (Huggins)

Leia mais

1. Introdução. fymoribe@gmail.com

1. Introdução. fymoribe@gmail.com Aplicação em cenário empresarial da utilização das metodologias de teste de software Fábio Yoshiaki Moribe¹ ¹ Departamento de Informática - Universidade Estadual de Maringá (UEM) fymoribe@gmail.com Abstract.

Leia mais

Capítulo 2 Introdução à ferramenta Flash

Capítulo 2 Introdução à ferramenta Flash Capítulo 2 Introdução à ferramenta Flash Índice 1. O uso da ferramenta Flash no projeto RIVED.... 1 2. História do Flash... 4 1. O uso da ferramenta Flash no projeto RIVED. É importante, antes de iniciarmos

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

HAT Programação Auditoria Pós. 12.1.x. abril de 2015. Versão: 2.0

HAT Programação Auditoria Pós. 12.1.x. abril de 2015. Versão: 2.0 HAT Programação Auditoria Pós 12.1.x abril de 2015 Versão: 2.0 1 Sumário 1 Introdução... 3 2 Visão do Processo... 3 3 Serviço... 5 4 Dataset... 7 5 Formulário Principal AuditoriaPos... 9 6 Arquitetura

Leia mais

Produto: Webscan Relatório II Programas desenvolvidos, testados e documentados

Produto: Webscan Relatório II Programas desenvolvidos, testados e documentados Produto: Webscan Relatório II Programas desenvolvidos, testados e documentados Sérgio Oliveira Campos Contrato N : 2008/000514 Sumário 1 Introdução 1 2 Bibliotecas Utilizadas 2 2.1 Reconhecimento de Texto

Leia mais

TESTES AUTOMATIZADOS COM JUNITE MOCKITO

TESTES AUTOMATIZADOS COM JUNITE MOCKITO TESTES AUTOMATIZADOS COM JUNITE MOCKITO Jaime William Dias 12, Dener Barranco 1, Douglas Delapria 1 1 Universidade Paranaense (Unipar) 2 Universidade Estadual de Maringá (UEM) Paranavaí PR Brasil dener_barranco@hotmail.com,

Leia mais

ANÁLISE DA UTILIZAÇÃO DE PRÁTICAS DO EXTREME PROGRAMMING PARA A PREVENÇÃO DO DÉBITO TÉCNICO DE PROJETOS DE SOFTWARE

ANÁLISE DA UTILIZAÇÃO DE PRÁTICAS DO EXTREME PROGRAMMING PARA A PREVENÇÃO DO DÉBITO TÉCNICO DE PROJETOS DE SOFTWARE CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇAO EM ENGENHARAIA DE SOFTWARE CENTRADA EM MÉTODOS ÁGEIS ANÁLISE DA UTILIZAÇÃO DE PRÁTICAS DO EXTREME PROGRAMMING

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Lista de Revisão. 3. Analise a afirmativa a seguir como verdadeira ou falsa e justifique.

Lista de Revisão. 3. Analise a afirmativa a seguir como verdadeira ou falsa e justifique. Lista de Revisão 1. Nos sistemas web, geralmente os usuários apresentam dois problemas típicos, a desorientação e a sobrecarga cognitiva. Discorra sobre esses problemas. 2. Apresente as principais diferenças

Leia mais

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados Tribunal de Justiça de Pernambuco Diretoria de Informática Guia de Utilização do Mantis Máquina de Estados Guia de Utilização Mantis Histórico de Alterações Data Versão Descrição Autor Aprovado Por 02/09/2008

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Frameworks para criação de Web Apps para o Ensino Mobile

Frameworks para criação de Web Apps para o Ensino Mobile 393 Frameworks para criação de Web Apps para o Ensino Mobile Lucas Zamim 1 Roberto Franciscatto 1 Evandro Preuss 1 1 Colégio Agrícola de Frederico Westphalen (CAFW) Universidade Federal de Santa Maria

Leia mais

Potenciais de Aplicação da Metodologia AJAX

Potenciais de Aplicação da Metodologia AJAX SEGeT Simpósio de Excelência em Gestão e Tecnologia 1 Potenciais de Aplicação da Metodologia AJAX Bruno Simões Kleverson Pereira Marcos Santos Eduardo Barrere Associação Educacional Dom Bosco - AEDB RESUMO

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP extreme Programming extreme Programming (XP) Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitos vagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Introdução ao TDD. Dionatan Moura. #guma10anos Abril de 2014. about.me/dionatanmoura

Introdução ao TDD. Dionatan Moura. #guma10anos Abril de 2014. about.me/dionatanmoura Introdução ao TDD #guma10anos Abril de 2014 Dionatan Moura about.me/dionatanmoura Introdução ao TDD Extreme Programming TDD Refatoração xunit Baby Steps Clean Code Patterns para TDD Red Bar Test Green

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

6 Infraestrutura de Trabalho

6 Infraestrutura de Trabalho 6 Infraestrutura de Trabalho Este capítulo tem como objetivo fornecer uma visão geral do ambiente de trabalho encontrado na organização estudada, bem como confrontá-lo com a organização ideal tal como

Leia mais

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação. ANEXO 11 O MATRIZ Para o desenvolvimento de sites, objeto deste edital, a empresa contratada obrigatoriamente utilizará o framework MATRIZ desenvolvido pela PROCERGS e disponibilizado no início do trabalho.

Leia mais

Justificativa do uso da Linguagem XML no Projeto RIVED

Justificativa do uso da Linguagem XML no Projeto RIVED Justificativa do uso da Linguagem XML no Projeto RIVED Índice Introdução... 1 Sobre a linguagem XML... 2 O que é XML (extensible Markup Language)?... 2 Características da Linguagem...3 Sobre o seu uso...

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

TECNOLOGIAS E FRAMEWORKS PARA O DESENVOLMENTO DE INTERFACES WEB

TECNOLOGIAS E FRAMEWORKS PARA O DESENVOLMENTO DE INTERFACES WEB TECNOLOGIAS E FRAMEWORKS PARA O DESENVOLMENTO DE INTERFACES WEB Marcelo Rodrigo da Silva Ribeiro 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil marcelo.rodrigo@live.com,

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Sumário. HTML CSS JQuery Referências IHC AULA 6 5-09-2011 1

Sumário. HTML CSS JQuery Referências IHC AULA 6 5-09-2011 1 Sumário HTML CSS JQuery Referências IHC AULA 6 5-09-2011 1 Linguagem HTML HTML é a abreviação de HyperText Markup Language, que pode ser traduzido como Linguagem de Marcação de Hipertexto. Não é uma linguagem

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

Nota de aplicação: Desenvolvimento de Páginas no PO9900 - WebGate

Nota de aplicação: Desenvolvimento de Páginas no PO9900 - WebGate Nota de aplicação NAP080 Desenvolvimento de Páginas no PO9900 - WebGate Altus Sistemas de Informática S.A. Página: 1 Sumário 1. Introdução...3 1.1 Páginas do WebGate... 3 2. Árvore de Navegação...3 3.

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

Desenvolvimento Web. Saymon Yury C. Silva Analista de Sistemas. http://www.saymonyury.com.br

Desenvolvimento Web. Saymon Yury C. Silva Analista de Sistemas. http://www.saymonyury.com.br Desenvolvimento Web Saymon Yury C. Silva Analista de Sistemas http://www.saymonyury.com.br Vantagens Informação em qualquer hora e lugar; Rápidos resultados; Portabilidade absoluta; Manutenção facilitada

Leia mais

Sistemas para internet e software livre

Sistemas para internet e software livre Sistemas para internet e software livre Metodologia de modelagem de aplicações WEB Image: FreeDigitalPhotos.net Domínio: Elementos de aplicação WEB Páginas Web Scripts Formulários Applets e ActiveX Motivação

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais

Lógica de Programação

Lógica de Programação Lógica de Programação Unidade 4 Ambiente de desenvolvimento Java QI ESCOLAS E FACULDADES Curso Técnico em Informática SUMÁRIO A LINGUAGEM JAVA... 3 JVM, JRE, JDK... 3 BYTECODE... 3 PREPARANDO O AMBIENTE

Leia mais

Conhecendo o Visual FoxPro 8.0 Parte 3

Conhecendo o Visual FoxPro 8.0 Parte 3 AULA Conhecendo o Visual FoxPro 8.0 Parte 3 Continuando nossa saga pelas ferramentas do Visual FoxPro 8.0, hoje vamos conhecer mais algumas. A Ferramenta Class Designer A Class Designer é a ferramenta

Leia mais

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo DOCUMENTAÇÃO TÉCNICA Melhores práticas de gerenciamento de ativos de software JUNHO DE 2013 Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo John Fulton CA IT Business Management

Leia mais

Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina

Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina Programação para Internet Rica 1 Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina Objetivo: Identificar as principais características de uma Aplicação Internet Rica.

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

Desenvolvimento Ágil de Software com Programação extrema (XP) Ricardo Argenton Ramos

Desenvolvimento Ágil de Software com Programação extrema (XP) Ricardo Argenton Ramos Desenvolvimento Ágil de Software com Programação extrema (XP) Ricardo Argenton Ramos Novos ventos no mundo do Desenvolvimento de Software Sociedade demanda grande quantidade de sistemas/aplicações software

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Testes de Software. Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB. Anne Caroline O. Rocha Tester Certified BSTQB NTI UFPB

Testes de Software. Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB. Anne Caroline O. Rocha Tester Certified BSTQB NTI UFPB Testes de Software 1 AULA 04 FERRAMENTAS DE AUTOMAÇÃO DE TESTES FUNCIONAIS Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB Conteúdo Programático Aula 04 Automação de testes funcionais Ferramentas

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Microsoft Visual Studio Express 2012 for Windows Desktop

Microsoft Visual Studio Express 2012 for Windows Desktop Microsoft Visual Studio Express 2012 for Windows Desktop Apresentação da ferramenta Professor: Danilo Giacobo Página pessoal: www.danilogiacobo.eti.br E-mail: danilogiacobo@gmail.com 1 Introdução Visual

Leia mais

Processamento de dados XML

Processamento de dados XML Processamento de dados XML César Vittori cvittori@inf.ufrgs.br Outubro de 2000 Resumo Considerações no desenvolvimento de software para processar dados XML. Processamento de uma DTD para interpretar marcação

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

(STUDY OF AGILITY IN SOFTWARE DEVELOPMENT PROCESS WITH TEAMS AT DIFFERENT WORK UNITS USING A ON-LINE MANAGEMENT TOOL)

(STUDY OF AGILITY IN SOFTWARE DEVELOPMENT PROCESS WITH TEAMS AT DIFFERENT WORK UNITS USING A ON-LINE MANAGEMENT TOOL) ESTUDO DE AGILIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE COM EQUIPES EM DIFERENTES UNIDADES DE TRABALHO UTILIZANDO UMA FERRAMENTA DE GERENCIAMENTO ON-LINE (STUDY OF AGILITY IN SOFTWARE DEVELOPMENT

Leia mais

Polycom RealPresence Content Sharing Suite Guia rápido do usuário

Polycom RealPresence Content Sharing Suite Guia rápido do usuário Polycom RealPresence Content Sharing Suite Guia rápido do usuário Versão 1.2 3725-69877-001 Rev.A Novembro de 2013 Neste guia, você aprenderá a compartilhar e visualizar conteúdos durante uma conferência

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos SOFTWARE PROCESSES Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Introduzir modelos de processo de software Descrever uma variedade de modelos de processo

Leia mais

Guia do Cúram Verification

Guia do Cúram Verification IBM Cúram Social Program Management Guia do Cúram Verification Versão 6.0.5 IBM Cúram Social Program Management Guia do Cúram Verification Versão 6.0.5 Nota Antes de usar essas informações e o produto

Leia mais

Conteúdo Programático de PHP

Conteúdo Programático de PHP Conteúdo Programático de PHP 1 Por que PHP? No mercado atual existem diversas tecnologias especializadas na integração de banco de dados com a WEB, sendo o PHP a linguagem que mais se desenvolve, tendo

Leia mais

MicrovixPOS Requisitos, Instalação e Execução

MicrovixPOS Requisitos, Instalação e Execução MicrovixPOS Requisitos, Instalação e Execução Autor Público Alvo Rodrigo Cristiano dos Santos Suporte Técnico, Consultoria e Desenvolvimento. Histórico Data 13/06/2012 Autor Rodrigo Cristiano Descrição

Leia mais

Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson

Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson QUALIDADE Simpósio Brasileiro de Qualidade de Software - SBQS Instituto Nokia de Tecnologia Unit Test Sucess Bug INdT Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Criando documentação com javadoc

Criando documentação com javadoc H Criando documentação com javadoc H.1 Introdução Neste apêndice, fornecemos uma introdução a javadoc ferramenta utilizada para criar arquivos HTML que documentam o código Java. Essa ferramenta é usada

Leia mais

Escolha e implantação de uma metodologia de desenvolvimento de software: um estudo de caso para o Laboratório de Aplicação em Tecnologia da Informação

Escolha e implantação de uma metodologia de desenvolvimento de software: um estudo de caso para o Laboratório de Aplicação em Tecnologia da Informação Escolha e implantação de uma metodologia de desenvolvimento de software: um estudo de caso para o Laboratório de Aplicação em Tecnologia da Informação Elton A. dos Santos Departamento de Informática e

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais