WatiN ou sélénium? [fermé]

Je vais bientôt commencer à coder des tests automatisés de notre présentation. Il semble que tout le monde recommande WatiN et Selenium . Lequel préférez-vous pour les tests automatisés des formulaires Web ASP.NET? Lequel de ces produits vous convient le mieux?

En passant, j'ai remarqué que WatiN 2.0 est en CTP depuis mars 2008, est-ce quelque chose dont il faut s'inquiéter?

Je veux juste dire que je travaille actuellement dur sur une version bêta de WatiN 2.0 quelque part au premier trimestre de 2009. Ce sera une mise à niveau majeure des versions actuelles de CTP 2.0 et vous donnera essentiellement les mêmes fonctionnalités pour automatiser FireFox et IE que la version 1.3.0 propose d'automatiser IE.

Donc pas de soucis là-bas.

J'espère que cela vous aidera à faire votre choix Jeroen van Menen Lead dev WatiN

Si vous cherchez à faire un investissement sérieux à long terme dans un cadre qui continuera à être amélioré et soutenu par la communauté, Selenium est probablement votre meilleur pari. Par exemple, je viens de tomber sur cette information sur le blog de Matt Raible:

Vendredi, Google compte plus de 50 équipes exécutant plus de 51 000 tests par jour sur Selenium Farm interne. 96% de ces tests sont gérés correctement par Selenium RC et les machines Farm. Les 4% restants sont en partie dus à des bogues RC, en partie à des erreurs de test, mais en isoler la cause peut être difficile. Le sélénium a été adopté comme technologie principale pour les tests fonctionnels des applications Web au sein de Google. Voilà la bonne nouvelle.

Je suis également allé à l'une des rencontres Selenium récemment et j'ai appris que Google consacrait des ressources sérieuses à l'amélioration de Selenium et à son intégration avec WebDriver, un outil de test automatisé développé par Simon Stewart. L'un des principaux avantages de WebDriver est qu'il contrôle le navigateur lui-même plutôt que de s'exécuter à l'intérieur du navigateur en tant qu'application Javascript, ce qui signifie que les principales pierres d'achoppement comme le problème de la «même origine» ne seront plus un problème.

Nous avons testé les deux et décidé d'aller avec WaTiN. Comme d'autres l'ont souligné, Selenium a quelques fonctionnalités intéressantes qui ne se trouvent pas dans WaTiN, mais nous avons rencontré des problèmes pour faire fonctionner Selenium et une fois que nous l'avons fait, il était certainement plus lent lors de l'exécution des tests que WaTiN. Si je me souviens bien, les problèmes de configuration que nous avons rencontrés provenaient du fait que Selenium avait une application distincte pour contrôler le navigateur réel où WaTiN faisait tout en cours.

J'ai essayé les deux et voici mes premières pensées ...

WatiN

Le bon

• Exécution rapide.
• Les outils de création de scripts sont des projets indépendants; il y en a 2 que je connais: Wax (basé sur Excel, hébergé sur CodePlex) et WatiN Test Record (hébergé sur SourceForge). Ni l'un ni l'autre n'est aussi robuste que Selenium IDE.
• Très bon support IE. Peut attacher et se détacher vers / des instances en cours d'exécution. Peut accéder aux poignées de fenêtre natives, etc. (voir l'exemple de script ci-dessous).
• NuGet emballé, facile à exécuter dans .NET, environnements de style Visual Studio et à maintenir à jour.

Le mauvais

• Googler WatiN (watin xyz) amène souvent Google à recommander "watir xyz" à la place. Pas beaucoup de documentation là-bas.
• Le peu qu'il y a (documentation), c'est déroutant; par exemple: à première vue, il semblerait qu'il n'y ait pas de support natif pour les sélecteurs CSS. D'autant qu'il existe des bibliothèques d'extensions comme 'WatiNCssSelectorExtensions' et de nombreux articles de blog sur des techniques alternatives (comme l'injection de jQuery / sizzle dans la page). Sur Stack Overflow, j'ai trouvé un commentaire de Jeroen van Menen qui suggère qu'il existe un support natif. Au moins, le développeur principal passe du temps sur Stack Overflow :)
• Pas de support XPath natif.
• Aucune exécution à distance prête à l'emploi / exécution basée sur la grille.

Exemple de script (C #). Vous ne pouvez pas faire cela avec Selenium (pas que je sache, du moins):

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;
    }
}

Sélénium

