WatiN ou Selenium? [fechadas]

Vou começar a codificar alguns testes automatizados da nossa apresentação em breve. Parece que todo mundo recomenda WatiN e Selenium . Qual você prefere para o teste automatizado de formulários da Web do ASP.NET? Qual desses produtos funciona melhor para você?

Como uma observação lateral, notei que o WatiN 2.0 está no CTP desde março de 2008, é algo para se preocupar?

Só quero dizer que atualmente estou trabalhando duro em uma versão beta do WatiN 2.0 em algum lugar no primeiro trimestre de 2009. Será uma grande atualização para as versões atuais do CTP 2.0 e basicamente fornecerá a mesma funcionalidade para automatizar o FireFox e o IE como A versão 1.3.0 oferece para automatizar o IE.

Portanto, não há preocupações lá.

Espero que isso ajude a fazer sua escolha Jeroen van Menen Lead dev WatiN

Se você deseja fazer um investimento sério a longo prazo em uma estrutura que continuará sendo aprimorada e apoiada pela comunidade, o Selenium é provavelmente a sua melhor aposta. Por exemplo, encontrei esta informação no blog de Matt Raible:

Na sexta-feira, o Google tem mais de 50 equipes executando mais de 51 mil testes por dia no Selenium Farm interno. 96% desses testes são tratados corretamente pelo Selenium RC e pelas máquinas agrícolas. Os outros 4% são em parte devido a erros de RC, em parte para testar erros, mas isolar a causa pode ser difícil. O Selenium foi adotado como a principal tecnologia para testes funcionais de aplicativos da Web no Google. Essa é a boa notícia.

Também fui recentemente a um dos encontros do Selenium e aprendi que o Google está investindo muito em melhorar o Selenium e integrá-lo ao WebDriver, uma ferramenta de teste automatizada desenvolvida por Simon Stewart. Uma das principais vantagens do WebDriver é que ele controla o próprio navegador em vez de ser executado dentro do navegador como um aplicativo Javascript, o que significa que grandes obstáculos como o problema da "mesma origem" não serão mais um problema.

Testamos os dois e decidimos seguir com o WaTiN. Como outros já apontaram, o Selenium possui alguns recursos interessantes não encontrados no WaTiN, mas tivemos problemas ao fazer o Selenium funcionar e, uma vez que o fizemos, foi definitivamente mais lento ao executar testes do que o WaTiN. Se bem me lembro, os problemas de configuração que encontramos surgiram do fato de o Selenium ter um aplicativo separado para controlar o navegador em que o WaTiN fazia tudo em processo.

Eu os experimentei e aqui estão meus pensamentos iniciais ...

WatiN

O bom

• Execução rápida.
• As ferramentas de criação de scripts são projetos independentes; Existem dois que eu conheço: Wax (baseado no Excel, hospedado no CodePlex) e WatiN Test Record (hospedado no SourceForge). Nem é tão robusto quanto o Selenium IDE.
• Muito bom suporte ao IE. Pode anexar e desanexar para / de instâncias em execução. Pode acessar identificadores de janela nativos etc. (Veja o exemplo de script abaixo).
• Pacote NuGet, fácil de executar nos ambientes estilo .NET, Visual Studio e atualizado.

O mal

• A pesquisa no WatiN (watin xyz) geralmente faz com que o Google recomende "watir xyz". Não há muita documentação por aí.
• O pouco que há (documentação), é confuso; por exemplo: à primeira vista, parece que não há suporte nativo para seletores CSS. Especialmente porque existem bibliotecas de extensões como 'WatiNCssSelectorExtensions' e muitos artigos de blog sobre técnicas alternativas (como injetar jQuery / sizzle na página). No Stack Overflow, encontrei um comentário de Jeroen van Menen que sugere que existe suporte nativo. Pelo menos o desenvolvedor líder gasta tempo no Stack Overflow :)
• Não há suporte XPath nativo.
• Nenhuma execução remota pronta para uso / execução baseada em grade.

