Pruebas frontend: ¿qué y cómo probar y qué herramienta usar?

Question

He estado escribiendo pruebas para mi código Ruby por un tiempo, pero como desarrollador de frontend obviamente estoy interesado en incluir esto en el código que escribo para mi código de interfaz. Hay un buen número de opciones diferentes que he estado jugando con:

• CasperJS
• Capybara & Rspec
• Jasmine
• pepino o simplemente Rspec

¿Cuáles son las personas que usan para la prueba? Y más allá de eso, ¿qué prueba la gente? ¿Solo JavaScript? ¿Campo de golf? ¿Formas? ¿Contenido codificado?

Cualquier pensamiento sería muy apreciado.

Answer 1

Hay muchas opciones y herramientas para eso. Pero su elección depende de si tiene una interfaz de usuario web o es una aplicación de escritorio.

Supongamos por las herramientas que ha mencionado que es la IU web. Sugeriría Selenium (también conocido como WebDriver): http://seleniumhq.org/docs/

Hay una variedad de idiomas compatibles (Ruby está en la lista). Se puede ejecutar contra una variedad de navegadores, y es bastante fácil de usar con muchos tutoriales y consejos disponibles. Ah, y es gratis, por supuesto :)

Answer 2

Tuve las mismas preguntas hace unos meses y, después de hablar con muchos desarrolladores y hacer una gran cantidad de investigación, esto es lo que descubrí. Debe probar su JavaScript por unidad, escribir un pequeño conjunto de pruebas de integración de UI y evitar las herramientas de prueba de grabación y reproducción. Déjame explicarte con más detalle.

Primero, considere el test pyramid. Esta es una analogía interesante creada por Mike Cohn que lo ayudará a decidir qué tipo de prueba debe hacer. En la parte inferior de la pirámide están las pruebas unitarias, que son sólidas y proporcionan una respuesta rápida. Estos deberían ser la base de su estrategia de prueba y ocupar así la mayor parte de la pirámide. En la parte superior, tienes las pruebas de UI. Esas son las pruebas que interactúan directamente con su UI, como Selenium, por ejemplo. Aunque estas pruebas pueden ayudarlo a encontrar errores, son más costosas y proporcionan una retroalimentación muy lenta. Además, según la herramienta que utilice, se vuelven muy frágiles y terminará gastando más tiempo en realizar estas pruebas que escribiendo el código de producción real. La capa de servicio, en el medio, incluye pruebas de integración que no requieren una IU. En Rails, por ejemplo, probarías tu interfaz REST directamente en lugar de interactuar con los elementos DOM.

Ahora, volviendo a su pregunta. Descubrí que podía reducir mucho el número de errores en mi proyecto, que es una aplicación web escrita en Spring Roo (Java) con toneladas de JavaScript, simplemente escribiendo suficientes pruebas unitarias para JS. En mi aplicación, hay mucha lógica escrita en JS y ese es el tipo de cosas que estoy probando aquí. No me preocupa cómo se verá realmente la página o si las animaciones se reproducirán como deberían. Pruebo si los módulos que escribo en JS ejecutarán la lógica esperada, si las clases de elementos están asignadas correctamente y si las condiciones de error se manejan bien. Para estas pruebas, he estado usando Jasmine. Esta es una gran herramienta. Es muy fácil de aprender y tiene buenas capacidades de burla, que se llaman espías. Jasmine-jQuery agrega más funcionalidad excelente si está utilizando jQuery. En particular, le permite especificar accesorios, que son fragmentos del código HTML, por lo que no tiene que burlarse manualmente del DOM. He integrado esta herramienta con maven y estas pruebas son parte de mi estrategia de CI.

