Rodando testes offline com Selenium e Firefox

O Firefox tem um curioso "recurso" que consiste em colocar o browser em modo "offline" quando o computador se desconecta da rede. Isto se torna um pequeno estorvo quando, por exemplo, se está fora da rede e acessando uma aplicação web local e acaba sendo necessário desmarcar a opção "Work offline". Enfim, todo mundo que usa Firefox e desenvolve para a web já deve ter passado por isto. Até aí, nada demais. O "pequeno estorvo", porém, torna-se um problema real quando se utiliza Selenium com Firefox com o computador desconectado. Aparentemente, isto aqui resolve o problema, que também é possível de ser resolvido manualmente a partir da versão 3.6 do Firefox setando uma variável oculta no Firefox, mas acabaria caindo no antipadrão "works-on-my-machine", pois apenas o meu Firefox funcionaria offline, quando o correto seria que qualquer máquina que rodasse as specs do projeto pudesse fazê-lo sem atropelos.

Tive este problema inicialmente com o Capybara (Ruby) e uma boa alma já havia postado a solução, reproduzida abaixo, que utiliza a API do Capybara para definir a variável network.manage-offline-status, a tal "variável oculta" que citei no parágrafo anterior.

class Capybara::Driver::Selenium
  def self.driver
    unless @driver
      profile = Selenium::WebDriver::Firefox::Profile.new
      profile['network.manage-offline-status'] = false
      @driver = Selenium::WebDriver.for :firefox, :profile => profile
      at_exit do
        @driver.quit
      end
    end
    @driver
  end
end

Para aplicações Python, há até pouco tempo não tínhamos algo como o Capybara, até que outro grupo de boas almas, o Cobrateam, formado pelos ex-colegas de NSI Hugo Lopes e Gustavo Rezende e mais alguns membros da Globo.com, decidiram fazer algo semelhamnte para Python, o Splinter. Apesar de ser um projeto bastante recente, o Splinter já é um ótimo substituto para boa parte das tarefas do dia-a-dia de quem escreve testes de aceitação. Porém, o Splinter não possui uma API para acessar detalhes e/ou configurar o browser utilizado. Assim, consegui resolver o problema fazendo um hack no Selenium.

from selenium.firefox.firefox_profile import FirefoxProfile
prefs = FirefoxProfile._get_webdriver_prefs()
prefs['network.manage-offline-status'] = 'false'
@staticmethod
def prefs_func():
    return prefs
FirefoxProfile._get_webdriver_prefs = prefs_func

Por sinal, o Splinter é um projeto muito legal, vale a pena dar uma olhada e ajudar, nem que seja só falando bem dele no seu blog, como eu fiz aqui :P Give back to open-source!

Update (05/01/2011, 13h50m): Francisco Souza abriu um issue no Splinter para uma API que possibilite customizar o perfil do Firefox no Webdriver, evitando - do ponto de vista do cliente do Splinter - o tipo de acesso de baixo nível mostrado aqui.

"Agile" nunca mais

Outro dia, em uma thread na lista de discussão do núcleo de pesquisa onde trabalho (a.k.a. glorioso NSI), debatíamos a respeito de uma palestra apresentada na Agile Conference 2009, chamada "Let's stop calling it 'agile'", em cujo resumo constava:

Agile development has grown a lot since its rebeleous 2001 start. In fact, it has grown to be the mainstream way of developing software. The time has come to drop the word 'agile.' Agile development is just modern practices in software development. There is no need to explicitly mark practices as Agile. There is no need anymore for opposing camps. Keeping the word Agile and things like ""the Agile conference"" is holding the development of modern SW development practices back.

Ou, em português:

O desenvolvimento ágil cresceu bastante desde seu início em 2001. De lá pra cá, se tornou o modo "mainstream" de desenvolver software. É chegada a hora de abandonar a palavra "ágil". Desenvolvimento ágil é tão-somente o uso de técnicas modernas no desenvolvimento de software. Não há necessidade de nomear explicitamente estas práticas como ágeis. Não há mais necessidade para campos opostos. Manter a palavra "ágil" e coisas como "a Conferência Ágil" é atrasar a evolução das práticas modernas de desenvolvimento de software.

Eu não fui primeiro no NSI a repercutir a conversa: o Rogério Atem já falou sobre o assunto em seu blog. Com este post, quero apenas apresentar a discussão e oferecer meus dois centavos ao assunto. De cara, concordo plenamente com a ideia de que o termo "ágil" tem feito mais mal do que bem hoje em dia. Principalmente por ser relativamente fácil passar um verniz ágil em um projeto ("olha, estamos fazendo Scrum, temos daily meetings, post-its no vidro da janela, e agora o analista de sistemas se chama scrum master, tem até certificado"). Uma vez que está na moda ser "ágil", o modelo se prolifera como erva daninha. Mas isto é assunto para outro post.

A discussão, inicialmente, era sobre o agilismo e a preponderância, na academia, de um estranho ente teórico-prático chamado "modelo tradicional". Minha opinião é de que a camada pensante do mundo tradicional é cada vez mais um grupo deslocado em um mundo que já não mais compreende. Imagino como estariam fora de lugar em qualquer bom evento de desenvolvimento de software envolvendo desenvolvedores militantes (i.e. que efetivamente desenvolvem software), como, por exemplo, o Dev In Rio.

Vou tentar explicar melhor como eu vejo essa questão. A idéia de deixar a palavra "agile" de lado é simplesmente continuar vivendo a vida e trabalhando como se os métodos tradicionais fossem o que realmente são: uma etapa ultrapassada - e, hoje, sem qualquer sentido - da evolução da engenharia de software.

Tenho tentado seguir isto hoje em dia e deixado discussões envolvendo "métodos tradicionais" apenas para contextos específicos como aulas de disciplinas universitárias de "Análise de Sistemas" (pois a própria estrutura das grades de cursos de graduação tem visivelmente inscrita a cascata). Ou então em discussões diretas com tradicionalistas. Fora destes contextos, procuro simplesmente sustentar que TDD/BDD é o modo considerado correto de se criar grande parte aplicações modernas, que integração contínua é condição necessária para a saúde de um projeto, que ubiquitous language é uma obrigação em qualquer projeto de software que queira ter sucesso, que código limpo é um requisito para qualquer programador digno do nome. Sem precisar citar que são técnicas "ágeis" ou qualquer coisa do tipo. E normalmente ignorando completamente o fato de que existe, ou existiu, alguma outra coisa. Tradicionalismo, só em história da engenharia de software, arqueologia, sei lá.

Para quem está em ambientes modernos de desenvolvimento de software, tudo isto é chover no molhado, é o óbvio. Porém, a academia está muito longe disto, e é no "método tradicional" - o que quer que isto seja - que os estudantes ainda estão sendo educados.

Assim, penso que o melhor a fazer é apresentar os conceitos tidos como "ágeis" simplesmente como o modo certo de fazer engenharia de software e não como técnicas alternativas ou coisa do tipo. E apresentar rapidamente o tradicionalismo (caso alguém o traga à discussão) simplesmente como um conjunto de ideias ligado a um contexto técnico que já passou (linguagens de baixo nível, computadores pouco poderosos, ambientes de desenvolvimento precários, extrema dificuldade ou impossibilidade de verificação automatizada, inexistência de controle de versão etc). Em nichos específicos, como por exemplo EIS, agile ainda é "alternativo". Mas no geral, não há mais porque continuarmos uma briga (pelo menos no campo simbólico) com um adversário que já morreu de velho. Tratar o tradicionalismo como um adversário é reconhecer-lhe um valor que já não tem mais.

Let's stop calling it "agile"!