Tendo em vista que o que vamos aprender neste artigo é como utilizar scripts síncronos e assíncronos, um dos principais conceitos que devemos entender é “o que é sincronia”. Dizemos que duas coisas são síncronas quando há uma exata coincidência no tempo ou no ritmo delas. No esporte, sempre ouvimos falar em nado sincronizado, onde as atletas coincidem todos os movimentos do início ao fim da execução da coreografia.

Na computação, quando uma tarefa precisa aguardar a tarefa anterior ser concluída para iniciar sua execução, dizemos que estas tarefas são síncronas. Por outro lado, vamos supor agora que duas ou mais tarefas precisam ser executadas e que não há nenhuma dependência entre elas. Ganharíamos tempo se elas fossem executadas ao mesmo tempo, contanto que o instante de conclusão de cada uma não importasse nem influenciasse a outra. Neste caso, dizemos que as tarefas foram executadas de forma assíncrona. Tais conceitos são fundamentais para entendermos como criar aplicações mais dinâmicas e interativas.

Sempre foi um grande desafio para os desenvolvedores de software para internet criar interfaces que fossem fáceis de operar, intuitivas e que procurassem minimizar a demora de comunicação com o servidor de internet para exibir dados na tela. Quando o conceito de AJAX surgiu, veio propondo uma nova abordagem de interação para o desenvolvimento de interfaces para internet. Algumas aplicações disponíveis na época de seu surgimento, como sítios de webmail, busca, mapas, mensagens instantâneas, entre outros, já utilizavam as tecnologias do AJAX. Tais sítios eram exemplos de inovação em interatividade.

Na época, já havia vários frameworks para o desenvolvimento da camada de apresentação das aplicações que procuravam atender às novas necessidades de evolução das interfaces web. Para o Java, a partir de 2004, lançaram o JavaServer Faces 1.0 (JSF), cujo objetivo era facilitar o desenvolvimento destas interfaces de usuário de aplicações Java para a internet. Com o Java EE 6, veio a versão 2.0 do JSF. Tal framework oferece recursos similares aos encontrados em interfaces para desktop, evita que equipes de desenvolvimento precisem dominar tecnologias como JavaScript, HTML e CSS, maximizava a produtividade dos desenvolvedores, auxilia na criação e reuso de componentes visuais e já vem com AJAX integrado.

Considerando vantagens como facilidade, interatividade, entre outras citadas até agora, neste artigo apresentaremos o que é AJAX, quais os benefícios do sincronismo/assincronismo propiciado por ele, quais as tecnologias envolvidas e veremos como ele está embutido no JSF 2 através de uma aplicação exemplo.


O que é AJAX
AJAX é o acrônimo de Asynchronous Javascript and XML, que em português significa “Javascript e XML assíncronos”. Entendendo melhor o significado, seria a chamada de um recurso no servidor a partir de um código Javascript no navegador web, de forma que o resultado atualize apenas uma parte da página sem precisar fazer uma atualização dela inteira. Esta chamada é assíncrona, ou seja, o script que a chamou continua sua execução sem esperar pela resposta. Quando o servidor responde, uma função Javascript especificada trata corretamente os dados retornados, fazendo a atualização de parte da tela apenas.
O termo AJAX foi criado por Jesse James Garrett, em 2005, em seu artigo chamado “Ajax: A New Approach to Web Applications” (AJAX: Uma Nova Abordagem para Aplicações Web), onde comparava a interatividade proporcionada pelas aplicações desktop com as aplicações web. Neste artigo, ele utiliza tal termo para referir-se ao uso conjunto de tecnologias que já existiam há muito tempo, como Javascript, DOM, CSS, XML, etc., para a criação de interfaces mais dinâmicas e responsivas ...

