WatiN ou sélénium?
Je vais bientôt commencer à coder certains 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 dans CTP depuis mars 2008, est-ce quelque chose à craindre?
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 vers les versions actuelles de CTP 2.0 et vous donnera essentiellement les mêmes fonctionnalités pour automatiser FireFox et IE comme 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 découvrir cette information sur le blog de Matt Raible:
Vendredi, Google comptait plus de 50 équipes exécutant plus de 51 000 tests par jour sur la ferme interne de Selenium. 96% de ces tests sont correctement gérés par Selenium RC et les machines agricoles. Les 4% restants sont en partie dus à des bogues RC, en partie à des erreurs de test, mais 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é récemment à l'un des Meetups Selenium et j'ai appris que Google investit de sérieuses ressources pour améliorer Selenium et l'intégrer à WebDriver, qui est 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 principaux obstacles comme le problème de la "même origine" ne seront plus un problème.
Nous avons testé les deux et décidé de choisir WaTiN. Comme d'autres l'ont souligné, Selenium a des fonctionnalités intéressantes que l'on ne trouve pas dans WaTiN, mais nous avons rencontré des problèmes pour faire fonctionner Selenium et une fois que nous l'avons fait, il était définitivement plus lent lors de l'exécution de 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.
Je les ai essayés tous 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 IE support. Peut attacher et se détacher de/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) pousse 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 plus qu'il existe des bibliothèques d'extensions comme 'WatiNCssSelectorExtensions' et de nombreux articles de blog sur les 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 natif XPath.
- Aucune exécution à distance/exécution basée sur la grille prête à l'emploi.
Exemple de script (C #). Vous ne pouvez pas faire ça avec du sélénium (pas que je sache, au 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 processus doit être créé).
- Sélecteurs CSS intégrés/prise en charge XPath.
- Sélénium IDE est bon (je ne peux pas dire grand, mais c'est le meilleur de sa catégorie!).
- Sent plus Java-ish que .NET-ish ... mais vraiment, c'est un langage de programmation agnostique; 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 en entrée/sortie au-delà des limites du processus, ce qui pourrait expliquer les problèmes de vitesse par rapport à 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. Aurait vraiment aimé que le mécanisme de "distribution" (c'est-à-dire la communication entre Driver & Control) soit à travers WebSphere ou un autre gestionnaire de file d'attente de messages robuste et existant.
- Support chrome et autres navigateurs hors de la boîte.
Malgré tout, je suis finalement allé avec WatiN; J'ai principalement l'intention d'écrire de petites applications de grattage d'écran et je souhaite utiliser LINQPad pour le développement. Attacher à une télécommande IE instance (une que je n'ai pas moi-même engendrée) est un gros plus. Je peux tripoter dans une instance existante ... puis exécuter un peu de script ... puis violon, etc. C'est plus difficile à faire avec Selenium, bien que je suppose que des "pauses" pourraient être incorporées dans le script pendant ce temps, je pourrais tripoter 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 .
En outre, Selenium possède 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 test le code 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 du sélénium. 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é à ce jour). Le plus gros avantage de Selenium pour moi est le fait que vous pouvez tester l'application Web. sur différents navigateurs.
Ni. Utilisez Coypu. Il enveloppe le sélénium. Beaucoup plus durable. https://github.com/featurist/coyp
Mise à jour Vous avez raison, Oliver. Ok pourquoi est-ce mieux? Personnellement, j'ai trouvé le pilote Selenium pour IE en particulier pour être très fragile - il existe un certain nombre d'exceptions de pilote "standard" qui J'ai retrouvé du temps en conduisant Selenium pour les tests unitaires sur les sites Web ajax lourds.
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 fera tourner un navigateur (de marque configurable) et exécutera le script. Il fonctionne très bien avec les régions délimitées et est TRÈS extensible.
Il y a plus d'exemples sur GitHub et comme Olvier le mentionne ci-dessous, la vidéo d'Adrian est excellente. Je pense que c'est la meilleure façon de conduire des tests basés sur un navigateur dans le monde .Net et essaie de suivre son Ruby homonyme capybara
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.
La chose la plus importante 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 dans visual studio. + et-à tous les deux.
Jusqu'à présent, nous sommes un pur Microsoft Shop pour fournir des solutions pour l'entreprise et nous sommes allés avec WatiN. Cela pourrait changer à l'avenir.
Comme source plus récente:
Microsoft a imprimé en MSDN Magazine 12/201 un BDD-Primer avec la combinaison de SpecFlow avec WatiN (Cool BDD-Behavior Driven Development). Son auteur Brandon Satrom (évangéliste développeur msft) a également publié en décembre 2010 un Webcast vidéo enseignant en détail 1: 1 ses conclusions ci-dessus.
Il y a un Whitepaper de 04/2011 sur Supporting ATDD/BDD with SpecLog, SpecFlow and Team Foundation Server (Acceptance Test Driven Development/Behavior Driven Development) de Christian Hassa , dont l'équipe a construit SpecFlow.
J'utilise Watin, mais je n'ai pas utilisé de sélénium. Je peux dire que je me suis rapidement installé sur Watin et que j'ai eu peu ou pas de problèmes. Je ne peux penser à rien de ce que je voulais faire que je ne pouvais pas comprendre avec. 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 quand je l'ai utilisé, mes reproches étaient peu nombreux. Je n'ai jamais essayé Selenium et je ne me souviens pas avoir beaucoup utilisé WaTiN, du moins pas au point où je pourrais le faire fonctionner avec succès. Je ne connais aucun framework qui traite avec élégance les dialogues Windows, bien que WebAii dispose d'une interface pour implémenter vos propres gestionnaires de dialogues.
J'ai envisagé d'utiliser les deux. J'ai utilisé l'enregistreur pour Selenium pour construire des tests en FF. J'ai essayé de faire la même chose dans Watin et j'ai trouvé que le Watin Recorder (2.0.9.1228) est complètement sans valeur pour nos sites. Il semble que le site soit rendu dans IE6, ce qui rend 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. S'il y en a plus d'un, ou un qui est tenu à jour, veuillez commenter.
L'enregistreur Selenium IDE pour Firefox est simple à utiliser et transfère les tests en C #. Ce n'est pas génial. Je n'ai pas pu faire fonctionner les suites de tests de portage, malgré la lecture d'un article de blog ou deux qui avaient 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, le sélénium est supérieur juste pour la facilité de construire de nouveaux tests. IE n'a pas de bonnes barres d'outils pour développeurs qui sont presque aussi bonnes que Firebug, donc je fais mon développement dans Firefox pour commencer, donc avoir un bon enregistreur de travail dans Firefox est un énorme bonus.
Ma conclusion ici ressemblait beaucoup à cette citation sur la démocratie de Churchill: Le sélénium est la pire forme de test automatisé de l'interface utilisateur. Sauf pour tous les autres.
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 de timeout de commande. WatiN vous pourriez faire beaucoup plus de choses, surtout si le site Web utilise IE des trucs spécifiques comme ShowModalDialog, etc. WatiN les gère très bien. Je pourrais même faire un accès iframe entre domaines.
Au risque de partir sur une tangente, je recommanderais Ax/WatiN. Axe permet aux tests d'être écrits dans Excel par des testeurs "manuels" sans connaissance du "langage" de test sous-jacent. Il a besoin d'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-techy.
J'ai également entendu que le projet UK Government Gateway (qui, je crois, a 6K + tests automatisés) a récemment transféré tous leurs tests d'Ax/Winrunner vers Ax/Watin en une semaine !! Et bon nombre des tests sont assez complexes - je sais que j'y ai travaillé il y a quelques années ...
Je regarde Selenium en ce moment, car un client potentiel l'utilise. Mais je suggère un petit regard sur Axe comme une couche au-dessus de l'outil "cheval de travail".