Pruebas unitarias en un DBMS: cómo lo hacemos en Sportmaster, segunda parte

Primera parte - aquí.

Imagina una situación. Se enfrenta a la tarea de desarrollar una nueva funcionalidad. Tienes la experiencia de tus predecesores. Suponiendo que no tiene obligaciones morales, ¿qué haría?

La mayoría de las veces, todos los desarrollos antiguos se olvidan y todo comienza de nuevo. A nadie le gusta profundizar en el código de otra persona y, si tiene tiempo, ¿por qué no comienza a crear su propio sistema? Este es un enfoque típico, y en muchos aspectos es correcto. Pero en nuestro proyecto, actuamos de manera diferente. Basamos el futuro sistema de pruebas automatizadas en los desarrollos de pruebas unitarias en utPLSQL de nuestros predecesores, y luego nos pusimos a trabajar en varias direcciones paralelas.

1. Restauración de pruebas unitarias antiguas. Recuperación significa adaptación de las pruebas al estado existente del sistema de fidelización y adaptación de las pruebas a los estándares utPLSQL.
2. Resolviendo el problema con la comprensión, y qué exactamente, qué métodos y procesos, hemos cubierto con autotests. Debe mantener esta información en su cabeza o sacar conclusiones basadas directamente en el código de autotests. Por lo tanto, decidimos crear un catálogo. Asignamos un código mnemotécnico único a cada autoprueba, creamos una descripción y arreglamos la configuración (por ejemplo, en qué condiciones se debe ejecutar o qué debe suceder si la prueba falla). En esencia, completamos los metadatos sobre las pruebas automáticas y colocamos estos metadatos en las tablas estándar del esquema utPLSQL.
3. Definición de la estrategia de expansión, es decir. selección de funcionalidad que está sujeta a verificación por autotests. Decidimos prestar atención a tres cosas: nuevas mejoras en el sistema, incidentes de producción y procesos clave del sistema. Por lo tanto, desarrollamos en paralelo con el lanzamiento, asegurando su mayor calidad, ampliando simultáneamente el alcance de la regresión y asegurando la confiabilidad del sistema en lugares críticos. El primer cuello de botella de este tipo fue el proceso de distribución de descuentos y bonificaciones mediante cheque.
4. Naturalmente, comenzamos a desarrollar nuevas pruebas automáticas. Una de las primeras tareas del lanzamiento fue evaluar el rendimiento de muestras predefinidas del sistema de fidelización. Nuestro proyecto tiene un bloque de consultas sql rígidamente fijadas que seleccionan clientes según condiciones. Por ejemplo, obtenga una lista de todos los clientes cuya última compra fue en una ciudad en particular, o una lista de clientes cuyo monto promedio de compra está por encima de cierto valor. Habiendo escrito pruebas automáticas, verificamos muestras predefinidas, fijamos parámetros de rendimiento de referencia y, además, obtuvimos pruebas de carga.
5. Trabajar con autotests debería ser conveniente. Las dos acciones más comunes son ejecutar pruebas automáticas y generar datos de prueba. Así aparecieron dos módulos auxiliares en nuestro sistema: el módulo de lanzamiento y el módulo de generación de datos.

   El lanzador se representa como un procedimiento genérico con un parámetro de texto de entrada. Como parámetro, puede pasar un código nemotécnico de autoprueba, un nombre de paquete, un nombre de prueba, una configuración de autoprueba o una palabra clave reservada. El procedimiento selecciona y ejecuta todas las pruebas automáticas que cumplen las condiciones.

   El módulo de generación de datos se presenta como un paquete, en el que para cada objeto del sistema bajo prueba (una tabla en la base de datos), se ha creado un procedimiento especial que inserta datos allí. En este procedimiento, los valores predeterminados se llenan al máximo, lo que garantiza la creación de objetos literalmente con el clic de un dedo. Y para facilitar su uso, se crearon plantillas para los datos generados. Por ejemplo, cree un cliente de cierta edad con un teléfono de prueba y una compra completa.

