Watin o selenio? [cerrado]

Voy a comenzar a codificar algunas pruebas automatizadas de nuestra presentación pronto. Parece que todos recomiendan WatiN y Selenium . ¿Qué prefiere para las pruebas automatizadas de formularios web ASP.NET? ¿Cuál de estos productos funciona mejor para usted?

Como nota al margen, noté que WatiN 2.0 ha estado en CTP desde marzo de 2008, ¿es algo de lo que preocuparse?

Solo quiero decir que actualmente estoy trabajando duro en una versión beta de WatiN 2.0 en algún lugar del primer trimestre de 2009. Será una actualización importante de las versiones actuales de CTP 2.0 y básicamente le dará la misma funcionalidad para automatizar FireFox e IE que La versión 1.3.0 ofrece la automatización de IE.

Así que no hay preocupaciones allí.

Espero que esto ayude a elegir Jeroen van Menen Líder de desarrollo WatiN

Si está buscando hacer una inversión seria a largo plazo en un marco que continuará siendo mejorado y respaldado por la comunidad, Selenium es probablemente su mejor opción. Por ejemplo, acabo de encontrar esta información en el blog de Matt Raible:

A partir del viernes, Google tiene más de 50 equipos que realizan más de 51,000 pruebas por día en Selenium Farm interno. Selenium RC y las máquinas agrícolas manejan correctamente el 96% de estas pruebas. El otro 4% se debe en parte a errores de RC, en parte a errores de prueba, pero aislar la causa puede ser difícil. Selenium ha sido adoptado como la tecnología principal para las pruebas funcionales de aplicaciones web en Google. Esa es la buena noticia.

También asistí a una de las reuniones de Selenium recientemente y me enteré de que Google está poniendo recursos importantes para mejorar Selenium e integrarlo con WebDriver, que es una herramienta de prueba automatizada desarrollada por Simon Stewart. Una de las principales ventajas de WebDriver es que controla el navegador en sí en lugar de ejecutarse dentro del navegador como una aplicación Javascript, lo que significa que los principales obstáculos como el problema del "mismo origen" ya no serán un problema.

Hemos probado ambos y decidimos usar WaTiN. Como otros han señalado, Selenium tiene algunas características agradables que no se encuentran en WaTiN, pero tuvimos problemas para que Selenium funcionara y una vez que lo hicimos fue definitivamente más lento al ejecutar pruebas que WaTiN. Si no recuerdo mal, los problemas de configuración con los que nos encontramos surgieron del hecho de que Selenium tenía una aplicación separada para controlar el navegador real donde WaTiN hizo todo lo que estaba en proceso.

Los he estado probando y aquí están mis pensamientos iniciales ...

Watin

El bueno

• Ejecución rápida
• Las herramientas de creación de guiones son proyectos independientes; Hay 2 que conozco: cera (basada en Excel, alojada en CodePlex) y WatiN Test Record (alojado en SourceForge). Ninguno de los dos es tan robusto como Selenium IDE.
• Muy buen soporte de IE. Puede adjuntar y desconectar a / de instancias en ejecución. Puede acceder a identificadores de ventanas nativos, etc. (Consulte el ejemplo del script a continuación).
• NuGet empaquetado, fácil de ejecutar en .NET, entornos de estilo Visual Studio y mantenerse actualizado.

El malo

• Buscar en Google WatiN (watin xyz) a menudo hace que Google recomiende "watir xyz". No hay mucha documentación por ahí.
• Lo poco que hay (documentación) es confuso; por ejemplo: a primera vista parecería que no hay soporte nativo para los selectores CSS. Especialmente porque hay bibliotecas de extensiones como 'WatiNCssSelectorExtensions' y muchos artículos de blog sobre técnicas alternativas (como inyectar jQuery / sizzle en la página). En Stack Overflow, encontré un comentario de Jeroen van Menen que sugiere que hay soporte nativo. Al menos el desarrollador principal pasa tiempo en Stack Overflow :)
• No es compatible con XPath nativo.
• Sin ejecución remota lista para usar / ejecución basada en cuadrícula.

