¿Qué pruebas debo realizar para el desarrollo de una aplicación individual?

"El cabo no debe ser más grande que la sandía. Es decir, no tiene sentido si escribir las pruebas lleva más tiempo."

Historia de la escritura de pruebas

Antes de lanzar la aplicación, quiero realizar una prueba de código simple. Como se trata de automatizar las pruebas, creo que es mejor escribirlas ahora para no tener problemas más adelante.

Primero, la prioridad de las pruebas que tengo en mente es

Prueba humana > Prueba de integración (solo proveedor) > Prueba unitaria > Prueba de widgets y aceptación

1. Simplemente, prueba humana

"La respuesta es simplemente que un humano lo pruebe."

Primero, intentaré revisar el flujo de usuarios a grandes rasgos mientras realizo la prueba de integración. Si la prueba se aprueba una vez, ¿no estará bien?

2. Prueba unitaria

"Simplemente, prueba si las partes más pequeñas funcionan bien."

De hecho, la prioridad es un poco baja porque no existe la posibilidad de que otra persona realice una fusión (debido al desarrollo individual). Primero, verificaré si funciona a grandes rasgos y luego lo lanzaré y escribiré la prueba unitaria. Como funciona, significa que el desarrollo se ha completado. A menos que se actualice o se agregue algo más, la probabilidad de que ocurra un error es baja por ahora.

3. Prueba de integración

"En realidad, es una prueba de proveedor. Centrémonos en esto."

En mi aplicación, creo que es esencialmente una comprobación del proveedor. No tengo tiempo para volver a crear todo y, como la mayoría de los flujos se realizan con Riverpod, ¿no se reducirán considerablemente los errores si solo realizo esta prueba? Esa es mi idea.

4. Prueba de aceptación y widgets

"Es importante, pero... si lo hago, se acabará el tiempo."

La comprobación del flujo de usuarios y la prueba de widgets son realmente muy importantes. Sin embargo, existe un problema: escribir estas pruebas lleva mucho tiempo. Es difícil verificar todas las bifurcaciones y, en realidad, es casi imposible escribirlas todas. Además, no se garantiza un 100% de seguridad al realizar esta prueba. Por lo tanto, creo que la relación calidad-precio es muy baja. Creo que sería suficiente probar el proveedor en la prueba de integración y, si hay algún problema, notificarlo al usuario o algo así... ¿y actualizarlo según sea necesario?

Mis pensamientos

En realidad, la prueba es como una automatización. Es una buena manera de ahorrar tiempo al automatizar las cosas que una persona tendría que probar una por una.

Como el tiempo es oro, debo desarrollar rápidamente las cosas urgentes y lanzarlas lo antes posible.

Sobre el desarrollador

YouTube: https://www.youtube.com/@AlienApp
Correo electrónico: slugj2020@gmail.com