6. Las pruebas automáticas deben ejecutarse y ejecutarse dentro de un tiempo razonable para su sistema. Por ello, se organizó un lanzamiento nocturno diario, a partir de cuyos resultados se genera un informe de resultados y se envía a todo el equipo de desarrollo por correo corporativo. Después de restaurar las pruebas automáticas antiguas y crear otras nuevas, el tiempo total de ejecución fue de 30 minutos. Tal desempeño se adaptó a todos, ya que el lanzamiento tuvo lugar fuera del horario laboral.

   Pero teníamos que trabajar en optimizar la velocidad de trabajo. El sistema de fidelización de la producción se actualiza por la noche. Como parte de uno de los lanzamientos, tuvimos que hacer cambios urgentemente por la noche. Media hora esperando los resultados de las pruebas automáticas a las tres de la mañana no hizo feliz a la persona responsable del lanzamiento (¡saludos ardientes a Alexei Vasyukov!), Y a la mañana siguiente se dijeron muchas palabras cálidas hacia nuestro sistema. Pero como resultado, se estableció un estándar de trabajo de 5 minutos.

   Para acelerar el rendimiento, utilizamos dos métodos: comenzamos a ejecutar autotests en tres subprocesos paralelos, ya que esto es muy conveniente debido a la arquitectura de nuestro sistema de fidelización. Y abandonamos el enfoque cuando la autoprueba no crea datos de prueba por sí misma, sino que intenta encontrar algo adecuado en el sistema. Después de realizar cambios, el tiempo total de funcionamiento se redujo a 3-4 minutos.

7. Un proyecto con autotests debería poder implementarse en varios soportes. Al comienzo del viaje, hubo intentos de escribir nuestros propios archivos por lotes, pero quedó claro que una instalación automatizada autoescrita es un completo horror, y nos dirigimos hacia soluciones industriales. Debido a que el proyecto tiene mucho código directamente (en primer lugar, almacenamos el código de las pruebas automáticas) y muy pocos datos (los datos principales son metadatos sobre las pruebas automáticas), resultó ser muy fácil de integrar en el Proyecto Liquibase.

   Es una biblioteca independiente de base de datos de código abierto para rastrear, administrar y aplicar cambios en el esquema de la base de datos. Administrado a través de la línea de comandos o marcos como Apache Maven. El principio de funcionamiento de Liquibase es bastante simple. Tenemos un proyecto organizado de cierta manera, que consiste en cambios o scripts que deben implementarse en el servidor de destino y archivos de control que determinan en qué orden y con qué parámetros deben instalarse estos cambios.

   En el nivel de DBMS, se crea una tabla especial en la que Liquibase almacena el registro de reversión. Cada cambio tiene un hash calculado que se compara cada vez entre el proyecto y el estado en la base de datos. Gracias a Liquibase, podemos implementar fácilmente cambios en nuestro sistema en cualquier circuito. Las pruebas automáticas ahora se ejecutan en bucles de prueba y liberación, así como en contenedores (bucles personales de los desarrolladores).

Entonces, hablemos de los resultados de aplicar nuestro sistema de pruebas unitarias.

1. Por supuesto, en primer lugar, estamos convencidos de que comenzamos a desarrollar un mejor software. Las pruebas automáticas se ejecutan a diario y encuentran docenas de errores en cada versión. Además, algunos de estos errores solo están indirectamente relacionados con la funcionalidad que realmente queríamos cambiar. Existen fuertes dudas de que estos errores se hayan encontrado mediante pruebas manuales.
2. El equipo ganó confianza en que la funcionalidad específica funciona correctamente... En primer lugar, esto se refiere a nuestros procesos críticos. Por ejemplo, en los últimos seis meses no hemos tenido problemas con la distribución de descuentos y bonos por cheque, a pesar de los cambios realizados en cada lanzamiento, aunque en periodos anteriores ocurrieron errores con cierta frecuencia.
3. Logramos reducir el número de iteraciones de prueba. Debido al hecho de que las autopruebas están escritas para nuevas funcionalidades, los analistas y evaluadores a tiempo parcial obtienen un código de mayor calidad, porque ya ha sido verificado.
4. Parte de los desarrollos de las pruebas automatizadas es utilizado por los desarrolladores. Por ejemplo, los datos de prueba en contenedores se crean utilizando el módulo de generación de objetos.
5. Es importante que hayamos desarrollado una "aceptación" del sistema de prueba automatizado por parte de los desarrolladores. Hay un entendimiento de que esto es importante y útil. Y desde mi propia experiencia, puedo decir que esto está lejos de ser el caso. Las autopruebas deben escribirse, deben mantenerse y desarrollarse, los resultados deben analizarse y, a menudo, estos costos de tiempo simplemente no valen la pena. Es mucho más fácil ir a producción y solucionar los problemas allí. En nuestro país, los desarrolladores hacen cola y piden cubrir su funcionalidad con autotests.

