Watin o selenio? [cerrado]

StackOverflow https://stackoverflow.com/questions/417380

Pregunta

Pronto comenzaré a codificar algunas pruebas automatizadas de nuestra presentación. Parece que todos recomiendan WatiN y Selenio . ¿Qué prefiere para las pruebas automatizadas de los 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?

¿Fue útil?

Solución

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 a las versiones actuales de CTP 2.0 y básicamente le dará la misma funcionalidad para automatizar FireFox e IE como ofertas de la versión 1.3.0 para automatizar IE.

Entonces no hay preocupaciones allí.

Espero que esto ayude a elegir Jeroen van Menen Desarrollador líder WatiN

Otros consejos

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.   ejecutando más de 51K pruebas por día en   Granja de selenio interna. 96% de estos   las pruebas son manejadas por Selenium RC y   La Granja maquina correctamente. El otro   El 4% se debe en parte a errores de RC, en parte   para probar errores, pero aislando el   La causa puede ser difícil. El selenio tiene   sido adoptado como la tecnología primaria   para pruebas funcionales de web   aplicaciones dentro de Google. Eso es   buenas noticias.

También asistí a una de las reuniones de Selenium recientemente y descubrí 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í mismo en lugar de ejecutarse dentro del navegador como una aplicación Javascript, lo que significa que los principales obstáculos como el "mismo origen" problema ya no será 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

Lo bueno

  • Ejecución rápida.
  • Las herramientas de creación de scripts son proyectos independientes; hay 2 que conozco: Wax (basado en Excel, alojado en CodePlex) y WatiN Test Record (alojado en SourceForge). Ninguno de los dos es tan robusto como Selenium IDE.
  • Muy buen soporte para IE. Puede adjuntar y desconectar a / de instancias en ejecución. Puede acceder a los 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.

Lo malo

  • Buscar en Google WatiN (watin xyz) a menudo hace que Google recomiende "watir xyz" en lugar. 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 script (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;
    }
}

Selenium

  • Más lento que WatiN (especialmente porque se debe crear un nuevo proceso).
  • Selectores CSS integrados / soporte XPath.
  • Selenium IDE es bueno (no puedo decir genial, ¡pero es el mejor de 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 a través de los límites del proceso, lo que podría explicar los problemas de velocidad relacionados con WatiN.
  • Procesos desacoplados - "Controlador" y "Control" significa más robustez, más complejidad, etc., pero también es más fácil crear cuadrículas / entornos de prueba distribuidos. Me hubiera gustado mucho si la " distribución " El mecanismo (es decir, la comunicación entre Driver & amp; Control) se realizó 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 de IE remota (una que no generé yo mismo) es una gran ventaja. Puedo jugar en una instancia existente ... luego ejecutar un poco de secuencia de comandos ... luego tocar el violín de nuevo, etc. Esto es más difícil de hacer con Selenium, aunque supongo que "pausa". podría incrustarse en el script durante el cual podría tocar el teclado 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 de los dos. Usa coipo. Envuelve el selenio. Mucho más duradero. https://github.com/featurist/coypu

Actualizar 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 para pruebas unitarias 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 nombre de Ruby capybara

He usado ambos, ambos parecen funcionar bien. Mi guiño es para Selenium ya que parecía tener un mejor soporte de Ajax. 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-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 fuente más reciente:

Microsoft imprimió en MSDN Magazine 12/2010 un BDD-Primer con la combinación de SpecFlow con WatiN (genial desarrollo de BDD-Behavior Driven Development). Su autor Brandon Satrom (msft Developer Evangelist) también publicó en diciembre de 2010 un Video Webcast enseñando en detalle 1: 1 sus hallazgos anteriores.

Hay un Whitepaper del 04/2011 en Soporte 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 Selenium. 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 eran 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 el 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á utilizando. 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. Axe 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 Ax 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 arrojaba 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 entre dominios.

Tendrá que hacer ambas cosas si necesita hacer pruebas de IE y FF, pero solo funcionarán muy 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).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top