testing - serp - test seo tags

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 bastantes opciones diferentes con las que he estado jugando:

• CasperJS
• Capybara y Rspec
• Jasmine
• Pepino o simplemente Rspec

¿Qué utilizan las personas para las pruebas? 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

Aunque creo que esta publicación recibe muchos "me gusta", publicaría mi respuesta a mi pregunta, ya que ahora escribo muchas pruebas y la forma en que pruebas la interfaz se ha movido mucho ahora.

Entonces, en términos de pruebas FE, pasé mucho tiempo usando karma con Jasmine , aunque el karma funcionará muy bien con otras suites de prueba como mocha y 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.

Recientemente me he mudado a Jest que es mucho más rápido y si su aplicación de escritura es reactiva, el uso de enzyme con pruebas instantáneas brinda una cobertura realmente buena. 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 prueba en el navegador y usa 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, es mucho más fácil ahora que la gema de webpacker ya está disponible y el uso de npm y nodo generalmente es mucho más raro. Recomendaría usar nvm para administrar las versiones de tus nodos

Si bien esto no es una prueba estricta, también recomendaría utilizar pelusas ya que esto también incluye muchos problemas en su código. Para JS uso eslint con prettier y scss / css uso stylelint

En términos de qué probar, creo que a medida que Carlos habla de que la pirámide de prueba sigue siendo relevante, después de todo, la teoría no cambia, solo 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 eso ayude a las personas que miran la pregunta.

Answer 2

Hace algunos meses tuve las mismas preguntas y, después de hablar con muchos desarrolladores y hacer muchas investigaciones, descubrí esto. 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 la pirámide de prueba . 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, de vuelta a tu 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 UI, especialmente si confía en herramientas de grabación / reproducción como Selenium. 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 las pruebas de humo / regresión, sin embargo, las pruebas de UI son muy útiles. Si necesita automatizar estos, debe tener cuidado con algunos peligros. Escribe tus pruebas, no las grabes . 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 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

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 que admite (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 :)