Exemplo de script (C #). Você não pode fazer isso com o Selenium (pelo menos eu não sei):

class IEManager
{
    IE _ie = null;
    object _lock = new object();

    IE GetInstance(string UrlFragment)
    {
        lock (_lock)
        {
            if (_ie == null)
            {
                var instances = new IECollection(true);  //Find all existing IE instances
                var match = instances.FirstOrDefault(ie=>ie.Url.Contains(UrlFragment));
                _ie = match ?? new IE();
                if (match==null)  //we created a new instance, so we should clean it up when done!
                    _ie.AutoClose = true;
            }
        }

        return _ie;
    }
}

Selênio

• Mais lento que o WatiN (especialmente porque um novo processo precisa ser criado).
• Seletores CSS embutidos / suporte XPath.
• O Selenium IDE é bom (não pode ser ótimo, mas é o melhor da classe!).
• Parece mais Java-ish do que .NET-ish ... mas, na verdade, é independente da linguagem de programação; todos os comandos são enviados para um 'Driver' fora de processo. O driver é realmente um processo de "host" para a instância do navegador. Toda comunicação deve ser serializada dentro / fora dos limites do processo, o que pode explicar os problemas de velocidade relativos ao WatiN.
• Processos dissociados - "Driver" e "Control" significam mais robustez, mais complexidade etc., mas também são mais fáceis de criar grades / ambientes de teste distribuídos. Teria realmente gostado se o mecanismo de "distribuição" (ou seja, a comunicação entre Driver & Control) fosse através do WebSphere ou outro gerenciador de filas de mensagens robusto e existente.
• Suporte Chrome e outros navegadores prontos para uso.

Apesar de tudo, eu fui com o WatiN no final; Pretendo principalmente escrever pequenos aplicativos de captura de tela e quero usar o LINQPad para desenvolvimento. Anexar a uma instância remota do IE (que eu não criei) é uma grande vantagem. Posso mexer em uma instância existente ... depois executar um pouco de script ... depois mexer novamente etc. Isso é mais difícil de fazer com o Selenium, embora eu suponha que "pausas" possam ser incorporadas no script durante o qual eu poderia mexer diretamente com o navegador.

A maior diferença é que o Selenium tem suporte para diferentes navegadores (não apenas o IE ou o FF, consulte http://seleniumhq.org/about/platforms.html#browsers .

Além disso, o Selenium possui um servidor de controle remoto ( http://seleniumhq.org/projects/remote-control/ ), o que significa que você não precisa executar o navegador na mesma máquina em que o código de teste está sendo executado. Portanto, você pode testar seu aplicativo Web. em diferentes plataformas de SO.

Em geral, eu recomendaria o uso do Selenium. Eu usei o WatiN alguns anos atrás, mas não estava satisfeito com sua estabilidade (provavelmente já melhorou). A maior vantagem do Selenium para mim é o fato de que você pode testar o aplicativo Web. em navegadores diferentes.

Nem. Use Coypu. Envolve o selênio. Muito mais durável. https://github.com/featurist/coypu

Atualize Ye Oliver, você está certo. Ok, por que é melhor? Pessoalmente, achei o driver Selenium para o IE em particular muito frágil - há várias exceções de driver 'padrão' que encontrei mais uma vez ao dirigir o Selenium for Unit Tests em sites pesados ​​ajax.

Eu mencionei que quero escrever meus scripts em c # como um projeto de teste? Sim Testes de aceitação em uma implantação de compilação contínua.

Bem, Coypu lida com o exposto acima. É um invólucro para o Selenium que permite equipamentos de teste como,

browser.Visit("file:///C:/users/adiel/localstuff.htm")
browser.Select("toyota").From("make");
browser.ClickButton("Search");

... que ativará um navegador (marca configurável de) e executará o script. Funciona muito bem com regiões com escopo definido e é MUITO extensível.

Há mais exemplos no GitHub e, como menciona Olvier abaixo, o vídeo de Adrian é excelente. Eu acho que é a melhor maneira de conduzir testes baseados em navegador no mundo .Net e tenta seguir seu xará Rubycapybara

Eu usei os dois, ambos parecem funcionar bem. Meu aceno é para o Selenium, pois parecia ter um melhor suporte ao Ajax. Acredito que o WaTiN tenha amadurecido desde a última vez que o usei, por isso deve ter a mesma coisa.

O mais importante seria em que ambiente de desenvolvimento você gostaria de estar? Selenium e Watin têm gravadores, mas o Selenium está no navegador e o watin está no visual studio. + e - para ambos.

Até agora, somos uma Microsoft Shop pura para fornecer soluções para a empresa e fomos com a WatiN. Isso pode mudar no futuro.

Como fonte mais recente:

A Microsoft imprimiu na MSDN Magazine 12/2010 um BDD-Primer com a combinação do SpecFlow com o WatiN (legal BDD-Behavior Driven Development). Seu autor Brandon Satrom (msft Developer Evangelist) também publicou em dezembro de 2010 um Video Webcast ensinando detalhadamente 1: 1 suas descobertas acima.

Há um whitepaper de 04/2011 sobre o suporte ao ATDD / BDD com SpecLog, SpecFlow e Team Foundation Server (desenvolvimento orientado a testes de aceitação / desenvolvimento orientado a comportamentos) de Christian Hassa , cuja equipe construiu o SpecFlow.

Eu uso Watin, mas não usei Selenium. Posso dizer que comecei a trabalhar rapidamente com Watin e tive poucos ou nenhum problema. Não consigo pensar em nada que quisesse fazer que não conseguisse descobrir. HTH

Geralmente uso o Selenium, principalmente porque gosto do plugin Selenium IDE do FireFox para registrar pontos de partida para os meus testes.

Eu recomendo o WebAii, pois é com isso que tenho tido sucesso e, quando o uso, minhas queixas foram poucas. Eu nunca experimentei o Selenium e não me lembro de usar muito o WaTiN, pelo menos até o ponto em que consegui que ele funcionasse com sucesso. Não conheço nenhuma estrutura que lide com as caixas de diálogo do Windows normalmente, embora o WebAii tenha uma interface para implementar seus próprios manipuladores de caixas de diálogo.

Eu considerei usar os dois. Eu usei o gravador do Selenium para criar alguns testes em FF. Tentei fazer o mesmo no Watin e descobri que o Watin Recorder (2.0.9.1228) é completamente inútil para nossos sites . Parecia renderizar o site no IE6 - tornando nosso site efetivamente inutilizável para gravação. Não suportamos o IE6. Não consegui encontrar nenhuma maneira de alterar o navegador que está usando. Eu só encontrei um Watin Recorder por aí. Se houver mais de um ou um atualizado, por favor, comente.

O Selenium Recorder IDE para Firefox é simples de usar e executa testes em C #. Não é ótimo nisso. Não consegui portar as suítes de teste para trabalhar, apesar de ler uma ou duas postagens no blog que tinham soluções alternativas. Portanto, há um pouco de manipulação do código gerado. Ainda assim, funciona 90% e é melhor que a alternativa.

Pelo meu dinheiro / tempo, o Selenium é superior apenas pela facilidade de criar novos testes . O IE não possui boas barras de ferramentas para desenvolvedores que sejam tão boas quanto o Firebug ; portanto, estou começando meu desenvolvimento no Firefox, portanto, ter um bom gravador de trabalho no Firefox é um bônus enorme.

Minha conclusão aqui foi muito parecida com a citação de democracia de Churchill: Selenium é a pior forma de teste automatizado de interface do usuário. Exceto por todos os outros.

Correndo o risco de sair pela tangente, eu recomendaria o Ax / WatiN. O Ax permite que os testes sejam escritos no Excel por testadores 'manuais', sem conhecimento da 'linguagem' subjacente do teste. Ele precisa de um 'Técnico' para escrever as ações sob medida (IE. Hoje eu tive que fazer uma consulta e referência cruzada da tabela um pouco complexa), mas uma vez escritas, as ações podem ser usadas em testes pelos testadores não técnicos.

Também ouvi dizer que o projeto Gateway do Governo do Reino Unido (que acredito ter mais de 6 mil testes automatizados) recentemente portou todos os seus testes de Ax / Winrunner a Ax / Watin dentro de uma semana! E muitos dos testes são bastante complexos - eu sei que trabalhei nisso alguns anos atrás ...

Estou olhando para o Selenium no momento, como um potencial cliente o usa. Mas sugiro uma pequena olhada em Ax como uma camada acima da ferramenta 'cavalo de trabalho'.

Se você precisar acessar iframes, diálogos modais e iframes entre domínios, o WatiN é um caminho a percorrer. O Selenium não conseguia lidar com os iframes que estavam lançando exceções de tempo limite do comando. No WatiN, você poderia fazer muito mais coisas, especialmente se o site usar coisas específicas do IE, como ShowModalDialog, etc. O WatiN lida com todas elas muito bem. Eu poderia até fazer acesso iframe entre domínios.

Você precisará fazer as duas coisas se precisar fazer testes no IE e no FF, mas eles só funcionarão tão bem nos testes de apresentação. Eles não conseguem detectar se um elemento está ligeiramente desligado, apenas que os elementos estão presentes. Não sei de nada que possa substituir o olho humano para testes de interface do usuário / apresentação, embora você possa fazer algumas coisas para ajudá-lo (faça capturas de tela das páginas em cada etapa para os usuários revisarem).