Me gusta el desglose de la respuesta de Alan Mellor, pero creo que sería útil aclarar algún término de confusión, que no es culpa de Alan, por cierto.
Las pruebas unitarias se refieren a la actividad de realizar, de forma manual o automatizada, un conjunto de pruebas en una sola “unidad” de código. Esa unidad se puede definir como desee, y depende en gran medida de cómo esté estructurada su aplicación.
El término confusión se infiltra en los marcos MVC front-end como AngularJS y ReactJS, que tienen características de prueba incorporadas en su nivel de “módulo” autodefinido. Debido a esas características, muchos desarrolladores front-end parecen referirse a este tipo de prueba de módulo como la única “prueba de unidad” verdadera, a menudo en contraste con las formas más antiguas de prueba de IU, que simplemente definen la unidad en un nivel superior ( por ejemplo, una sola página, un formulario de 3 pasos, etc.). Esas características de prueba integradas son muy elegantes, lo que permite simular fácilmente las “interacciones” de los pseudousuarios mediante un código de prueba, lo que facilita la prueba de piezas individuales de una IU altamente dinámica.
- ¿Las palabras clave en una página web mejoran el SEO?
- ¿Cómo angular js vienen con cambios drásticos en el mercado marco JS?
- Cómo trabajar de forma independiente como diseñador web
- ¿Cuál fue la pila de software menos irritante con la que has trabajado en tu vida de programación?
- ¿Alguien usa iPage? ¿Les gusta?
De vuelta a tu pregunta. Creo que la respuesta práctica es que cualquier front-end lo suficientemente complejo va a imponer una necesidad de pruebas unitarias. Si existe un problema de costo insuperable, puede elegir delegar esa prueba a sus usuarios finales. Pero incluso entonces, ayuda a dividir una aplicación compleja en “unidades” de nivel superior y proporcionar al menos un menú desplegable en su formulario de ticket de soporte para guiar a los usuarios finales a darle algunos detalles sobre qué parte del código está funcionando mal.
Si tiene una aplicación front-end dinámica compleja que no está construida sobre un marco de prueba de módulos como Angular o React, la batalla no se pierde. Todavía puede hacer pruebas unitarias, incluso a nivel de módulo (suponiendo que tenga módulos); si no, a nivel de flujo de trabajo. Las pruebas a nivel de flujo de trabajo son más rentables y una opción completamente viable incluso para aplicaciones profesionales. Permite ciclos de liberación mucho más rápidos con el riesgo conocido de permitir la entrada de errores relativamente menores.
Si bien es cierto que la automatización de las pruebas de aplicaciones web con navegadores aprovechados que utilizan Selenium SDK (también consulte phantomjs / casperjs) puede ser complicado y escamoso en comparación con llamar a métodos de prueba internos en Angular o React, a menudo es una buena propuesta de costo-beneficio en complejas aplicaciones profesionales que realizan pruebas de regresión a nivel de flujo de trabajo. No solo es independiente del framework, sino que también es más realista, captando problemas del usuario final que los métodos de interacción de la interfaz de usuario sintética ni siquiera ven como problemas (por ejemplo, un elemento clave de la interfaz de usuario está oculto por otro elemento y no se puede hacer clic en él).
También hay un número creciente de herramientas y servicios que se hacen cargo de mantener y ejecutar pruebas automatizadas en un horario. Los ejemplos incluyen sitios como Cross browser testing gratis. Selenium IDE integración. y (mi propio servicio) Inicio – QA2L.
