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

¡Hola, Habr!

Mi nombre es Maxim Ponomarenko y soy desarrollador en Sportmaster. Tengo 10 años de experiencia en el campo TI. Comenzó su carrera en pruebas manuales y luego pasó al desarrollo de bases de datos. Durante los últimos 4 años, acumulando los conocimientos adquiridos en pruebas y desarrollo, he estado automatizando pruebas a nivel DBMS.

Llevo poco más de un año en el equipo Sportmaster y estoy desarrollando pruebas automatizadas en uno de los proyectos más importantes. En abril, los chicos de Sportmaster Lab y yo hablamos en una conferencia en Krasnodar, mi informe se llamó "Pruebas unitarias en DBMS" y ahora quiero compartirlo con ustedes. Habrá mucho texto, así que decidí dividir el informe en dos publicaciones. En el primero hablaremos sobre las pruebas automáticas y las pruebas en general, y en el segundo, me detendré con más detalle en nuestro sistema de pruebas unitarias y los resultados de su aplicación.

Primero, una teoría un poco aburrida. ¿Qué son las pruebas automatizadas? Se trata de pruebas que se llevan a cabo mediante software y, en la TI moderna, se utilizan cada vez más en el desarrollo de software. Esto se debe al hecho de que las empresas crecen, sus sistemas de información crecen y, en consecuencia, crece la cantidad de funcionalidades que deben probarse. Realizar pruebas manuales es cada vez más caro.

Trabajé para una gran empresa cuyos lanzamientos salen cada dos meses. Al mismo tiempo, se dedicó un mes entero a que una docena de evaluadores verificaran manualmente la funcionalidad. Gracias a la implementación de la automatización por parte de un pequeño equipo de desarrolladores, pudimos reducir el tiempo de prueba a 2 semanas en un año y medio. No solo hemos aumentado la velocidad de las pruebas, sino que también hemos mejorado su calidad. Las pruebas automatizadas se lanzan periódicamente y siempre realizan todo el proceso de control incluido en ellas, es decir, excluimos el factor humano.

La TI moderna se caracteriza por el hecho de que a un desarrollador se le puede exigir no solo que escriba el código del producto, sino también que escriba pruebas unitarias que verifiquen este código.

Pero ¿qué pasa si su sistema se basa principalmente en la lógica del servidor? No existe una solución universal ni mejores prácticas en el mercado. Como regla general, las empresas resuelven este problema creando su propio sistema de pruebas escrito por ellas mismas. Este es nuestro propio sistema de prueba automatizado escrito por nosotros mismos que se creó en nuestro proyecto y hablaré de ello en mi informe.

Probando la lealtad

Primero, hablemos del proyecto en el que implementamos un sistema de prueba automatizado. Nuestro proyecto es el sistema de fidelización Sportmaster (por cierto, ya escribimos sobre él en esta publicación).

Si su empresa es lo suficientemente grande, su sistema de fidelización tendrá tres propiedades estándar:

• Su sistema estará muy cargado
• Su sistema contendrá procesos informáticos complejos
• Su sistema se mejorará activamente.

Vayamos en orden... En total, si consideramos todas las marcas Sportmaster, tenemos más de 1000 tiendas en Rusia, Ucrania, China, Kazajstán y Bielorrusia. En estas tiendas se realizan cada día unas 300 compras. Es decir, cada segundo ingresan 000-3 cheques a nuestro sistema. Naturalmente, nuestro sistema de fidelización está muy cargado. Y dado que se utiliza activamente, debemos garantizar los más altos estándares de calidad, porque cualquier error en el software significa grandes pérdidas monetarias, de reputación y de otro tipo.

Al mismo tiempo, Sportmaster organiza más de cien promociones diferentes. Hay una variedad de promociones: hay promociones de productos, las hay dedicadas al día de la semana, las hay ligadas a una tienda específica, las hay por el monto del recibo, las hay por la cantidad de mercancías. En general, no está mal. Los clientes disponen de bonificaciones y códigos promocionales que se utilizan al realizar compras. Todo esto lleva al hecho de que calcular cualquier pedido es una tarea nada trivial.

El algoritmo que implementa el procesamiento de pedidos es realmente terrible y complicado. Y cualquier cambio en este algoritmo es bastante arriesgado. Parecía que los cambios aparentemente más insignificantes podían tener efectos bastante impredecibles. Pero son precisamente estos procesos informáticos complejos, especialmente aquellos que implementan funciones críticas, los mejores candidatos para la automatización. Verificar decenas de casos similares a mano requiere mucho tiempo. Y dado que el punto de entrada al proceso no cambia, habiéndolo descrito una vez, puede crear rápidamente pruebas automáticas y estar seguro de que la funcionalidad funcionará.

