Todos rega√Īan los marcos de prueba auto-escritos. Y estamos contentos con nuestro



Mi nombre es Elena Rastorgueva, soy responsable del producto Factor en HFLabs . El Factor es una empresa algorítmica muy compleja; procesa datos a escala industrial.

En el artículo, le contaré cómo comenzamos a probar el "Factor", cómo se desarrollaron las pruebas automáticas y por qué llegamos a los marcos autoescritos.

¬ŅQu√© tipo de producto es este?


"Factor" limpia datos en bases de datos con millones de clientes: elimina errores tipográficos en el nombre, teléfono y correo electrónico, revisa pasaportes, hace mucho más. Lo más difícil es corregir las direcciones de correo.


Las direcciones se escriben de cientos de maneras, por lo que el Factor tiene un fuerte aparato algorítmico bajo el capó

"Factor" funciona como un servicio: datos de entrada - datos de salida.

Este es un sistema sin estado donde cada llamada es independiente de las anteriores. Sin estado simplifica enormemente la vida del probador. Es mucho más difícil probar un sistema con estado cuando una secuencia de acciones es importante.

El producto debe ser confiable como ISS, ya que es utilizado por bancos, operadores móviles, seguros y minoristas del nivel Lenta. Respondemos por errores con la cabeza en la medida en que la ausencia de errores sea parte del SLA en el contrato con el cliente.

Debido a los requisitos de confiabilidad de las pruebas automáticas, escribimos desde el comienzo del desarrollo. Uno de los criterios para la preparación de la tarea es "Pruebas automáticas agregadas".

Comenzó con comprobaciones manuales y pruebas automáticas


Lanzamos el Factor en 2005 y primero lo probamos con nuestras manos. Por la ma√Īana, el probador realiz√≥ pruebas autom√°ticas en un archivo con casos y compar√≥ el resultado del procesamiento de datos con el resultado del d√≠a anterior: lo que cambi√≥ despu√©s de la confirmaci√≥n del c√≥digo de ayer.

El proceso podría tomar medio día, esta alineación no fue buena. Por lo tanto, tomamos el conjunto mínimo de pruebas para la funcionalidad clave y las incluimos en pruebas unitarias. Estas pruebas son rápidas, y el desarrollador mismo las ejecutó antes de comprometerse.

Las pruebas unitarias son tan convenientes y tan rápidas que agregamos miles de ellas. Y luego nos topamos con él: cuando las pruebas parecen una hoja de miles de piezas de código, no es fácil incluso desplazarse al lugar correcto. Sin mencionar agregar o actualizar.


Prueba unitaria para verificar el formato SNILS

Adem√°s, algo inesperado aparece repentinamente en los datos industriales que no cubre las pruebas unitarias. Por ejemplo, un nuevo cliente vino con nuevas funciones en las direcciones, las pruebas unitarias no cubren estas funciones. Debe sentarse y ver qu√© pruebas agregar para obtener nuevos datos. A√ļn lo hicimos manualmente.

Crea tu propio marco


En las pruebas unitarias tradicionales, los datos y el código se mezclan; es difícil encontrar las partes correctas.

Por lo tanto, probamos las pruebas automáticas en el paradigma de Pruebas controladas por datos (DDT) . DDT es cuando los datos para la prueba se almacenan por separado del código para la prueba.

Los casos se cargaron desde un archivo de Excel, estaban en las columnas "Datos sin procesar" y "Resultado esperado". El DDT fue un gran avance: la actualización de casos en el "exelnik" es inexpresablemente más simple.

Poco a poco, desarrollamos un enfoque y desarrollamos nuestro propio marco de prueba. Recibe archivos de texto como entrada, dentro de ellos est√°n los datos de origen y el resultado esperado.


Nos negamos a los archivos de Excel como almacenamiento: los archivos de texto se abren m√°s r√°pido, no cambian los contenidos, es m√°s f√°cil recolectar datos

El marco es ayudado por herramientas est√°ndar:

  • TeamCity ejecuta pruebas autom√°ticamente todas las noches;
  • testNG compara los resultados esperados y reales.


Si el resultado es diferente al esperado, en TeamCity la prueba se sonroja. Si todo está como debería, la prueba es verde

Modificó el marco para usted


Han pasado 12 a√Īos desde entonces. Durante este tiempo, el marco se ha cubierto de capacidades que no est√°n en las soluciones est√°ndar.

Contabilización del estado de la tarea en Jira. HFLabs se adhiere a Test Driven Development : primero escribimos una prueba o agregamos casos de prueba para un nuevo comportamiento, y solo luego cambiamos la funcionalidad.

Apagamos nuevos casos comentando la línea. De lo contrario, primero cayeron e interfirieron, porque los casos agregaron características o correcciones de errores antes.

Pero es posible que la tarea no pueda completar el caso de prueba correspondiente: el error resultará ser extremadamente raro o el cliente traerá algo más importante. Algunas tareas se suspendieron durante meses con baja prioridad y se acumularon casos desconectados. Al mismo tiempo, no está claro a qué tarea pertenece cada caso, si este caso se puede eliminar.