¿Qué sigue

Hablemos de los planes de desarrollo del proyecto de pruebas automatizadas.

Por supuesto, mientras el sistema de fidelización Sportmaster esté vivo y continúe desarrollándose, las pruebas automáticas también se pueden desarrollar casi sin fin. Por lo tanto, la dirección principal del desarrollo es la expansión del área de cobertura.

A medida que aumenta el número de autotests, el tiempo total de su trabajo aumentará constantemente y nuevamente tendremos que volver al tema del rendimiento. Lo más probable es que la solución sea aumentar el número de subprocesos paralelos.

Pero estas son formas obvias de desarrollo. Si hablamos de algo más no baladí, destacamos lo siguiente:

1. Ahora las pruebas automáticas se gestionan a nivel de DBMS, es decir, Se requiere conocimiento de PL/SQL para un trabajo exitoso. Si es necesario, la administración del sistema (por ejemplo, el lanzamiento o la creación de metadatos) se puede realizar mediante algún tipo de panel de administración usando Jenkins o algo similar.
2. Todo el mundo ama los indicadores cuantitativos y cualitativos. Para las pruebas automáticas, dicho indicador universal es Cobertura de código o métrica de cobertura de código. Usando este indicador, podemos determinar qué porcentaje del código de nuestro sistema bajo prueba está cubierto por autotests. A partir de la versión 12.2, Oracle brinda la capacidad de calcular esta métrica y sugiere usar el paquete estándar DBMS_PLSQL_CODE_COVERAGE.

   Nuestro sistema de autoprueba tiene poco más de un año y podría ser el momento de evaluar la cobertura. En mi último proyecto (un proyecto que no es de Sportmaster), sucedió esto. Un año después de trabajar en autotests, la gerencia se dio a la tarea de evaluar qué porcentaje del código cubrimos. Con más del 1% de cobertura, la gerencia estaría feliz. Nosotros, los desarrolladores, esperábamos un resultado de alrededor del 10%. Arruinamos la cobertura del código, la medimos y obtuvimos un 20 %. Para celebrar, fuimos por el premio, pero cómo lo hicimos y a dónde fuimos después es una historia completamente diferente.

3. Las pruebas automáticas pueden probar los servicios web expuestos. Oracle le permite hacer esto y ya no encontraremos una serie de problemas.
4. Y, por supuesto, nuestro sistema de pruebas automatizado se puede aplicar a otro proyecto. La solución que recibimos es universal y solo requiere el uso de Oracle. Escuché que hay interés en las pruebas automatizadas en otros proyectos de Sportmaster y, tal vez, vayamos a ellos.

Hallazgos

Recapitulemos. En el proyecto del sistema de fidelización en Sportmaster, logramos implementar un sistema de pruebas automatizado. Su base es la solución utPLSQL de Stephen Feuerstein. Alrededor de utPLSQL se encuentra el código para autotests y módulos autoescritos auxiliares: un lanzador, un módulo de generación de datos y otros. Las pruebas automáticas se ejecutan a diario y, lo que es más importante, funcionan y se benefician. Estamos convencidos de que hemos comenzado a lanzar software de mayor calidad. Al mismo tiempo, la solución resultante es universal y se puede aplicar libremente a cualquier proyecto donde sea necesario organizar pruebas automatizadas en Oracle DBMS.

PD Este artículo resultó ser poco específico: hay mucho texto y prácticamente ningún ejemplo técnico. Si el tema es globalmente interesante, entonces estamos listos para continuarlo y regresar con una continuación, donde le diremos qué ha cambiado en los últimos seis meses y le daremos ejemplos de código.

Escriba comentarios si hay puntos que deben enfatizarse en el futuro o preguntas que requieren divulgación.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Escribimos más sobre esto?

• Sí, por supuesto

• No gracias

12 usuarios votaron. 4 usuarios se abstuvieron.

Fuente: habr.com