• Plus lent que WatiN (d'autant plus qu'un nouveau process doit être créé).
• Sélecteurs CSS intégrés / support XPath.
• Selenium IDE est bon (je ne peux pas dire génial, mais c'est le meilleur de sa catégorie!).
• On se sent plus Java-ish que .NET-ish ... mais vraiment, c'est un langage de programmation indépendant; toutes les commandes sont envoyées à un «pilote» hors processus. Le pilote est vraiment un processus «hôte» pour l'instance de navigateur. Toutes les communications doivent être sérialisées d'entrée / sortie au-delà des limites du processus, ce qui pourrait expliquer les problèmes de vitesse relatifs à WatiN.
• Processus découplés - «Driver» et «Control» signifient plus de robustesse, plus de complexité, etc., mais aussi plus faciles à créer des grilles / environnements de test distribués. J'aurais vraiment aimé que le mécanisme de «distribution» (c'est-à-dire la communication entre le pilote et le contrôle) se fasse via WebSphere ou un autre gestionnaire de files d'attente de messages robuste et existant.
• Prend en charge Chrome et autres navigateurs prêts à l'emploi.

Malgré tout, je suis finalement allé avec WatiN; J'ai principalement l'intention d'écrire de petites applications de capture d'écran et je souhaite utiliser LINQPad pour le développement. La connexion à une instance IE distante (que je n'ai pas engendrée moi-même) est un gros plus. Je peux bidouiller dans une instance existante ... puis exécuter un peu de script ... puis jouer à nouveau, etc. jouer directement avec le navigateur.

La plus grande différence est que Selenium prend en charge différents navigateurs (pas seulement IE ou FF, voir http://seleniumhq.org/about/platforms.html#browsers .

De plus, Selenium dispose d'un serveur de contrôle à distance ( http://seleniumhq.org/projects/remote-control/ ), ce qui signifie que vous n'avez pas besoin d'exécuter le navigateur sur la même machine que le code de test est en cours d'exécution. Vous pouvez donc tester votre application Web. sur différentes plates-formes OS.

En général, je recommanderais d'utiliser Selenium. J'ai utilisé WatiN il y a quelques années, mais je n'étais pas satisfait de sa stabilité (il s'est probablement amélioré maintenant). Le plus gros avantage de Selenium pour moi est le fait que vous pouvez tester l'application Web. sur différents navigateurs.

Ni. Utilisez Ragondin. Il enveloppe le sélénium. Beaucoup plus durable. https://github.com/featurist/coypu

Mettez à jour Ye Oliver, vous avez raison. Ok pourquoi est-ce mieux? Personnellement, j'ai trouvé que le pilote Selenium pour IE en particulier était très fragile - il existe un certain nombre d'exceptions de pilote `` standard '' que j'ai à nouveau trouvées lors de la conduite de Selenium pour des tests unitaires sur des sites Web lourds ajax.

Ai-je mentionné que je voulais écrire mes scripts en c # en tant que projet de test? Oui Tests d'acceptation dans un déploiement de build continu.

Eh bien Coypu s'occupe de ce qui précède. C'est un wrapper pour Selenium qui permet des montages de test tels que,

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

... qui lancera un navigateur (de marque configurable) et exécutera le script. Il fonctionne très bien avec les régions étendues et est TRÈS extensible.

Il y a plus d'exemples sur GitHub et comme le mentionne Olvier ci-dessous, la vidéo d'Adrian est excellente. Je pense que c'est le meilleur moyen de conduire des tests basés sur un navigateur dans le monde .Net et essaie de suivre son homonyme Rubycapybara

J'ai utilisé les deux, ils semblent tous les deux fonctionner correctement. Mon signe de tête est pour Selenium car il semblait avoir un meilleur support Ajax. Je crois que WaTiN a mûri depuis la dernière fois que je l'ai utilisé, il devrait donc avoir la même chose.

Le plus important serait dans quel environnement de développement aimez-vous être? Selenium et Watin ont des enregistreurs mais Selenium est dans le navigateur et watin est en studio visuel. + et-pour les deux.

Jusqu'à présent, nous sommes un pur Microsoft Shop pour fournir des solutions pour l'entreprise et avons opté pour WatiN. Cela peut changer à l'avenir.

En tant que source plus récente:

Microsoft a imprimé dans MSDN Magazine 12/2010 un BDD-Primer avec la combinaison de SpecFlow avec WatiN (cool BDD-Behavior Driven Development). Son auteur Brandon Satrom (msft Developer Evangelist) a également publié en décembre 2010 un Webcast vidéo enseignant en détail 1: 1 ses résultats ci-dessus.

Il y a un livre blanc de 04/2011 sur le soutien ATDD / BDD avec SpecLog, SpecFlow et Team Foundation Server (Acceptance Test Driven Development / Comportement Driven Development) de Christian Hassa , dont l' équipe construit SpecFlow.

J'utilise Watin, mais je n'ai pas utilisé Selenium. Je peux dire que je suis rapidement opérationnel sur Watin et que j'ai eu peu ou pas de problèmes. Je ne peux penser à rien de ce que j'ai voulu faire que je ne pourrais pas comprendre. HTH

J'utilise généralement Selenium, principalement parce que j'aime le plugin Selenium IDE pour FireFox pour enregistrer les points de départ de mes tests.

Je recommande WebAii car c'est ce avec quoi j'ai eu du succès et lors de son utilisation, mes plaintes étaient rares. Je n'ai jamais essayé Selenium et je ne me souviens pas avoir beaucoup utilisé WaTiN, du moins pas au point de le faire fonctionner avec succès. Je ne connais aucun cadre qui traite avec élégance les dialogues Windows, bien que WebAii dispose d'une interface pour implémenter vos propres gestionnaires de dialogue.

J'ai envisagé d'utiliser les deux. J'ai utilisé l'enregistreur pour Selenium pour construire quelques tests dans FF. J'ai essayé de faire la même chose dans Watin et j'ai trouvé que le Watin Recorder (2.0.9.1228) ne valait absolument rien pour nos sites . Il semblait rendre le site dans IE6 - rendant notre site effectivement inutilisable pour l'enregistrement. Nous ne prenons pas en charge IE6. Je n'ai trouvé aucun moyen de changer le navigateur qu'il utilise. Je n'ai trouvé qu'un seul enregistreur Watin là-bas. S'il y en a plus d'un, ou s'il y en a un qui est tenu à jour, veuillez commenter.

L'IDE Selenium Recorder pour Firefox est simple à utiliser et transfère les tests en C #. Ce n'est pas génial pour ça. Je ne pouvais pas faire fonctionner les suites de tests de portage, malgré la lecture d'un article de blog ou deux qui contenaient des solutions de contournement. Il y a donc un peu de manipulation du code généré. Pourtant, cela fonctionne à 90% et c'est mieux que l'alternative.

Pour mon argent / temps, Selenium est supérieur juste pour la facilité de créer de nouveaux tests . IE n'a pas de bonnes barres d'outils de développement qui soient aussi bonnes que Firebug , donc je fais mon développement dans Firefox pour commencer, donc avoir un bon enregistreur fonctionnel dans Firefox est un énorme bonus.

Ma conclusion ici ressemblait beaucoup à la citation de Churchill sur la démocratie: le sélénium est la pire forme de test automatisé de l'interface utilisateur. Sauf pour tous les autres.

Au risque de partir sur une tangente, je recommanderais Ax / WatiN. Ax permet aux tests d'être écrits dans Excel par des testeurs «manuels» sans aucune connaissance du «langage» du test sous-jacent. Il faut un «technicien» pour écrire les actions sur mesure (IE. Aujourd'hui, j'ai dû faire une recherche de table et des références croisées légèrement complexes) mais une fois écrites, les actions peuvent être utilisées dans les tests par les testeurs non techniques.

J'ai également entendu dire que le projet UK Government Gateway (qui, je crois, a 6K + tests automatisés) a récemment porté tous ses tests d'Axe / Winrunner à Axe / Watin en une semaine !! Et beaucoup de tests sont assez complexes - je sais, car j'y ai travaillé il y a quelques années ...

Je regarde Selenium pour le moment, car un client potentiel l'utilise. Mais je suggère un petit regard sur Axe en tant que couche au-dessus de l'outil «cheval de travail».

Si vous devez accéder aux iframes, aux boîtes de dialogue modales et aux iframes interdomaines, WatiN est une solution. Selenium ne pouvait pas gérer les iframes qu'il lançait des exceptions commandtimeout. WatiN vous pouvez faire beaucoup plus de choses surtout si le site Web utilise des trucs spécifiques à IE comme ShowModalDialog etc. WatiN les gère tous très bien. Je pourrais même faire un accès iframe interdomaine.

Vous devrez faire les deux si vous devez faire des tests IE et FF, mais ils ne fonctionneront que très bien pour les tests de présentation. Ils ne peuvent pas détecter si un élément est légèrement éteint, juste que les éléments sont présents. Je ne connais rien qui puisse remplacer l'œil humain pour les tests d'interface utilisateur / de présentation, bien que vous puissiez faire quelques choses pour l'aider (prendre des captures d'écran des pages à chaque étape pour que les utilisateurs les examinent).