Por lo tanto, agregamos un n√ļmero de tarea a los casos desconectados y arruinamos un poco la automatizaci√≥n. Ahora todo funciona as√≠:

  • el caso de prueba se deshabilita al combinarlo con una tarea abierta en Jira;


    Para adjuntar un caso a una tarea, escriba delante de √©l # y n√ļmero de tarea
  • el marco ejecuta pruebas incluso en casos deshabilitados. Pero ignora los bloqueos mientras la tarea est√° abierta en Jira;
  • Tan pronto como se cierra la tarea, la prueba comienza a recaer en los casos adjuntos. Esta es una se√Īal: aprobaron la tarea, pero olvidaron encender los casos;
  • Si de repente la prueba para el caso desconectado comenz√≥ a pasar con una tarea abierta, el marco tambi√©n informar√° sobre esto. Quiz√°s sea hora de encender el caso o cerrar la tarea adjunta (adem√°s de actualizar las notas de la versi√≥n e informar a los clientes).


    El marco dice que el caso desconectado está pasando. Quizás alguien corrigió el código como parte de otra tarea, y ahora todo funciona

Así que ahorramos TDD y derrotamos el olvido al gestionar casos de prueba.


Documentamos todas las opciones con el estado de los casos de prueba y tareas relacionadas, para no olvidar

Actualización de casos de prueba en modo semiautomático. Parece que si la prueba falla, busque un error en el código. Pero para nosotros este no es siempre el caso. A veces sucede que los casos de prueba deben actualizarse, porque los requisitos para el resultado han cambiado.

Por ejemplo, antes de que el cliente en la direcci√≥n autorizada quisiera "g. Mosc√ļ "en un campo. Ahora que ha cambiado la arquitectura de la base de datos, quiere la "ciudad" en un campo, "Mosc√ļ" en otro. Es hora de cambiar los casos de prueba.

Para la prueba caída, TeamCity muestra la diferencia entre los resultados esperados y reales. Anteriormente, copiamos esta diferencia y actualizamos los casos de prueba con nuestras manos. Para cambios masivos, un evento muy costoso.


Un ejemplo vivo: ense√Īamos "Factor" para determinar un pa√≠s por n√ļmero de tel√©fono, las pruebas en TeamCity cayeron. Se puede tomar un nuevo punto de referencia del resultado real, pero lleva mucho tiempo

Hicimos que el marco actualizara el punto de referencia en sí. Para hacer esto, después de ejecutar las pruebas, reemplaza los resultados de limpieza esperados en el estándar con los resultados reales donde no coincidían. El resultado se guarda en artefactos como un archivo de actualización de caso.


El primer archivo es un nuevo punto de referencia en el que el marco ha actualizado los resultados esperados. Los archivos restantes son los datos de entrada, el est√°ndar anterior y los datos reales de los casos descartados.

Con el nuevo punto de referencia, el probador actualiza los casos en tres pasos.

  1. Descargue el archivo generado.
  2. Comprueba a través de cualquier herramienta de fusión qué cambios hay en el nuevo punto de referencia. Deja solo lo necesario.
  3. Comprometerse


El probador verifica si las actualizaciones en el nuevo est√°ndar son correctas y las confirma

Sí, si se actualiza sin pensar, nada bueno saldrá de eso. Pero existe el riesgo de una actualización irreflexiva cuando se trabaja manualmente.

Estabilizaci√≥n de datos de prueba con stubs. "Factor" devuelve datos procesados ‚Äč‚Äčen docenas de campos. Hay un mont√≥n de componentes en una sola direcci√≥n: √≠ndice, regi√≥n, tipo de regi√≥n, tipo de ciudad, ciudad, tipo de calle, casa, edificio, edificio, apartamento. Para ellos, el "Factor" atrapa IFTS, OKATO, OKTMO e incluso las peque√Īas cosas. Entonces, de una l√≠nea en la entrada se obtienen docenas de valores.

No todos los campos del resultado deben verificarse con casos de prueba. Por ejemplo, el reconocimiento de la misma direcci√≥n depende directamente del directorio de estado: FIAS. Y en √©l los campos cambian regularmente, para nuestras tareas son completamente extra√Īos. La actualizaci√≥n de algunos c√≥digos CLADR para casas dej√≥ caer cientos de casos de prueba.

Agregamos talones al resultado esperado cuando nos dimos cuenta de que estábamos perdiendo el tiempo analizando caídas sin importancia.

Cuando no es necesario verificar el campo, el probador escribe un símbolo en el resultado esperado: $$ DNV $$ . Cuándo debe rellenarse el campo, pero el valor en sí mismo no es importante: $$ NE $$ .


El ID de FIAS siempre está en la dirección, por lo que lo verificamos en todas las pruebas. Si el campo está vacío, algo está mal. Pero el índice puede no ser, por lo tanto, al verificar la ID de FIAS, ignoramos el índice

Podría ir hacia otro lado y separar las pruebas: cada campo tiene el suyo. Pero es difícil, porque no todo puede aislarse. Por ejemplo, "ciudad" y "calle" son partes de una dirección y sin la otra no tienen sentido.

Un marco auto escrito es m√°s conveniente


Por lo tanto, no considero en absoluto crear mi propio marco como una tarea est√ļpida. Si no hubi√©ramos creado nuestra propia herramienta, no habr√≠amos recibido tantas oportunidades nuevas y tanta flexibilidad.

Desactivar el caso de texto por estado de la tarea, generar un nuevo punto de referencia y resguardos para el resultado son las cosas que nuestros evaluadores ahora piden en otros marcos. Si tomáramos soluciones estándar, nunca podríamos hacerlo.

Si te gusta hacer cosas complejas en la empresa, ven a nosotros. Ahora estamos buscando un desarrollador de Java , salario de 135 000 ‚āĹ sin impuesto sobre la renta personal.

Source: https://habr.com/ru/post/437380/


All Articles