¿Es malo que no tenga una sola prueba escrita para mi aplicación web de inicio escrita en Rails?

tl; dr
* No es un problema ahora, pero será más tarde.
* Ahora es un buen momento para aprender.

Esto es lo que sucede con las pruebas para aplicaciones Rails: puede escribir una aplicación que funcione completamente sin ellas.

No está mal que te hayas saltado las pruebas, pero tu vida de desarrollo se haría mucho más fácil si las tuvieras. Claramente, entiendes que hay un beneficio en las pruebas o de lo contrario no hubieras hecho la pregunta.

Apuesto a que su equipo de desarrollo pasa mucho tiempo revisando la aplicación cada vez que se realizan cambios, para asegurarse de que las partes importantes de la aplicación no se rompan. Esto funciona, pero ese es el tipo de cosa que podría automatizarse con pruebas, liberando a sus desarrolladores para que sean desarrolladores y no evaluadores de control de calidad.

Su aplicación está en el negocio de manejar análisis en línea. Esto probablemente significa que hay muchos datos entrando y saliendo. En este momento, es sostenible para usted asegurarse manualmente de que los datos sean consistentes. Sin embargo, eso no durará mucho. Cada nuevo conjunto de datos que desea rastrear, cada API que desea construir y cada nueva característica que desea agregar a su cliente web aumenta exponencialmente la cantidad de tiempo que necesita para asegurarse de que todo lo que está debajo del capó funcione como se espera.

Se trata de tiempo y esfuerzo. Fue menos tiempo y esfuerzo simplemente construir algo y sacarlo de lo que hubiera sido aprender a escribir pruebas haciendo lo mismo. A medida que su aplicación crezca, ese número se inclinará a favor de escribir pruebas.

En este momento es un muy buen momento para comenzar a probar. Su equipo tiene un conocimiento íntimo de cómo funciona todo. La aplicación funciona y ya no se encuentra en modo de inicio-crisis. Es lo suficientemente pequeño como para ser un proyecto manejable. Hay suficiente trabajo involucrado para que su equipo salga con suficiente práctica para mantener un hábito de prueba con proyectos futuros.

Podría llegar a la producción sin problemas, lo que significa que su aplicación se ejecuta sin problemas y ha logrado un producto mínimo viable. ¿Qué pasará cuando comiences a hacer cambios? ¿Confía en que no romperá la funcionalidad existente en la función A cuando aumente o elimine la función B?

También hay muchos tipos diferentes de pruebas que podrían brindarle la seguridad que busca. Una de ellas es una prueba de regresión funcional, que implicaría implementar su aplicación y ejecutar una serie de pruebas de navegador Selenium o similares para asegurarse de que su aplicación esté en funcionamiento y que pasen los escenarios de ruta feliz. Otros tipos de pruebas pueden implicar probar el código subyacente de las piezas críticas de su aplicación, como por ejemplo, si el patrón de expresiones regulares que está utilizando para analizar datos de terceros coincide con más casos que el 1 escenario que codificó.

Las pruebas tienen que ver con su confianza en la implementación de cambios en el código, y si está dispuesto a aceptar el riesgo de que los usuarios accedan a su aplicación y tengan una experiencia rota, si confía únicamente en las pruebas manuales de qa o del globo ocular del desarrollador.

Trabajar eficazmente con código heredado es un libro comúnmente recomendado para personas que trabajan con bases de código que no tienen pruebas.

¡Sufrirás más tarde!

Es mucho más fácil escribir un marco de prueba para su aplicación cuando todavía es un bebé, y naturalmente evolucionará y aplicará buenos hábitos de programación.

Si pospone la prueba a “más tarde cuando tenga tiempo”. Probablemente nunca lo hagas.

Si es una maqueta, no hay problema. Si sus programadores hacen la prueba, pero usted no, supongo que es solo cuestión de confianza en su equipo. Sin embargo, si su equipo escribe algo para la producción sin siquiera pruebas básicas (no por usted, sino por cualquier persona), entonces parece un equipo de desarrolladores horrible.