internet explorer 8 - navegador - ¿Cómo lograr que WatiN funcione en Windows Server 2008 con IE8?

internet explorer 9 windows server 2003

Question

Mi problema es que no puedo obtener una prueba de WatiN simple para funcionar de manera confiable en mi máquina de desarrollo que ejecuta Windows Server 2008 e IE8.

He visto un par de buenas publicaciones sobre esto, pero todavía estoy teniendo problemas. Aquí están los mensajes:

• Artículo de prueba de MSDN
• Desbordamiento de pila - Segundo método de WatiN falla

Los pasos en el primer artículo parecieron ayudar (comente ":: 1" en mi archivo de hosts, coloque mi (s) sitio (s) en sitios de confianza y asegurándose de que mi app.config tenga "STA" y esté configurado para "copiar si más nuevos ", pero no ayudaron de manera confiable. Probé el código del segundo ejemplo con la esperanza de que ayudara, pero no fue así. Estoy usando WatiN versión 2.0 beta 1.

Mi código NUnit se parece a lo siguiente:

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.");
}

Lo que estoy viendo es que a veces (aunque rara vez) mi examen pasa. A veces, la afirmación falla (existe = falso), a veces se produce un tiempo de espera al intentar abrir el navegador y, a veces, se produce un error al intentar acceder al enlace.Existe.

El error al acceder a link.Exists se ve así:

MyFixture.WaterThroughThePipes: System.Runtime.InteropServices.COMException: la interfaz es desconocida. (Excepción de HRESULT: 0x800706B5)

Parece que no puedo reproducir el error de tiempo de espera ahora, así que no puedo proporcionarlo en este momento (aunque esto solía ocurrir todo el tiempo).

Tiendo a ver resultados diferentes cuando ejecuto esto en modo de depuración y no en modo de depuración.

Por lo que vale, Firefox 3.0.6 nunca me ha funcionado. Me gustaría, pero necesito IE para trabajar independientemente. Aquí está el error que me sale con Firefox.

MyFixture (TestFixtureSetUp): WatiN.Core.Native.Mozilla.FireFoxException: No se puede conectar al servidor jssh, asegúrese de haber instalado correctamente el complemento jssh.xpi ----> System.Net.Sockets.SocketException: No se puede conectar se realizará porque la máquina de destino lo rechazó activamente 127.0.0.1:9997

¿Algunas ideas? Realmente no quiero volver a Selenium (he estado allí, hecho eso), pero es posible que tenga que hacerlo.

Answer 1

Con respecto al error que está viendo en Firefox ... Eso puede superarse instalando el complemento FireWatir FF . (O al menos eso me funcionó en 3.5.3)

Pero como ya se mencionó, IE es compatible y, en un contexto de WatiN, el uso de FireFox no es una solución mágica.

Answer 2

Ejecutar Visual Studio como administrador

Answer 3

IE8 definitivamente trabaja con WatiN, y lo ha hecho desde la primera versión pública de IE8.

Si algo está funcionando en la depuración, pero no cuando se ejecuta, generalmente apunta a un problema de sincronización o de seguridad del Servidor 2008.

Debe colocar la línea que está fallando en un retén de prueba, luego, si hay una pausa de excepción, digamos medio segundo y vuelva a intentarlo.

También asegúrese de haber desactivado todos los bloqueos de seguridad adicionales del servidor, y está ejecutando nUnit como administrador para evitar que UAC se interponga en el camino.

Answer 4

La otra alternativa para evitar la ejecución de Visual Studio o NUnit como administrador sería deshabilitar el UAC a nivel de máquina, lo que no debería ser un problema de seguridad si está ejecutando con los privilegios mínimos (que debería ser).

Answer 5

Pude hacer desaparecer este error de COM (y hacer que mis pruebas se ejecuten normalmente) ajustando la configuración de Seguridad de Internet a "Habilitar el modo protegido" incluso para sitios de Intranet local. Esta única casilla de verificación hizo toda la diferencia. (Y no tengo que ejecutar Visual Studio como administrador).

Consulte esta publicación del blog para solucionar este problema sin ejecutar Visual Studio como administrador.

Brevemente:

En Internet Explorer, abra Herramientas -> Opciones de Internet -> Seguridad -> Intranet local y marque la casilla "Habilitar el modo protegido".

Estoy ejecutando IE 8 y Visual Studio 2010 en Windows 7.