¿Es NUnit una mala elección para la prueba de selenio?

Question

He leído innumerables respuestas sobre SO mientras busco NUnit + métodos dependientes + orden de ejecución de la prueba. Cada respuesta sugiere que forzar cualquier orden para las pruebas unitarias es extremadamente malo.

Estoy escribiendo pruebas de selenio usando NUnit. ¡¡Así que estoy tratando de escribir pruebas de integración usando el marco de prueba de la Unidad !!!

Para citar un ejemplo de pruebas de integración (y este es solo un ejemplo). Necesito crear una cuenta válida antes de continuar con otras pruebas. Si falla la creación de la cuenta, me gustaría cancelar la ejecución de la prueba completa.

Como no deseo confiar en el orden alfabético de la prueba y con verdadero ánimo de NUnit, decidí crear una cuenta antes de cualquier prueba adicional. A pesar de que no se ve bien para mí por dos razones principales -

1. código innecesario duplicación/ejecución
2. ¿Qué pasa si la creación de cuentas aplicación no funciona, todas mis pruebas aún tratarían de crear y tener en cuenta una y otra vez y fracasando

Me inclino a pensar que NUnit puede no ser el correcto para lidiar con las pruebas de Selenium. Pero si no es Nunit, ¿qué debería usar?

Answer 1

Selenium Core viene con un TestRunner escrito en Javascript y puede ejecutar sus pruebas directamente desde el navegador.

Para más información, véase:

http://www.developerfusion.com/article/84484/light-up-your-development-with-selenium-tests/

Aparte de eso, el uso de Nunit y pruebas escritas en C# son mucho más fáciles de escribir y mantener. ¿Estás usando SetUp y TearDown mientras escribes tus pruebas? De esa forma puede evitar la duplicación de código.

En cuanto al segundo punto, puede tener un indicador que está configurado en el primer error de configuración y se salta la configuración la próxima vez o la instalación misma lo rastrea y falla rápidamente la próxima vez. Y las pruebas no se ejecutan si falla la configuración en Nunit.

Answer 2

Ejecuto Selenium con NUnit todo el tiempo. Solo depende de cómo escribas tus pruebas. Para evitar la duplicación de código, creo una biblioteca de funciones de ayuda que hacen cosas comunes, como iniciar o cerrar sesión en mi sitio, que las otras pruebas usan para llegar a la página que necesitan probar. (Utilizo el término 'biblioteca' en un sentido amplio, en realidad no los divido en su propio proyecto C#)

Tiene razón en que si la función de creación de cuenta se rompe, las otras pruebas fallarán. Pero personalmente, no lo veo como un problema, ya que el punto de las pruebas unitarias es asegurarse de que sus cambios no tengan efectos no deseados en ningún otro lugar de su proyecto. Si la creación de la cuenta se rompió, claramente eso afecta muchas cosas. Lo mismo ocurre si falla mi método de inicio de sesión: si no puede iniciar sesión, no puede acceder a nada en el sitio. Efectivamente, todo el sitio está roto.

Answer 3

Si necesita crear nuevas cuentas en cada prueba, entonces el enfoque que tomaría es que ese código se transfiera a su código de configuración. Si algunas de sus pruebas no requieren inicio de sesión, divídalas en diferentes archivos.

Se deben eliminar todos los bits de duplicidad, el código de prueba debe ser tan limpio y robusto como el código de producción. Dividir los archivos con diferentes pruebas ayuda a mantener la idea de Single Responsibility.

Answer 4

¿También viste a PNunit?

ver uno de los anwers en esta pregunta:

Has anyone found a way to run C# Selenium RC tests in parallel?

todavía no estoy 100% seguro de cómo funcionaría TestNG con rejilla, suponga que tiene un proceso de registro de 3 pasos y se divide esta hasta en 3 pruebas. ¿TestNG con grid te ayudará aquí? Supongo que no, ¿o detectará que la prueba C necesita tener las pruebas A y B en el mismo hilo?

PNunit parece que podría proporcionar una forma de distribuir pruebas dependientes a la misma máquina. Aunque es probable que sea bastante complicado de configurar.

Answer 5

dos enfoques podrían ayudar a que, con el problema que usted describe como una respuesta a AutomatedTester:

Primera, NUnit 2.4.4 define una SuiteAttribute que le permite ejecutar pruebas en el orden que desee. Muy útil, pero tiene una gran restricción: no es compatible con TestCaseAttribute. Eso significa que todas sus pruebas tienen que ser activadas solo por TestAttribute; que es muy molesto si se enfoca en la cobertura de pruebas de límites basadas en valores (por lo tanto, varios casos de prueba basados ​​en datos). Más información en http://www.nunit.org/index.php?p=suite&r=2.5.10

Otro acercamiento es preparar una base de datos de la muestra de la integración adaptada apenas para sus casos de la prueba. Supongamos que tiene un proceso de registro de 15 pasos: cree un registro de alumno y empújelo hasta el paso uno, luego otro alumno y empújelo hasta el paso dos, y así sucesivamente. Guarde su base de datos y restaurela como instalación de dispositivo de prueba. Luego prueba cada paso con un alumno diferente.

En la mayoría de los casos es perfectamente válido realizar pruebas de integración en diferentes registros para cada paso, ya que proporciona la misma cobertura de sentido y código, y sigue la idea de pruebas de integración porque sus registros en el DB son verdaderos registros (creado por la interfaz de usuario con todos los defectos que viene con la interfaz de usuario).

Por supuesto, necesita más tiempo para ejecutar y espacio de almacenamiento debido a las copias de DB que tendrá que almacenar. Si su sistema no puede pagar eso, entonces probablemente quiera ver la primera solución.

También le ofrece la ventaja de poder detectar errores en pasos posteriores incluso si los pasos anteriores son inestables: todas las pruebas se ejecutan en cada campaña de prueba, lo que no ocurre en la solución que solicita.