Hola Quiero contarles cómo funcionan las pruebas en el proyecto
Autotech , un servicio de inspección de automóviles de VIN. Debajo del corte: sobre qué herramientas usamos para probar los requisitos, la planificación del sprint, cómo funciona el proceso de prueba en nuestro proyecto.
MindMap's para tareas de aseo
Usamos scrum en el Auto Center, ya que esta es la metodología más exitosa para nuestras tareas. Semanalmente, celebramos reuniones en las que priorizamos, determinamos la complejidad, descomponemos las tareas del trabajo atrasado y establecemos Definición de Listo y Definición de Hecho para cada una de las tareas (puede leer sobre ellas en
este maravilloso artículo ). Este proceso se llama preparación del trabajo atrasado.
Para una preparación efectiva, se deben considerar todas las dependencias. Sepa cómo la implementación de la tarea puede afectar negativamente el proyecto. Comprenda qué funcionalidad necesita admitir y cuál cortar. Quizás, en el proceso de implementación de la tarea, la API para socios pueda verse afectada, o solo necesita recordar implementar métricas para comprender la eficiencia del negocio. Con el desarrollo de cualquier proyecto, cada vez hay más dependencias de este tipo, y tenerlas en cuenta es cada vez más difícil. Esto es malo: es importante que el equipo de soporte conozca todas las funciones a tiempo. Y a veces las innovaciones deben coordinarse con el departamento de marketing.
Como resultado, propuse una solución basada en MindMap, que reflejaba casi todas las dependencias que podrían afectar DoD, DoR y la evaluación de tareas.
La ventaja de este enfoque es una representación visual de todas las dependencias posibles en un estilo jerárquico, así como bollos adicionales en forma de iconos, selección de texto y ramas multicolores. Todo el equipo tiene acceso a este MindMap, que le permite mantener el mapa actualizado. Extendí el espacio en blanco de dicha tarjeta, que puede tomarse como un hito, aquí,
melón . (Haré una reserva de inmediato que esto es solo una guía, y es muy dudoso usar esta tarjeta para sus tareas sin finalizar el proyecto).
Linty y análisis de código estático para Go
En nuestro proyecto, una cantidad bastante grande de código golang, y para que el estilo del código cumpla con ciertos estándares, se decidió aplicar un análisis de código estático. Sobre lo que es, hay un excelente
artículo sobre Habré.
Queríamos integrar el analizador en el proceso de CI, de modo que en cada compilación del proyecto se inicie el analizador y, según los resultados de la verificación, la compilación continúa o se bloquea con errores. En general, usar gometalinter como un paso de compilación separado en Teamcity sería una buena solución, pero ver los errores en los registros de compilación no es muy conveniente.
Continuamos buscando y encontrando el Linty Bot, desarrollado como parte del hackatón Avito
por Artemy
Flaker Ryabinkov.
Este es un bot que monitorea el código del proyecto en nuestro sistema de control de versiones y lanza un analizador de código de diferencias con cada solicitud de extracción. Si se produce un error durante el análisis, el bot envía un comentario a este RP a la línea de código deseada. Sus ventajas son la velocidad de conexión con el proyecto, la velocidad del trabajo, los comentarios sobre las solicitudes de extracción y el uso de la interfaz popular Gometalinter, que por defecto ya contiene todas las comprobaciones necesarias.
MockServer y cómo obtener servicios para dar lo que necesitan
La siguiente sección trata sobre la estabilidad de la prueba. El concesionario de automóviles es extremadamente dependiente de las fuentes de datos (provienen de concesionarios, servicios gubernamentales, estaciones de servicio, compañías de seguros y otros socios), pero su inoperancia no puede ser la base para negarse a realizar pruebas.
Debemos verificar el conjunto de informes tanto en las fuentes de trabajo como en su inoperancia. Hasta hace poco, utilizamos fuentes de datos reales en el entorno de desarrollo y, en consecuencia, dependíamos de su estado. Resultó que indirectamente verificamos estas fuentes en las pruebas de IU. Como resultado, tuvieron pruebas inestables que se cayeron junto con las fuentes y esperaron una encuesta de fuentes de datos, lo que no contribuyó a la velocidad de pasar las pruebas automáticas.
Tuve la idea de escribir mi propio simulacro y así reemplazar las fuentes de Autotech. Pero al final, se encontró una solución más simple: el
MockServer listo para
usar , desarrollo de código abierto en Java.
El principio de su trabajo:
- creando expectativas
- coincidir con las solicitudes entrantes,
- Si se encuentra una coincidencia, envíe una respuesta.
Un ejemplo de creación de una espera usando un cliente java:
new MockServerClient("localhost", 1080) .when( request() .withMethod("POST") .withPath("/login") .withBody("{username: 'foo', password: 'bar'}") ) .respond( response() .withStatusCode(302) .withCookie( "sessionId", "2By8LOhBmaW5nZXJwcmludCIlMDAzMW" ) .withHeader( "Location", "https://www.mock-server.com" ) );
Como puede ver en el ejemplo, describimos la solicitud que enviaremos y la respuesta que queremos recibir. MockServer recibe la solicitud, intenta compararla con las que se crearon y, si hay coincidencias, devuelve una respuesta. Si la solicitud no falla, obtenemos 404.
Para MockServer hay clientes para Java y JavaScript, excelente documentación y ejemplos de uso. Existe la posibilidad de que coincidan las solicitudes en RegExp, el registro detallado en el servidor y un montón de chips. Para nuestras necesidades, era un candidato ideal. El proceso de lanzamiento se describe en detalle en el sitio, por lo que volver a contarlo aquí no ve el punto. El único momento, la última versión tenía bastante pérdida de memoria, por lo que usamos la versión 5.2.3. Ten cuidado Otro inconveniente es que Mockserver no tiene soporte SOAP listo para usar.
Por el momento, MockServer ha estado trabajando con nosotros durante aproximadamente tres meses. Como resultado, la estabilidad de las pruebas, la velocidad de su ejecución y la capacidad de recibir datos en un entorno de desarrollo han aumentado. Y en consecuencia, hay más oportunidades para realizar pruebas.
Epílogo
Estas tecnologías son las principales cosas de las que me gustaría hablar en este artículo. Por lo demás, utilizamos las herramientas de prueba habituales: pruebas API con el paquete Kotlin + JUnit + RestAssured, Postman para la conveniencia de acceder a la API. En este artículo de revisión, no hablé sobre nuestro enfoque para las pruebas de IU. Usamos MBT y
Graphwalker . Estamos planeando preparar una publicación con colegas sobre esto.
Si tiene alguna pregunta, pregunte en los comentarios, intentaré responder. Espero que este artículo sea útil para los equipos de desarrollo. (Por cierto, mientras se preparaba para el lanzamiento, apareció un trabajo de
desarrollador de control de calidad en nuestro equipo, que muestra a los que podrían estar interesados en él).