unit-testing - unit testing laravel
¿Cuál es el punto del selenio? (15)
Ok, tal vez me estoy perdiendo algo, pero realmente no veo el sentido de Selenium. ¿Cuál es el punto de abrir el navegador usando el código, hacer clic en los botones usando el código y verificar el texto usando el código? Leí el sitio web y veo que, en teoría, sería bueno probar las aplicaciones web automáticamente, pero al final no solo toma mucho más tiempo escribir todo este código en lugar de simplemente hacer clic y verificar visualmente las cosas. ?
No lo entiendo ...
¿Por qué necesitas Selenio? Porque los probadores son seres humanos. Van a casa todos los días, no siempre pueden trabajar los fines de semana, tomarse la enfermedad, tomar vacaciones, irse de vacaciones de vez en cuando, aburrirse haciendo tareas repetitivas y no siempre pueden confiar en que estén presentes cuando los necesite.
No digo que deba deshacerse de los probadores, pero una herramienta de prueba de UI automatizada complementa los probadores del sistema.
El punto es el mismo que para cualquier tipo de prueba automatizada: escribir el código puede tomar más tiempo que "simplemente hacer clic y verificar visualmente las cosas", tal vez 10 o incluso 50 veces más.
Pero cualquier aplicación no trivial tendrá que ser probada más de 50 veces con el tiempo, y las pruebas manuales son una tarea molesta que probablemente se omita o se haga bajo presión, lo que provoca que no se descubran errores hasta fechas importantes (o posteriores), lo que resulta en sesiones estresantes de codificación durante toda la noche o incluso pérdida monetaria directa debido a las penalidades del contrato.
El punto es la capacidad de automatizar lo que era antes de una prueba manual y que consume mucho tiempo. Sí, toma tiempo escribir las pruebas, pero una vez escritas, se pueden ejecutar con la frecuencia que el equipo desee. Cada vez que se ejecutan, están verificando que el comportamiento de la aplicación web sea consistente. El selenio no es un producto perfecto, pero es muy bueno para automatizar la interacción realista del usuario con un navegador.
En un trabajo anterior solíamos probar nuestra aplicación web. Si la aplicación web cambia de aspecto, no es necesario volver a escribir las pruebas. Todas las pruebas de tipo de grabación y repetición deberían volver a realizarse.
Esto es algo común que se dice acerca de las pruebas unitarias en general. "¿Necesito escribir el doble de código para las pruebas?" Los mismos principios se aplican aquí. El beneficio es la capacidad de cambiar tu código y saber que no estás rompiendo nada.
Imagine que tiene 50 páginas, todas con 10 enlaces cada una, y algunas con formularios de varias etapas que requieren que revise los formularios, agregue aproximadamente 100 conjuntos diferentes de información para verificar que funcionen correctamente con todos los números de tarjetas de crédito, todas las direcciones en todos los países, etc.
Eso es virtualmente imposible de probar manualmente. Se vuelve tan propenso a errores humanos que no se puede garantizar que las pruebas se realizaron correctamente, sin importar lo que las pruebas probaron sobre lo que se está probando.
Además, si sigue un modelo de desarrollo moderno, con muchos desarrolladores trabajando todos en el mismo sitio de manera desconectada y distribuida (algunos trabajando en el sitio desde su computadora portátil mientras están en un avión, por ejemplo), entonces los probadores humanos no lo harán. incluso podrá acceder a él, y mucho menos tendrá la paciencia de volver a probar cada vez que un único desarrollador intente algo nuevo.
En cualquier tamaño decente del sitio web, las pruebas TIENEN que ser automatizadas.
Le permite escribir pruebas funcionales en su marco de prueba de "unidad" (el problema es nombrar el último).
Cuando prueba su aplicación a través del navegador, generalmente está probando el sistema completamente integrado. Considere que ya debe probar sus cambios antes de cometerlos (pruebas de humo), no desea probarlos manualmente una y otra vez.
Algo realmente agradable es que puede automatizar sus pruebas de humo y QA puede aumentarlas. Muy efectivo, ya que reduce la duplicación de esfuerzos y acerca a todo el equipo.
Ps como cualquier práctica que está utilizando la primera vez que tiene una curva de aprendizaje, por lo que generalmente lleva más tiempo las primeras veces. También sugiero que mire el patrón Página de objeto , ayuda a mantener las pruebas limpias.
Actualización 1: tenga en cuenta que las pruebas también ejecutarán javascript en las páginas, lo que ayuda a probar páginas altamente dinámicas. También tenga en cuenta que puede ejecutarlo con diferentes navegadores, por lo que puede verificar problemas entre navegadores (al menos desde el punto de vista funcional, ya que aún necesita verificar el visual).
También tenga en cuenta que a medida que la cantidad de páginas cubiertas por las pruebas se acumula, puede crear pruebas con ciclos completos de interacciones rápidamente. Usando el patrón del Objeto de página se ven así:
LastPage aPage = somePage
.SomeAction()
.AnotherActionWithParams("somevalue")
//... other actions
.AnotherOneThatKeepsYouOnthePage();
// add some asserts using methods that give you info
// on LastPage (or that check the info is there).
// you can of course break the statements to add additional
// asserts on the multi-steps story.
Es importante entender que vas gradual sobre esto. Si se trata de un sistema ya construido, agregue pruebas para las características / cambios en los que está trabajando. Agregar más y más cobertura en el camino. El manual en cambio, generalmente oculta lo que te perdiste para probar, por lo que si realizaste un cambio que afecta a cada página y verificaras un subconjunto (como el tiempo no permite), sabrás cuáles realmente has probado y de qué QA puede funcionar allí (con suerte añadiendo incluso más pruebas).
Lo uso para probar formularios de varias páginas, ya que esto elimina la carga de tipear lo mismo una y otra vez. Y tener la capacidad de verificar si ciertos elementos están presentes es genial. Una vez más, usando el formulario como ejemplo, su prueba final de selenio podría verificar si aparece algo así como "Gracias Sr. Rogers por pedir ..." al final del proceso de pedido.
Para aplicaciones con interfaces web enriquecidas (como muchos proyectos GWT), Selenium / Windmill / WebDriver / etc es la forma de crear pruebas de aceptación. En el caso de GWT / GXT, el código de la interfaz de usuario final está en JavaScript, por lo que la creación de pruebas de aceptación con los casos de prueba de juntura normales está básicamente fuera de toda duda. Con Selenium puede crear escenarios de prueba que coincidan con las acciones reales del usuario y los resultados esperados.
Basado en mi experiencia con Selenium, puede revelar errores en la lógica de la aplicación y la interfaz de usuario (en caso de que sus casos de prueba estén bien escritos). Tratar con los front ends de AJAX requiere un esfuerzo adicional, pero aún es posible.
Porque puedes repetir la MISMA prueba una y otra vez.
Selenium (junto con herramientas similares, como Watir) le permite ejecutar pruebas en contra de la interfaz de usuario de su aplicación web de manera que las computadoras son buenas: miles de veces durante la noche o segundos después de cada registro en la fuente. (Tenga en cuenta que hay muchas otras pruebas de UI en las que los humanos son mucho mejores, como darse cuenta de que algo extraño que no está directamente relacionado con la prueba está fuera de lugar).
Existen otras formas de involucrar toda la pila de su aplicación mirando el HTML generado en lugar de abrir un navegador para representarlo, como Webrat y Mechanize . La mayoría de estos no tienen una manera de interactuar con las IU pesadas de JavaScript; El selenio lo tiene algo cubierto aquí.
Si no le gusta el enfoque de Selenium, puede probar HtmlUnit , lo encuentro más útil y fácil de integrar en las pruebas de unidades existentes.
Si su aplicación tiene incluso más de 50 páginas y necesita realizar compilaciones frecuentes y probarla contra un número X de buscadores importantes, tiene mucho sentido.
Y si guarda esas pruebas como clases JUnit, puede volver a ejecutarlas en su tiempo libre, como parte de su versión automatizada o en la prueba de carga de un hombre pobre utilizando JMeter.
Selenium registrará y volverá a ejecutar todos los clics y tipeos manuales que haga para probar su aplicación web. Una y otra vez.
Con el tiempo, mis estudios me han demostrado que tiendo a hacer menos pruebas y empiezo a saltear algunas, u olvidarme de ellas.
En su lugar, el selenio tomará cada prueba, la ejecutará, si no devuelve lo que espera, puede hacerle saber.
Hay un costo de tiempo inicial para registrar todas estas pruebas. Lo recomendaría como pruebas unitarias: si no lo tiene ya, empiece a usarlo con las partes más complejas, sensibles o más actualizadas de su código.