O ser humano é suscetível a erros. Quando programamos, procuramos sempre desenvolver uma lógica que implemente o que é requisitado por alguém ou que está especificado em algum documento. Muitas vezes, sem perceber, cometemos pequenos deslizes ao programar, mas continuamos acreditando que nosso código está coerente e consistente. Para verificar, rodamos a nossa aplicação e observamos seu comportamento e suas respostas aos nossos cliques e dados que digitamos. Não ocorreu nenhum erro? Então está perfeito. Será mesmo? E se testarmos com outros dados? Ao inserirmos dados inválidos propositalmente, qual seria o resultado? O que aconteceria se um laço while fosse executado mais vezes do que o esperado? No caso de nosso método possuir um if/else, nosso dado de teste fez o if ser executado? O else foi testado em algum momento?

Olhamos de novo, mais 10 vezes, e não conseguimos ver erro nenhum. Estamos certos de que o código está correto. Pelo menos, pressupomos que esteja. Para ampliarmos nossa certeza, vamos conhecer um pouco sobre Testes de Software e aprender algumas técnicas que nos mostram que, apenas com concentração e boa intenção, não conseguimos enxergar os problemas que estão presentes.

O que é Teste de Software?

Durante o processo de desenvolvimento, há os momentos de verificar se o software que estamos construindo está correto e se o que estamos desenvolvendo é o que o cliente ou o usuário realmente quer. Estes momentos de verificação fazem parte de um processo chamado Verificação e Validação, também referenciado como V & V, e devem ocorrer em várias fases da construção do software. Validação é o processo que visa garantir que se está construindo o programa que o cliente de fato deseja utilizar, com as funcionalidades que ele espera que estejam disponíveis. Ou seja, conseguimos compreender o que o cliente quer e o entregamos conforme acertado. Verificação é o processo de garantir que o produto de software está sendo bem construído, executando corretamente, mostrando as mensagens corretas, sem ocorrer falhas durante sua operação. Assim esperamos.

Teste de Software é parte integrante de V & V e corresponde ao processo que consiste de todas as atividades do ciclo de vida referentes à avaliação do software, com o objetivo de se determinar três coisas: (1) que o mesmo satisfaz aos requisitos especificados; (2) que o mesmo está apto para ser liberado para o cliente; (3) e para encontrar defeitos, motivo que todos pensam ser o único. Portanto, testar um programa não é apenas procurar erros, é um processo bem mais amplo, com seus papéis, atividades e artefatos resultantes.

Um Caso de Teste, que nós chamamos apenas de Teste, consiste de:

·         Um conjunto de valores de entrada para o sistema;

·         As ações a serem executadas pelo testador ou outro programa que interaja com o software que está sendo testado;

·         Os resultados esperados como consequências das ações executadas; e

·         As pós-condições, que são o resultado final gerado como consequência do que foi executado ao longo do teste.

 

Para conhecer os vários tipos de teste e entender em que momento eles se aplicam, veja a Figura 1, conhecida como Modelo V, que mostra como as atividades de teste podem ser integradas em cada fase do ciclo de vida de desenvolvimento. Quatro tipos diferentes são mostrados, onde cada um deles é aplicado em um nível diferente dos artefatos da aplicação, desde um simples método até o sistema inteiro. Por isso eles definem os Níveis de Teste.

Níveis de Teste – entendendo melhor

Vamos entender estes “níveis” melhor. Após a codificação do sistema, criação das classes, definição de seus atributos e implementação de seus métodos, iniciamos o desenvolvimento dos Testes Unitários, que consiste em checar se os métodos de uma classe funcionam corretamente (este é o foco deste artigo).

Depois que todos os métodos que interessam foram testados separadamente, inicia-se os Testes de Integração, onde se procura verificar a comunicação entre as classes. Por exemplo, procura-se verificar os resultados dos métodos de uma determinada classe quando chamados por métodos de outras. Nesta fase, vai-se integrando do nível mais granulado, de classe em classe, indo até componentes inteiros interagindo com outros, mas sempre observando as estruturas internas que estão sendo testadas nos códigos, suas condições e seus laços. Estes testes, os unitários e os de integração, são também chamados de “Testes de Caixa Branca”, porque estamos olhando o que há dentro do código-fonte

...