Durante el desarrollo, ¿cuántas pruebas es la cantidad correcta que debe hacer un sitio web?

Creo que depende de qué tipo de software estés escribiendo y para quién. He trabajado en proyectos donde hicimos todo lo anterior con CI y en proyectos que no hicieron absolutamente ninguna prueba.

Probablemente me crucificarán por decir esto, pero si está creando un producto web para el consumidor y está haciendo múltiples lanzamientos al día, a menudo es aceptable que los usuarios lo ayuden a encontrar errores no críticos y las pruebas funcionales no serán tan importantes. Es posible que solo escriba pruebas funcionales para su API, por ejemplo, que no puede permitirse tener un descanso o la funcionalidad principal de su producto.

Me gustan las pruebas unitarias para verificar la “lógica empresarial”. Estos son especialmente importantes si no está utilizando restricciones en su base de datos (o su almacén de datos no las admite) para la integridad de los datos. Además de esto, uno de los mayores beneficios que obtengo al escribir pruebas unitarias es que me ayuda a diseñar mejores interfaces para mis objetos. Escribir pruebas de regresión tiende a producir una gran recompensa también, ya que las mismas funciones siempre parecen propensas a errores.

Como todo lo demás, tendrá que sopesar las compensaciones. Me equivocaría en el lado de las pruebas, especialmente si tiene más de un par de desarrolladores en el producto porque rápidamente se dará cuenta de un gran ahorro de tiempo solucionando errores. Por otro lado, si usted es un desarrollador exclusivo que trabaja en un pequeño proyecto web para el consumidor y desea avanzar rápidamente, puede aceptar incurrir en una deuda técnica.

Las pruebas unitarias no son algo que haces porque “es lo correcto”, lo haces porque ahorras tiempo. Para cualquier código, piense en el tiempo que pasará escribiéndolo y modificándolo en los próximos 6 meses. En muchos casos, claramente querrá escribir pruebas unitarias (por ejemplo, escribir estructuras de datos).

Una cosa a tener en cuenta es que las pruebas suelen ser más fáciles si lo haces desde el principio. Si intenta realizar pruebas más tarde, a menudo necesitará refactorizar.

Un punto que rara vez se plantea, pero sin embargo es importante: ¡no realice pruebas a ciegas! Una cosa que debemos hacer es definir la estrategia de prueba al comienzo. No todo tipo de software necesita la misma cantidad de pruebas (dependiendo de cuán críticos sean) y no todas las partes del software necesitan la misma atención.
Sé por experiencia que algunas partes del software requieren mucha atención y, a veces, son partes no previstas por los desarrolladores. Por ejemplo: instaladores! Los instaladores son el primer contacto de los usuarios con el software, ¡debe comportarse correctamente en cualquier momento en todas las condiciones!
Por otro lado, algunas páginas web en el interior del árbol de navegación no requerirán dedicar demasiado tiempo a las pruebas. Puede bloquearse en condiciones inesperadas, pero no sería razonable gastar demasiado esfuerzo aquí.

En resumen: ¡desarrolle una estrategia y adapte su esfuerzo de prueba al contexto!