Dado que nuestro sistema se utiliza activamente, la empresa querrá algo nuevo de usted, vivir con los tiempos y estar orientado al cliente. En nuestro sistema de fidelización los lanzamientos salen cada dos meses. Esto significa que cada dos meses debemos realizar una regresión completa de todo el sistema. Al mismo tiempo, naturalmente, como en cualquier TI moderna, el desarrollo no pasa inmediatamente del desarrollador a la producción. Se origina en el circuito del desarrollador, luego pasa sucesivamente por el banco de pruebas, lanzamiento, aceptación y solo entonces termina en producción. Como mínimo, en los circuitos de prueba y liberación, debemos realizar una regresión completa de todo el sistema.

Las propiedades descritas son estándar para casi cualquier sistema de fidelización. Hablemos de las características de nuestro proyecto.

Tecnológicamente, el 90% de la lógica de nuestro sistema de fidelización está basada en servidor e implementada en Oracle. Hay un cliente expuesto en Delphi, que realiza la función de administrador automatizado del lugar de trabajo. Hay servicios web expuestos para aplicaciones externas (por ejemplo, un sitio web). Por tanto, es muy lógico que si implementamos un sistema de pruebas automatizado, lo hagamos en Oracle.

El sistema de fidelización en Sportmaster existe desde hace más de 7 años y fue creado por desarrolladores individuales... El número promedio de desarrolladores en nuestro proyecto durante estos 7 años fue de 3 a 4 personas. Pero durante el año pasado, nuestro equipo creció significativamente y ahora hay 10 personas trabajando en el proyecto. Es decir, al proyecto llegan personas que no están familiarizadas con las tareas, los procesos y la arquitectura típicos. Y existe un mayor riesgo de que pasemos por alto errores.

El proyecto se caracteriza por la ausencia de evaluadores dedicados como unidades de personal. Por supuesto, existen pruebas, pero las realizan los analistas, además de sus otras responsabilidades principales: comunicarse con los clientes comerciales, usuarios, desarrollar requisitos del sistema, etc. etc... A pesar de que las pruebas se llevan a cabo con una calidad muy alta (es especialmente apropiado mencionar esto, ya que algunos de los analistas pueden llamar la atención de este informe), la efectividad de la especialización y concentración en una cosa no ha sido cancelada. .

Teniendo en cuenta todo lo anterior, para mejorar la calidad del producto entregado y reducir el tiempo de desarrollo, la idea de automatizar las pruebas en un proyecto parece muy lógica. Y en diferentes etapas de la existencia del sistema de fidelización, los desarrolladores individuales se esforzaron por cubrir su código con pruebas unitarias. En general, fue un proceso bastante inconexo, en el que cada uno utilizó su propia arquitectura y métodos. Los resultados finales fueron comunes a las pruebas unitarias: las pruebas se desarrollaron, se usaron durante algún tiempo, se almacenaron en un almacenamiento de archivos versionado, pero en algún momento dejaron de ejecutarse y fueron olvidadas. En primer lugar, esto se debió al hecho de que las pruebas estaban más vinculadas a un ejecutante específico que al proyecto.

utPLSQL viene al rescate

¿Sabes algo sobre Stephen Feuerstein?

Este es un tipo inteligente que dedicó una gran parte de su carrera a trabajar con Oracle y PL/SQL, y ha escrito una gran cantidad de trabajos sobre este tema. Uno de sus libros famosos se llama: “Oracle PL/SQL. Para profesionales." Fue Stephen quien desarrolló la solución utPLSQL o, como significa, marco de pruebas unitarias para Oracle PL/SQL. La solución utPLSQL se creó en 2016, pero se sigue trabajando activamente en ella y se lanzan nuevas versiones. En el momento de redactar este informe, la última versión data del 24 de marzo de 2019.
Qué es. Este es un proyecto de código abierto independiente. Pesa un par de megas, incluye ejemplos y documentación. Físicamente, es un esquema separado en la base de datos ORACLE con un conjunto de paquetes y tablas para organizar las pruebas unitarias. La instalación tarda unos segundos. Una característica distintiva de utPLSQL es su facilidad de uso.
Globalmente, utPLSQL es un mecanismo para ejecutar pruebas unitarias, donde una prueba unitaria se entiende como procedimientos por lotes ordinarios de Oracle, cuya organización sigue ciertas reglas. Además del lanzamiento, utPLSQL almacena un registro de todas las ejecuciones de pruebas y también tiene un sistema de informes interno.

Veamos un ejemplo de cómo se ve el código de prueba unitaria, implementado utilizando esta técnica.

Entonces, la pantalla muestra el código de una especificación de paquete típica con pruebas unitarias. ¿Cuáles son los requisitos obligatorios? El paquete debe tener el prefijo "utp_". Todos los procedimientos con pruebas deben tener exactamente el mismo prefijo. El paquete debe contener dos procedimientos estándar: “utp_setup” y “utp_teardown”. El primer procedimiento se llama reiniciando cada prueba unitaria, el segundo, después del lanzamiento.

