¿Debo escribir pruebas unitarias para expresiones regulares complejas en mi aplicación?
- Por un lado: son fáciles de probar porque el formato de entrada y salida a menudo es simple y bien definido, y a menudo pueden volverse tan complejos que las pruebas de ellos específicamente son valiosas.
- Por otro lado: ellos mismos rara vez forman parte de la interfaz de alguna unidad. Sería mejor probar solo la interfaz y hacerlo de una manera que implícitamente pruebe las expresiones regulares.
EDITAR:
Estoy de acuerdo con Doc Brown, quien en su comentario señala que este es un caso especial de pruebas unitarias de componentes internos .
Pero como los componentes internos regexes tienen algunas características especiales:
- Una expresión regular de una sola línea puede ser realmente compleja sin ser realmente un módulo separado.
- Las expresiones regulares asignan la entrada a la salida sin ningún efecto secundario y, por lo tanto, son realmente fáciles de probar por separado.
Respuestas:
Dejando a un lado el dogmatismo, la verdadera pregunta es si proporciona valor para la prueba unitaria de expresiones regulares complejas. Parece bastante claro que proporciona valor (independientemente de si la expresión regular es parte de una interfaz pública) si la expresión regular es lo suficientemente compleja, ya que le permite encontrar y reproducir errores y evitar regresiones.
fuente
isValid,parse,tryParse, o lo que sea, dependiendo exactamente cómo se está utilizando), por lo que el código del cliente no tiene que saber que está implementado actualmente usando una expresión regular. La unidad de envoltura tendría pruebas detalladas que, una vez más, no necesitarían conocer la implementación actual. Estas pruebas, por supuesto, son pruebas de facto de la expresión regular, pero de una manera independiente de la implementación.FooValidatorsus entradas y salidas, luego no le preocupa cómo se está haciendo. ++Regex puede ser una herramienta poderosa, pero no es una herramienta en la que pueda confiar para que funcione si realiza cambios menores en expresiones regulares complejas.
Por lo tanto, cree muchas pruebas que documenten los casos que debe cubrir. Y cree muchas pruebas que documenten casos en los que debería fallar, si se usa para la validación.
Cada vez que necesite cambiar sus expresiones regulares, agregue los nuevos casos como pruebas, modifique sus expresiones regulares y espere lo mejor.
Si estuviera en una organización que en general no usara pruebas unitarias, aún escribiría un programa de prueba que probaría cualquier expresión regular que usaríamos. Incluso lo haría en mi propio tiempo si tuviera que hacerlo, mi cabello no necesita perder más color.
fuente
Las expresiones regulares son código junto con el resto de su aplicación. Debe probar que el código en general hace lo que espera que haga. Esto tiene varios propósitos:
Como hay un obstáculo adicional que superar al tener el código en un idioma diferente incrustado con el resto, lo más probable es que debas prestar esta atención adicional en beneficio del mantenimiento.
fuente
En resumen, debe probar su aplicación, punto. Ya sea que pruebe su expresión regular con pruebas automáticas que lo ejecutan de forma aislada, como parte de una caja negra más grande o si simplemente juega con ella a mano, es secundario para asegurarse de que funcione.
La principal ventaja de las pruebas unitarias es que ahorran tiempo. Te permiten probar la cosa tantas veces como quieras ahora o en cualquier momento en el futuro. Si hay alguna razón para creer que su expresión regular se refactorizará, ajustará, obtendrá más restricciones, etc., entonces sí, es probable que desee algunas pruebas de regresión, o cuando lo cambie, tendrá que ir a través de una hora de pensar en todos los casos límite para que no lo rompas. Eso, o aprendes a vivir con el miedo a tu código y simplemente nunca lo cambias.
fuente
Creo que con esto lo respondiste tú mismo. Las expresiones regulares en una unidad son muy probablemente un detalle de implementación.
Lo que vale para probar tu SQL probablemente también va para expresiones regulares. Cuando cambia un pedazo de SQL, probablemente lo ejecute a través de un cliente SQL a mano para ver si produce lo que espera. Lo mismo ocurre cuando cambio una expresión regular, uso alguna herramienta de expresión regular con alguna entrada de muestra para ver si hace lo que esperaba.
Lo que encuentro útil es un comentario cerca de la expresión regular con una muestra de texto que debe coincidir.
fuente
Si tiene que preguntar, la respuesta es sí.
Supongamos que aparece un FNG y cree que puede "mejorar" su expresión regular. Ahora, él es un FNG, así que automáticamente un idiota. ¡Exactamente el tipo de persona que nunca debe tocar su precioso código bajo ninguna circunstancia! Pero tal vez esté relacionado con el PHB o algo así, así que no hay nada que puedas hacer.
Excepto que sabes que el PHB te arrastrará pateando y gritando de nuevo a este proyecto para "tal vez darle al chico algunos consejos sobre cómo hiciste este desastre" cuando todo va mal. Entonces, escribe todos los casos que ha considerado cuidadosamente al construir su hermosa obra maestra de expresión.
Y dado que los ha escrito todos, tiene dos tercios del camino para tener un conjunto de casos de prueba, ya que, seamos sinceros, los casos de prueba de expresiones regulares son muy fáciles de ejecutar una vez que se ha creado el marco.
Entonces, ahora tiene un conjunto de condiciones de borde, alternativas y resultados esperados. Y de repente, los casos de prueba son la documentación tal como se prometió en todas esas publicaciones de blog de Agile. Simplemente le señala a la FNG que si su "mejora" no supera los casos de prueba existentes, no es una gran mejora, ¿verdad? ¡Y dónde están sus nuevos casos de prueba propuestos que demuestran algún problema con el código original, que ya que funciona, no necesita modificarse, nunca!
fuente