anselmo alves

Recentes discussões sobre desempenho e escalabilidade de sistemas me levaram a seguinte questão: por que não se fala em frameworks e sistemas web server-side compilados diretamente para assembly nativo?

Este é um fenômeno curioso para mim, já que aplicações interpretadas (e até as compiladas para uma virtual machine), são menos performáticas. Quero que fique claro que não acredito que o uso de aplicações compiladas seja a solução para problemas de performance. Estas questões precisam ser primariamente endereçadas a melhorias arquiteturais e infraestruturais desenhadas para cada aplicação particular. Apenas questiono o fato de nós desenvolvedores, na grande maioria dos casos, não considerarmos essa hipótese ao desenvolver uma aplicação web, ou mesmo como meio de otimizar sistemas específicos cuja performance é crítica.

Por exemplo, ainda que soluções Java tenham desempenho excelente em muitos casos, seria muito interessante e perfeitamente justificável, do meu ponto de vista, o desenvolvimento de um framework para C++ que suportasse um esquema semelhante à tecnologia Servlet do Java - sem as limitações de performance de programas CGI - entre outras soluções web consagradas, além de bibliotecas que facilitassem o desenvolvimento de aplicações C++ para web.

É claro que não podemos negar que existem vantagens interessantes oferecidas pelas linguagens interpretadas neste campo. Mas, honestamente, não entendo porque o simples ganho de performance oferecido por aplicações nativas ainda não resultou no surgimento de pelo menos um framework desse gênero consolidado e de uma comunidade de desenvolvedores que, assim como eu, são aficionados por desempenho.

Neste post inaugural, vamos demonstrar uma maneira de facilitar o trabalho de implementar testes de aceitação automatizados usando a extension Firefox Selenium IDE. Para ilustrar, tente fazer com o Selenium algum tipo de ação ou asserção sobre algum dos links da parte inferior do site www.google.com, por exemplo. Basicamente, há duas opções neste caso: ou clicar no link (com o botão direito ou esquerdo do mouse) para registrar uma ação/asserção, o que faz com que o Selenium automaticamente escreva um trecho de script, ou você pode escrever o script na mão. A primeira opção tem uma desvantagem: o Selenium poderá gravar como identificador do link o texto do link. Se o texto deste link mudar freqüentemente no site, você não vai querer identificá-lo desta maneira. A segunda opção sempre permite que você faça essa identificação pelo posicionamento desse elemento na árvore DOM do documento, por XPath.

No screencast abaixo, vamos demonstrar como o uso de duas outras extensions Firefox, o XPather e o Firebug, ajudam a descobrir rapidamente os XPaths dos elementos ao escrever os scripts.

Obs.: É necessário acrescentar uma barra (/) no início do XPath gerado para que o Selenium entenda.

P.S.: o Firebug é indispensável para uma infinidade de outras coisas. Portanto, se você gostar do XPather, mantenha as duas extensions instaladas.