![translation](https://cdn.durumis.com/common/trans.png)
Esta es una publicación traducida por IA.
¿Qué pruebas se deben realizar para el desarrollo de una aplicación de una sola persona?
- Idioma de escritura: Coreano
- •
-
País de referencia: Todos los países
- •
- Tecnología de la información
Seleccionar idioma
Texto resumido por la IA durumis
- Destaca la importancia de escribir código de prueba antes del lanzamiento de la aplicación, y presenta prioridades para varios métodos de prueba, como pruebas de personas, pruebas de integración, pruebas unitarias y pruebas de aceptación y widgets.
- Los desarrolladores deben priorizar las pruebas de personas y las pruebas de integración (centradas en el proveedor) considerando la eficiencia del tiempo, agregar pruebas unitarias después del lanzamiento y considerar la eficiencia al realizar pruebas de aceptación y widgets, ya que consumen mucho tiempo.
- Se busca un lanzamiento rápido mediante la automatización de pruebas para ahorrar tiempo y aumentar la velocidad de desarrollo.
"No debe haber más gastos que ingresos. Es decir, no tiene sentido si escribir pruebas lleva más tiempo."
¿Se va a acabar el tiempo escribiendo pruebas?
La historia de escribir pruebas
Antes de lanzar la aplicación, intentaré llevar a cabo una prueba de código simple. De hecho, es la automatización de pruebas, así que creo que es mejor escribirlo ahora para no tener un dolor de cabeza en el futuro.
En primer lugar, mi prioridad de prueba es
Prueba humana > Prueba de integración (solo proveedor) > Prueba unitaria > Widget, prueba de aceptación
1. Simplemente prueba con personas
"La mejor solución es que un humano lo haga."
Primero, quiero probar la integración, analizando aproximadamente el flujo del usuario. Entonces, como ya he aprobado la prueba una vez, ¿no está bien?
2. Prueba unitaria
"Prueba si las partes más pequeñas funcionan correctamente."
De hecho, la prioridad es un poco baja porque no hay casos en los que otra persona haga una fusión (debido al desarrollo individual). Primero, verificaré si funciona correctamente y luego lanzaré la aplicación, y luego escribiré la prueba unitaria. Bueno, ya que funciona, habré completado el desarrollo. A menos que se actualice o se agregue algo más, la probabilidad de errores es baja por ahora.
3. Prueba de integración
"En realidad, la prueba del proveedor. Concéntrate solo en esto"
Creo que en la aplicación que estoy creando, es en realidad una verificación del proveedor. No tengo tiempo para volver a crearlo todo, y como el flujo se realiza normalmente a través de riverpod, ¿no disminuirán los errores solo con esto? Esa es mi pensamiento.
4. Prueba de aceptación, prueba de widgets
"Es importante, pero... se pierde tiempo haciéndolo."
La verificación del flujo del usuario y la prueba del widget son realmente muy importantes. Pero hay un problema... lleva mucho tiempo escribirlo. Es difícil verificar todas las ramas, y es casi imposible escribirlas todas. Y no es que al probar esto se garantice la seguridad al 100 %. Entonces, creo que la relación calidad-precio es muy baja. Creo que sería mejor probar el proveedor de prueba de integración, y si hay alguna parte que no funcione, se lo notificaré al usuario ... y luego actualizaré esa parte en ese momento.
Parece un poco irresponsable, pero creo que esta es la mejor manera.
Mis pensamientos
De hecho, las pruebas son lo mismo que la automatización. Es una buena manera de ahorrar tiempo al automatizar las cosas que una persona debe probar una por una.
Primero, el tiempo es dinero, así que voy a desarrollar rápidamente las cosas urgentes y acelerar la fecha de lanzamiento.
El tiempo se está acabando. Parece que necesito desarrollar rápidamente.
Sobre el desarrollador
Alien, la aplicación de citas global, está siendo desarrollada y operada conjuntamente por una pareja internacional real.
Youtube : https://www.youtube.com/@AlienApp
Correo electrónico : slugj2020@gmail.com