Introducción a ELECLE Android TDD (3/3). El equipo Android de ELECLE introdujo TDD y desarrolló… | Por Jeongin Choi | Electrónica | Mar 2022
Hola, Servicio ELECLE operativo nueve a uno Soy Choi Jeong-in y trabajo en Android en el equipo móvil.
Esta es la última de una serie de introducciones a ELECLE Android TDD.en este articulo Un método para acelerar mediante la aplicación de un enfoque de desarrollo basado en pruebasPresentarte. Explicaré el evento de plantación para el análisis de datos usando un ejemplo de código.
Proyecto de ejemplo: eventos de plantación para el análisis de datos
nosotros Se están plantando varias campañas para seguir y analizar más de cerca la experiencia de los usuarios de ELECLE.
Por ejemplo, cómo los usuarios pueden alquilar bicicletas eléctricas Elecle: ¿Está escaneando un código QR, ingresando manualmente un número de serie, usando la función de reserva, usando la función de embarque directo o usando una etiqueta NFC? –analizar Cada vez que se lanza una nueva función, también se agregan eventos de análisis asociados con ella.ya
A medida que evoluciona la aplicación ELECLE, la gestión de eventos se vuelve cada vez más compleja y los problemas siguientes se acumulan.
Los eventos integrados en Firebase Analytics y los eventos integrados en Amplitude se mezclan. / Los eventos heredados que ya no se usan continúan. / Los eventos se plantan en la ubicación incorrecta. La parte del parámetro / es incorrecta. El valor / es extraño. / Algunos eventos solo están integrados en Android, no en iOS. (viceversa)
Así que aprovechamos esta oportunidad Cree un archivo para administrar funciones que envían eventos, establecen convenciones y manejan la lógica de la interfaz de manejo de errores Hemos realizado trabajos a gran escala como
«No se pudo montar» Tomando eventos como ejemplo, describa el proceso del ciclo Rojo → Verde → Refactor.vamos a hacerlo. «No se pudo montar» Los eventos son eventos que buscan información sobre el equipo de la bicicleta y las condiciones de error que ocurren cuando el usuario no inicia con éxito un paseo eléctrico. Los detalles del evento son los siguientes.
viaje fallido / cuando intentas montar y no arranca con éxito
exception_slug
(cadena): {scan_ble_not_found, riding_lock_already_opened, riding_lock_opened, riding_start_fail}region
(cadena): El código de área 11, 36, 411 es el área de servicio donde se encuentra la ubicación actual del usuario, si no está en el área de servicio, está vacíoservice_group
(cadena): la identificación del área de servicio donde la ubicación actual del usuario es {1,2,3,…}organization
(String): El código de organización de la bicicleta escaneado por el usuario. nulo si no hay organización {1,2,3…}inflow
(cadena): modo de conducción {nfc, autoride, qrcode, entrada}
escenario rojoEn , es necesario determinar qué tipo de pruebas se requieren y en qué medida. Por ejemplo, en el caso de funciones de eventos, se requieren tres pruebas principales de la siguiente manera.
evento Nombre¿Cumple con esta especificación?
evento clave de parámetro¿Cumple con la especificación?
evento El valor del parámetro¿Cumple con la especificación?
Por ejemplo, podría agregar el siguiente caso de prueba para verificar si se recibe un evento denominado «error en el viaje».
Escribí una breve descripción del caso de prueba con comentarios de varias líneas y agregué dado, cuándo y luego comentarios en línea. Vamos a explicarlo de esta manera:
dado — ajustes dados y valores iniciales para la prueba,
when — cuando se ejecuta la función de evento ‘sendRidingFailEvent’,
Luego, envíe un evento llamado «viaje fallido». (=El primer parámetro de la función que envía el evento a Amplitude es «fallo de viaje».)
Si comentas así, en el escenario verde, Fácil de implementar incluso cuando la funcionalidad está realmente implementadaY desde el punto de vista del revisor, cada caso de prueba Es bueno saber qué está probando y qué está haciendo su función objetivo.
Y puede probar si la clave del parámetro de evento entra de la siguiente manera.
K analógicos ‘Verificar’ a través de esta oración si se ha realizado una función específicase puede comprobar ‘exactamente=1’Literalmente, es una sentencia que comprueba si se ha ejecutado una vez. ranura, cada uno, con Arg Estas también son frases de uso frecuente.Uso detallado documentación oficial de mockKPuede verificarlo aquí 🙂
La prueba del valor de los parámetros del evento se puede realizar de manera similar a las pruebas críticas.Sin embargo, una cosa a tener en cuenta son las variables anulables cuando nulo se da como valorSí, también deberías probar.
De esta manera, se deben realizar pruebas de todos los casos vacíos para garantizar que todas las ramas estén bien probadas cuando se extrae la cobertura.
escenario verdeImplemente la funcionalidad real para que el caso de prueba pueda pasar. «No se pudo montar» Si implementa la función para que el nombre del evento y las claves y valores de los parámetros coincidan con la especificación, se verá así.
Una vez que pase el nombre «fallo de conducción» como parámetro en la línea 9, pasará el primer caso de prueba descrito anteriormente.
Si observa las líneas 2 a 7, las claves y los valores de los parámetros del evento se especifican de acuerdo con la especificación. Esto también pasará los casos de prueba segundo y tercero.
Sin embargo, en las líneas 3 y 7 «exception_slug» y «inflow» son cadenas Tenga en cuenta que lo pasamos como un parámetro! (Corregiremos esta parte en un próximo paso de refactorización. 😉)
Pasos de refactorizaciónRealmente tienes que refactorizar.En este punto, el caso de prueba ha pasado, por lo que el evento «error en el viaje» Función En realidad es hora de plantarlo en algún lugar.está.Luego nueva pregunta – tienes que seguir montando y pasando parámetros, de lo contrario no hay forma de detectar valores incorrectos antes de tiempo – ya verás.
Anteriormente, en la fase verde, la «entrada» era cuerdaentregue pero mire la especificación del evento nuevamente, enumerarParece más fácil y seguro de manejar.
inflow
(cadena): modo de conducción {nfc, autoride, qrcode, entrada}
Si se pasa como una cadena, tendría que hacer clic en cada uso de la función de evento para ver qué valores se pueden asignar a la entrada. Además, incluso si hay un error tipográfico, es difícil detectarlo y, para diferentes propósitos (p. ej., para eventos, puntos finales de vistas web, etc.), es probable que se confunda con cadenas.
como anteriormente RidingInflow
Si crea una clase de enumeración llamada y reemplaza el parámetro con el tipo RidingInflow en lugar de String, se verá así.
Cuando se usan enumeraciones como esta, es bueno que los miembros del equipo/sucesores sepan «cuáles son los posibles intentos de viaje», lo cual es bueno porque la seguridad de tipo está garantizada incluso a nivel de código.
«exception_slug» Además, mirando la especificación del evento, parece haber una mejor manera de administrarlo que pasarlo como una cadena.
exception_slug
(cadena): {scan_ble_not_found, riding_lock_already_opened, riding_lock_opened, riding_start_fail}
En este caso, decidí que sería mejor usar una clase sellada en lugar de una enumeración. RidingFailError
Creé una clase sellada llamada y creé el caso de error detallado como una subclase y pasé el flujo de entrada.
En este punto, la función de evento finalmente se completa sendRidingFailEvent
¡bajo!
Mientras escribía estos tres artículos, me quedé pensando. «¿No sería mejor si escribiera un tutorial como ‘Cómo escribir código de prueba con mockK’…» Tengo una idea. Sin embargo, sería más preciso y útil leer la documentación oficial de la biblioteca, así que decidí que sería mejor cubrir el ensayo y error que seguimos en una publicación moderada.
en este articulo rojo→verde→refactorización Expliqué el bucle y el código. Intento dar un ejemplo simple y comprensible, pero siento no poder transmitirlo al 100% porque estoy tratando de explicar el caso especial de Elicle.
posible Esta serie es útil para aquellos que quieren presentar TDD a su equipo pero se sienten abrumados porque no saben cómo empezar.Espero que se pueda 🙂
Ver todas las colecciones
Periodo de introducción de ELECLE Android TDD (1/3) → Antecedentes de la introducción de TDD, largo proceso de introducción seria
ELECLE Introducción a Android TDD (2/3) → Practica escribir código de prueba refactorizando sesiones, reuniendo citas
Período introductorio de ELECLE Android TDD (3/3) → El proceso de aplicar seriamente el método de desarrollo basado en pruebas sprint