Comment WatiN fonctionne-t-il sous Windows Server 2008 avec IE8?

Question

Mon problème est que je ne peux pas obtenir un test WatiN simple pour travailler de manière fiable sur ma machine de développement qui exécute Windows Server 2008 et IE8.

J'ai vu quelques bons commentaires à ce sujet, mais j'ai toujours des problèmes. Voici les messages:

• MSDN Testing Article
• Stack Overflow - WatiN Second Method Fails

Les étapes du premier article semblaient aider (en commentaire ":: 1" dans mon fichier Hosts, mettre mon site (s) Dans les sites de confiance, et en m'assurant que mon app.config a "STA" et est mis à "copier si plus récent", mais ils n'ont pas aidé de manière fiable. "J'ai essayé le code du deuxième exemple en espérant que cela aiderait mais pas. J'utilise WatiN version 2.0 beta 1.

Mon code NUnit lo oks comme ce qui suit:

protected Browser Browser { get; set; } 

[TestFixtureSetUp] 
public void SetupPriorToTestsInThisFixture() 
{ 
    Browser = new IE(); 
    Browser.GoTo(Constants.SiteCollectionUrl); 
} 

[TestFixtureTearDown] 
public void TearDownAfterTestsInThisFixture() 
{ 
    if (Browser != null) 
    { 
     Browser.Dispose(); 
    } 
} 

[Test] 
public void WaterThroughThePipes() 
{ 
    Link link = Browser.Link(Find.ByText("Calendar")); 
    bool exists = link.Exists; 
    Assert.That(exists, Is.True, "Could not find 'Calendar' link."); 
} 

Ce que je vois est que parfois (quoique rarement) mon test passe. Parfois l'assertion échoue (exists = false), parfois j'obtiens un timeout en essayant d'ouvrir le navigateur, et parfois j'obtiens une erreur essayant d'accéder à link.Exists.

L'erreur d'accès à link.Exists ressemble:

MyFixture.WaterThroughThePipes: System.Runtime.InteropServices.COMException: L'interface est inconnue. (Exception de HRESULT: 0x800706B5)

Je ne peux pas sembler reproduire l'erreur de délai d'attente, je peux maintenant afin de ne pas prévoir que, au moment (bien que ce qui se passait tout le temps).

J'ai tendance à voir des résultats différents lors de l'exécution de ce mode de débogage par rapport à ne pas s'exécuter en mode débogage.

Pour ce que ça vaut, Firefox 3.0.6 n'a jamais fonctionné pour moi. Je voudrais, mais besoin de IE pour fonctionner indépendamment. Voici l'erreur que je reçois avec Firefox.

MyFixture (TestFixtureSetUp): WatiN.Core.Native.Mozilla.FireFoxException: Impossible de se connecter à jssh serveur, s'il vous plaît assurez-vous que vous avez correctement installé le plugin jssh.xpi ----> System.Net .Sockets.SocketException: Aucune connexion n'a pu être établie car la machine cible l'a refusée 127.0.0.1:9997

Des idées? Je ne veux vraiment pas retourner à Selenium (été là, fait cela), mais je dois le faire.

Answer 1

IE8 fonctionne avec WatiN, et ce depuis la première version publique d'IE8.

Si quelque chose fonctionne dans le débogage mais pas lors de l'exécution, il pointe généralement vers un problème de synchronisation ou de verrouillage de sécurité Server 2008.

Vous devez placer la ligne qui échoue dans un catch try, puis s'il y a une pause d'exception pendant une demi-seconde, puis réessayez.

Vérifiez également que vous avez désactivé tous les verrouillages de sécurité supplémentaires du serveur et que vous utilisez nUnit en tant qu'administrateur pour éviter que le contrôle de compte d'utilisateur ne se produise.

Answer 2

En ce qui concerne l'erreur que vous voyez sur Firefox ... Cela peut être surmonté en installant le FireWatir FF plugin. (Ou au moins cela a fonctionné pour moi sur 3.5.3)

Mais comme déjà mentionné, IE est pris en charge et dans un contexte WatiN, en utilisant FireFox n'est pas une solution magique.

Answer 3

Run Visual Studio en tant qu'administrateur

Answer 4

L'autre alternative pour éviter l'exécution de Visual Studio ou NUnit comme administrateur serait de désactiver l'UAC à un niveau de la machine, ce qui ne devrait pas être un problème de sécurité si vous exécutez avec moins privilèges (que vous devriez être).

Answer 5

J'ai réussi à faire disparaître cette erreur COM - et à faire fonctionner normalement mes tests - en ajustant mes paramètres de sécurité Internet sur «Activer le mode protégé» même pour les sites intranet locaux. Cette seule case à cocher a fait toute la différence. (Et je ne dois pas exécuter Visual Studio en tant qu'administrateur.)

See this blog post pour résoudre ce problème sans exécuter Visual Studio en tant qu'administrateur.

En bref:

Dans Internet Explorer, ouvrez Outils -> Options Internet -> Sécurité -> Intranet local et cochez la case "Activer le mode protégé."

Je suis en cours d'exécution IE 8 et Visual Studio 2010 sous Windows 7.