Try using it in your preferred language.

English

  • English
  • 汉语
  • Español
  • Bahasa Indonesia
  • Português
  • Русский
  • 日本語
  • 한국어
  • Deutsch
  • Français
  • Italiano
  • Türkçe
  • Tiếng Việt
  • ไทย
  • Polski
  • Nederlands
  • हिन्दी
  • Magyar
translation

Esta es una publicación traducida por IA.

Alien Story

¿Qué pruebas se deben realizar para el desarrollo de una aplicación de una sola persona?

Seleccionar idioma

  • Español
  • English
  • 汉语
  • Bahasa Indonesia
  • Português
  • Русский
  • 日本語
  • 한국어
  • Deutsch
  • Français
  • Italiano
  • Türkçe
  • Tiếng Việt
  • ไทย
  • Polski
  • Nederlands
  • हिन्दी
  • Magyar

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





Alien
Alien Story
Alien developer & international couple
Alien
La primera historia de un desarrollador de aplicaciones alienígenas La historia de un desarrollador que elige durumis para comenzar un blog global. Su objetivo es promover una aplicación de citas internacional utilizando soporte para 38 idiomas y herramientas de traducción automática de YouTube. También es el operador del

21 de abril de 2024

Las razones por las que el matrimonio internacional es bueno Esta es la historia del desarrollador que creó una aplicación de citas para parejas internacionales. Presenta las ventajas de conocer gente de otros países a través de la aplicación y los objetivos que el desarrollador quiere lograr con la aplicación. Ech

5 de mayo de 2024

Selección de la región del servidor de la aplicación Alien (AWS) Este artículo trata sobre el proceso de diseño e implementación de un servidor AWS para la aplicación de citas global Alien. Se presentan las necesidades de soporte multirregional, escalado automático, etc., junto con los criterios de selección de la regi

8 de mayo de 2024

Creamos un programa automatizado para mejorar la productividad. Durumis es una empresa que desarrolla programas automatizados para mejorar la productividad. Puede utilizar la automatización para diversas tareas, como el trabajo, los pasatiempos y la vida diaria, para convertirla en su propio robot secretario. Ofrecemo
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
¡Mi propia secretaria robot!
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마

22 de marzo de 2024

¿No quieres sonreír cada mañana? El secreto de la felicidad del 1% Esta es una historia sobre la experiencia y el crecimiento que he experimentado al mantener una publicación diaria durante 60 días. Captura el proceso de descubrir nuevos caminos mientras se mantiene una actitud positiva y la resiliencia a través de la es
카니리 @khanyli
카니리 @khanyli
카니리 @khanyli
카니리 @khanyli
카니리 @khanyli

6 de mayo de 2024

[Sin ser un experto, sobrevivir como desarrollador] 16. Consejos para crear una cartera para desarrolladores junior Un desarrollador junior (especialmente uno que no tiene formación en el campo) debe describir claramente no solo las tecnologías en su portafolio, sino también los servicios o funciones que ha desarrollado. Por ejemplo, en el caso de un proyecto de "Comun
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

3 de abril de 2024

[Historia de un desarrollador de SI] 09. El comienzo del desarrollo real después de la asignación del proyecto SI El desarrollador de SI desarrolla las funciones especificadas en la RFP después de la asignación del proyecto, pero debido a los requisitos adicionales del cliente, los cambios de código son frecuentes, por lo que la velocidad de desarrollo es más importa
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

18 de abril de 2024

Prueba de texto No hay vista previa de durumis AI.
안민수
안민수
안민수
안민수

29 de abril de 2024

Burla de Prisma Client para pruebas unitarias en NestJS La eliminación de dependencias externas es crucial al probar unidades de aplicación. Puede realizar pruebas unitarias fácilmente utilizando el método de burla de Jest para Prisma ORM. Después de instalar el paquete jest-mock-extended, puede simular Prisma
제이의 블로그
제이의 블로그
제이의 블로그
제이의 블로그

2 de abril de 2024