"utp_setup", por regla general, prepara nuestro sistema para ejecutar una prueba unitaria, por ejemplo, creando datos de prueba. “utp_teardown”: por el contrario, todo vuelve a la configuración original y restablece los resultados del inicio.

A continuación se muestra un ejemplo de la prueba unitaria más simple que verifica la normalización del número de teléfono del cliente ingresado al formulario estándar de nuestro sistema de fidelización. No existen estándares obligatorios sobre cómo escribir procedimientos con pruebas unitarias. Como regla general, se realiza una llamada a un método del sistema bajo prueba y el resultado devuelto por este método se compara con el de referencia. Es importante que la comparación del resultado de referencia y el obtenido se realice mediante métodos estándar utPLSQL.

Una prueba unitaria puede tener cualquier número de comprobaciones. Como puede verse en el ejemplo, realizamos cuatro llamadas consecutivas al método probado para normalizar el número de teléfono y evaluar el resultado después de cada llamada. Al desarrollar una prueba unitaria, se debe tener en cuenta que hay comprobaciones que no afectan al sistema de ninguna manera, y después de algunas es necesario volver al estado original del sistema.
Por ejemplo, en la prueba unitaria presentada simplemente formateamos el número de teléfono ingresado, lo que no afecta el sistema de fidelización de ninguna manera.

Y si escribimos pruebas unitarias utilizando el método de creación de un nuevo cliente, después de cada prueba se creará un nuevo cliente en el sistema, lo que puede afectar el lanzamiento posterior de la prueba.

Así es como se ejecutan las pruebas unitarias. Hay dos opciones de inicio posibles: ejecutar todas las pruebas unitarias desde un paquete específico o ejecutar una prueba unitaria específica en un paquete específico.

Así es como se ve un ejemplo de un sistema de informes internos. Según los resultados de la prueba unitaria, utPLSQL genera un pequeño informe. En él vemos el resultado de cada comprobación específica y el resultado general de la prueba unitaria.

6 reglas de autopruebas

Antes de comenzar a crear un nuevo sistema de pruebas automatizadas del sistema de fidelización, junto con la dirección, determinamos los principios que deberían seguir nuestras futuras pruebas automatizadas.

1. Las pruebas automáticas deben ser efectivas y útiles. Tenemos desarrolladores maravillosos, que definitivamente necesitan ser mencionados, porque algunos de ellos probablemente verán este informe y escriben un código maravilloso. Pero incluso su maravilloso código no es perfecto y tiene, tiene y seguirá conteniendo errores. Se requieren pruebas automáticas para encontrar estos errores. Si este no es el caso, entonces o estamos escribiendo malos autotests o hemos llegado a una zona muerta que, en principio, no se está desarrollando. En ambos casos, estamos haciendo algo mal y nuestro enfoque simplemente no tiene sentido.
2. Se deben utilizar pruebas automáticas. No tiene sentido dedicar mucho tiempo y esfuerzo a escribir un producto de software, guardarlo en un repositorio y olvidarlo. Las pruebas deben realizarse con la mayor regularidad posible.
3. Las pruebas automáticas deberían funcionar de manera estable. Independientemente de la hora del día, la plataforma de lanzamiento y otras configuraciones del sistema, las pruebas deberían conducir al mismo resultado. Como regla general, esto está garantizado por el hecho de que las pruebas automáticas funcionan con datos de prueba especiales con configuraciones fijas del sistema.
4. Las pruebas automáticas deberían funcionar a una velocidad aceptable para su proyecto. Este tiempo se determina individualmente para cada sistema. Algunas personas pueden permitirse el lujo de trabajar todo el día, mientras que a otras les resulta fundamental hacerlo en segundos. Les contaré un poco más adelante qué estándares de velocidad logramos en nuestro proyecto.
5. El desarrollo de pruebas automáticas debe ser flexible. No es recomendable negarnos a probar ninguna funcionalidad simplemente porque no lo hemos hecho antes o por algún otro motivo. utPLSQL no impone ninguna restricción al desarrollo y Oracle, en principio, le permite implementar una variedad de cosas. La mayoría de los problemas tienen solución, sólo es cuestión de tiempo y esfuerzo.
6. Implementabilidad. Disponemos de varios stands donde necesitamos realizar pruebas. En cada stand se puede actualizar un volcado de datos en cualquier momento. Es necesario realizar un proyecto con pruebas automáticas de tal forma que se pueda realizar sin dolor su instalación total o parcial.

Y en el segundo post dentro de un par de días os contaré qué hicimos y qué resultados conseguimos.

Fuente: habr.com