Ejemplo de secuencia de comandos (C #). No puedes hacer esto con Selenium (no es que yo sepa, al menos):

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

Selenio

• Más lento que WatiN (especialmente porque se debe crear un nuevo proceso).
• Selectores CSS incorporados / soporte XPath.
• Selenium IDE es bueno (no puedo decir genial, ¡pero es el mejor en su clase!).
• Se siente más Java-ish que .NET-ish ... pero realmente, es un lenguaje de programación agnóstico; Todos los comandos se envían a un 'Driver' fuera de proceso. El controlador es realmente un proceso 'host' para la instancia del navegador. Toda la comunicación debe ser serializada dentro / fuera de los límites del proceso, lo que podría explicar los problemas de velocidad relacionados con WatiN.
• Procesos desacoplados: "Controlador" y "Control" significan más robustez, más complejidad, etc., pero también es más fácil crear cuadrículas / entornos de prueba distribuidos. Realmente me hubiera gustado que el mecanismo de "distribución" (es decir, la comunicación entre Controlador y Control) fuera a través de WebSphere u otro gestor de colas de mensajes existente y robusto.
• Admite Chrome y otros navegadores fuera de la caja.

A pesar de todo, fui con Watin al final; Principalmente tengo la intención de escribir pequeñas aplicaciones de raspado de pantalla y quiero usar LINQPad para el desarrollo. Adjuntar a una instancia remota de IE (una que no generé yo mismo) es una gran ventaja. Puedo jugar en una instancia existente ... luego ejecutar un poco de script ... luego tocar de nuevo, etc. Esto es más difícil de hacer con Selenium, aunque supongo que las "pausas" podrían incrustarse en el script durante el cual podría tocar el violín directamente con el navegador.

La mayor diferencia es que Selenium tiene soporte para diferentes navegadores (no solo IE o FF, consulte http://seleniumhq.org/about/platforms.html#browsers .

Además, Selenium tiene un servidor de control remoto ( http://seleniumhq.org/projects/remote-control/ ), lo que significa que no necesita ejecutar el navegador en la misma máquina en la que se ejecuta el código de prueba. Por lo tanto, puede probar su aplicación web. en diferentes plataformas del sistema operativo.

En general, recomendaría usar Selenium. Utilicé WatiN hace unos años, pero no estaba satisfecho con su estabilidad (probablemente ya haya mejorado). La mayor ventaja de Selenium para mí es el hecho de que puede probar la aplicación web. en diferentes navegadores.

Ninguno. Usa coipo. Envuelve el selenio. Mucho más duradero. https://github.com/featurist/coypu

Actualiza a Ye Oliver, tienes razón. Ok, ¿por qué es mejor? Personalmente, he encontrado que el controlador Selenium para IE en particular es muy frágil: hay una serie de excepciones de controladores 'estándar' que he encontrado una vez más al conducir Selenium for Unit Tests en sitios web pesados ​​de ajax.

¿Mencioné que quiero escribir mis scripts en c # como proyecto de prueba? Sí Pruebas de aceptación dentro de una implementación de compilación continua.

Bueno Coypu se ocupa de lo anterior. Es una envoltura para Selenium que permite accesorios de prueba como,

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

... que activará un navegador (marca configurable de) y ejecutará el script. Funciona muy bien con regiones de ámbito y es MUY extensible.

Hay más ejemplos en GitHub y, como menciona Olvier a continuación, el video de Adrian es excelente. Creo que es la mejor manera de conducir pruebas basadas en navegador en el mundo .Net y trata de seguir su mismo nombre Rubycapybara

He usado ambos, ambos parecen funcionar bien. Mi guiño es para Selenium ya que parecía tener un mejor soporte de Ajax. Sin embargo, creo que WaTiN ha madurado desde la última vez que lo usé, por lo que debería tener lo mismo.

Lo más importante sería en qué entorno de desarrollo te gustaría estar. Selenium y Watin tienen grabadoras, pero Selenium está en el navegador y watin está en el estudio visual. + y -'s a ambos.

Hasta ahora, somos una tienda de Microsoft pura para ofrecer soluciones para la empresa y fuimos con WatiN. Esto puede cambiar en el futuro.

Como una fuente más reciente:

Microsoft imprimió en MSDN Magazine 12/2010 un BDD-Primer con la combinación de SpecFlow con WatiN (genial desarrollo basado en el comportamiento de BDD). Su autor Brandon Satrom (msft Developer Evangelist) también publicó en diciembre de 2010 un video por Internet que enseña en detalle 1: 1 sus hallazgos anteriores.

Existe un documento técnico de 04/2011 sobre el soporte de ATDD / BDD con SpecLog, SpecFlow y Team Foundation Server (Desarrollo impulsado por prueba de aceptación / Desarrollo dirigido por comportamiento) de Christian Hassa , cuyo equipo creó SpecFlow.

Yo uso Watin, pero no he usado selenio. Puedo decir que me puse en marcha rápidamente en Watin y he tenido pocos o ningún problema. No puedo pensar en nada que haya querido hacer que no pudiera resolver con eso. HTH

Generalmente uso Selenium, principalmente porque me gusta el complemento Selenium IDE para FireFox para registrar puntos de partida para mis pruebas.

Recomiendo WebAii ya que eso es con lo que he tenido éxito y cuando lo uso, mis quejas son pocas. Nunca probé Selenium y no recuerdo haber usado WaTiN mucho, al menos no hasta el punto en que pudiera lograr que funcionara con éxito. No conozco ningún marco que trate con diálogos de Windows con gracia, aunque WebAii tiene una interfaz para implementar sus propios controladores de diálogo.

Pensé en usar ambos. Usé la grabadora de Selenium para construir algunas pruebas en FF. Traté de hacer lo mismo en Watin y descubrí que Watin Recorder (2.0.9.1228) no tiene ningún valor para nuestros sitios . Parecía estar renderizando el sitio en IE6, haciendo que nuestro sitio fuera efectivamente inutilizable para la grabación. No apoyamos IE6. No pude encontrar ninguna manera de cambiar el navegador que está usando. Solo encontré una grabadora Watin por ahí. Si hay más de uno, o uno que esté actualizado, por favor comente.

El Selenium Recorder IDE para Firefox es fácil de usar y transfiere las pruebas a C #. No es genial en esto. No pude conseguir que las suites de prueba funcionaran, a pesar de leer una publicación de blog o dos que tenían soluciones alternativas. Entonces hay un poco de manipulación del código generado. Aún así, funciona al 90% y eso es mejor que la alternativa.

Por mi dinero / tiempo, Selenium es superior solo por la facilidad de crear nuevas pruebas . IE no tiene buenas barras de herramientas para desarrolladores que sean tan buenas como Firebug , por lo que estoy haciendo mi desarrollo en Firefox para empezar, por lo que tener una buena grabadora que funcione en Firefox es una gran ventaja.

Mi conclusión aquí fue muy parecida a la cita de democracia de Churchill: el selenio es la peor forma de prueba automatizada de IU. Excepto por todos los demás.

A riesgo de salir por una tangente, recomendaría Axe / WatiN. Ax permite que las pruebas sean escritas en Excel por probadores 'manuales' sin conocimiento del 'lenguaje' de prueba subyacente. Se necesita un 'Técnico' para escribir las acciones a medida (IE. Hoy tuve que hacer una búsqueda de tabla y referencias cruzadas un poco complejas) pero una vez escritas las acciones pueden ser utilizadas en pruebas por los evaluadores no técnicos.

¡También escuché que el proyecto UK Government Gateway (que creo que tiene 6K + pruebas automatizadas) recientemente transfirió todas sus pruebas de Axe / Winrunner a Axe / Watin en una semana !! Y muchas de las pruebas son bastante complejas: sé que trabajé en ellas hace unos años ...

Estoy viendo Selenium en este momento, ya que un Cliente potencial lo usa. Pero sí sugiero un pequeño vistazo a Axe como una capa sobre la herramienta 'caballo de trabajo'.

Si tiene que acceder a iframes, cuadros de diálogo modales e iframes de dominio cruzado, WatiN es un camino a seguir. Selenium no pudo manejar los iframes que estaba lanzando excepciones de tiempo de espera de comando. WatiN podría hacer muchas más cosas, especialmente si el sitio web utiliza cosas específicas de IE como ShowModalDialog, etc. WatiN las maneja muy bien. Incluso podría hacer acceso de iframe de dominio cruzado.

Tendrá que hacer ambas cosas si necesita hacer pruebas de IE y FF, pero solo funcionarán tan bien para las pruebas de presentación. No pueden detectar si un elemento está ligeramente apagado, solo que los elementos están presentes. No sé de nada que pueda reemplazar el ojo humano para las pruebas de UI / presentación, aunque podría hacer algunas cosas para ayudarlo (tome capturas de pantalla de las páginas en cada paso para que los usuarios las revisen).