Debe tener cuidado con las pruebas de IU, especialmente si confía en las herramientas de grabación/reproducción como el Selenio. Debido a que la IU cambia con frecuencia, estas pruebas se siguen interrumpiendo y usted pasará mucho tiempo averiguando si las pruebas realmente fallaron o si están desactualizadas. Además, no agregan tanto valor como las pruebas unitarias. Debido a que necesitan un entorno integrado para ejecutar, lo que más le gusta es ejecutarlos solo después de que termine de desarrollar, cuando el costo de arreglar las cosas es mayor.

Para pruebas de humo/regresión, sin embargo, las pruebas de IU son muy útiles. Si necesita automatizar estos, debe tener cuidado con algunos peligros. Escriba sus pruebas, no las registre. Las pruebas grabadas generalmente se basan en xpaths generados automáticamente que se rompen por cada pequeño cambio que haga en su código. Creo que Cucumber es un buen marco para escribir estas pruebas y puede usarlo junto con WebDriver para automatizar la interacción del navegador. Código pensando en las pruebas. En las pruebas de UI, tendrá que hacer que los elementos sean más fáciles de encontrar para que no tenga que confiar en los xpaths complejos. Agregar los elementos de clase e id donde normalmente no lo harás será frecuente. No escriba pruebas para cada caso de esquina pequeña. Estas pruebas son caras de escribir y tardan demasiado en ejecutarse. Debe centrarse en los casos que exploran la mayor parte de su funcionalidad. Si escribe demasiadas pruebas en este nivel, probablemente probará la misma funcionalidad que ha probado previamente en las pruebas de su unidad (suponiendo que las haya escrito).

En mi proyecto actual, estoy usando Spock y Geb para escribir las pruebas de UI. Encuentro estas herramientas increíbles. Están escritos en Groovy, que se adapta mejor a mi proyecto Java.

Answer 3

Aunque esta publicación recibe muchos "Me gusta", publicaría mi respuesta a mi pregunta, ya que ahora escribo muchas pruebas y cómo la prueba de la interfaz se ha movido mucho ahora.

Así que en términos de pruebas FE Pasé mucho tiempo utilizando karma con Jasmine, aunque el karma va a funcionar muy bien con otros conjuntos de pruebas como moka & qunit. Si bien estos son geniales y el karma le permite interactuar directamente con los navegadores para ejecutar sus pruebas. La desventaja es que a medida que su suite de pruebas crece, puede volverse bastante lenta.

Así que recientemente me he mudado a Jest, que es mucho más rápido y si su aplicación de escritura de reacción, utilizando enzyme con prueba de disparo instantáneo le dan una muy buena cobertura. Hablando de cobertura Jest tiene la cobertura de Estambul incorporada y configurada, y la burla es realmente fácil de usar. La desventaja es que no se prueba en el navegador y utilizando algo llamado jsdom que es rápido, pero tiene algunas molestias. Personalmente, no me parece una gran oferta, especialmente cuando compilo mi código a través de webpack/babel, lo que significa que los errores cruzados son bastante pocos y distantes, por lo que generalmente no es un problema si prueba manualmente de todos modos (y debería hacerlo)

En términos de trabajar dentro de la pila de rieles, esto es mucho más fácil ahora que la gema de webpacker está ahora disponible y el uso de npm y nodo generalmente es mucho más raro. Recomendaría usar nvm para administrar sus versiones de nodo

Si bien esto no se está probando estrictamente, también recomendaría usar pelusa ya que esto también detecta muchos problemas en su código. Para JS utilizo eslint con prettier y SCSS/css utilizo stylelint

En términos sobre lo que debe probar, creo que Carlos habla de la pirámide de la prueba sigue siendo relevante, después de todo, la teoría no cambia, sólo las herramientas . También me gustaría ser práctico sobre las pruebas, siempre lo haría, pero a qué nivel y cobertura dependerá el proyecto. Es importante administrar su tiempo y pasar horas/días probando un proyecto de ciclo de vida corto.Proyectos más grandes/a más largo plazo Los beneficios de un conjunto de pruebas más grande son obviamente mayores.

De todos modos espero que ayude a las personas que ven la pregunta.