Probas unitarias nun DBMS: como o facemos en Sportmaster, segunda parte

primeira parte - aquí.

Imaxina a situación. Enfróntase á tarefa de desenvolver novas funcionalidades. Tes novidades dos teus predecesores. Se asumimos que non tes obrigas morais, que farías?

Na maioría das veces, todos os vellos desenvolvementos son esquecidos e todo comeza de novo. A ninguén lle gusta afondar no código doutra persoa, pero se tes tempo, por que non comezas a crear o teu propio sistema? Este é un enfoque típico, e é en gran parte correcto. Pero no noso proxecto fixémolo mal. Baseamos o futuro sistema de probas automáticas nos desenvolvementos das probas unitarias en utPLSQL dos nosos predecesores, e despois pasamos a traballar en varias direccións paralelas.

1. Restauración de probas unitarias antigas. A recuperación supón adaptar as probas ao estado existente do sistema de fidelización e adaptar as probas aos estándares utPLSQL.
2. Resolver un problema entendendo que é exactamente, que métodos e procesos se cobren con autotests. Debes manter esta información na túa cabeza ou sacar conclusións baseadas directamente no código de autotest. Por iso, decidimos crear un catálogo. Asignamos un código mnemónico único a cada proba automática, creamos unha descrición e gravamos a configuración (por exemplo, en que condicións debería iniciarse ou que debería ocorrer se falla o lanzamento da proba). Esencialmente, enchemos os metadatos sobre as probas automáticas e colocamos eses metadatos en táboas de esquemas utPLSQL estándar.
3. Definición da estratexia de expansión, é dicir. selección da funcionalidade que está suxeita a verificación mediante probas automatizadas. Decidimos prestar atención a tres cousas: novas melloras do sistema, incidentes de produción e procesos clave do sistema. Así, estamos a desenvolver en paralelo ao lanzamento, garantindo a súa maior calidade, ampliando ao mesmo tempo o alcance da regresión e garantindo a fiabilidade do sistema en lugares críticos. O primeiro pescozo de botella deste tipo foi o proceso de distribución de descontos e bonificacións nun cheque.
4. Por suposto, comezamos a desenvolver novos autotests. Unha das primeiras tarefas de lanzamento foi avaliar o rendemento de mostras predefinidas do sistema de fidelización. O noso proxecto ten un bloque de consultas SQL fixadas de forma ríxida que seleccionan clientes en función das condicións. Por exemplo, obtén unha lista de todos os clientes cuxa última compra foi nunha cidade específica ou unha lista de clientes cuxo importe medio de compra supera un determinado valor. Despois de escribir autotests, comprobamos mostras predefinidas, rexistramos parámetros de rendemento de referencia e, ademais, realizamos probas de carga.
5. Traballar con autotests debería ser conveniente. As dúas accións máis comúns son realizar probas automáticas e crear datos de proba. Así apareceron no noso sistema dous módulos auxiliares: un módulo de lanzamento e un módulo de xeración de datos.

   O lanzador represéntase como un procedemento universal cun parámetro de entrada de texto. Como parámetro, pode pasar o código mnemónico da proba automática, o nome do paquete, o nome da proba, a configuración da proba automática ou unha palabra clave reservada. O procedemento selecciona e executa todas as probas automáticas que cumpran as condicións.

   O módulo de xeración de datos preséntase en forma de paquete no que para cada obxecto do sistema en proba (unha táboa na base de datos) creouse un procedemento especial que insire alí os datos. Neste procedemento, os valores predeterminados enchen o máximo posible, o que garante a creación de obxectos literalmente cun clic do dedo. E para facilitar o seu uso, creáronse modelos para os datos xerados. Por exemplo, crea un cliente dunha determinada idade cun teléfono de proba e unha compra completada.

6. As probas automáticas deberían comezar e executarse nun tempo que sexa aceptable para o seu sistema. Por iso, organizouse un lanzamento nocturno diario, a partir dos que se xera un informe dos resultados que se envía a todo o equipo de desenvolvemento a través do correo corporativo. Despois de restaurar antigas probas automáticas e crear outras novas, o tempo total de funcionamento foi de 30 minutos. Esta actuación convenía a todos, xa que o lanzamento tivo lugar fóra do horario laboral.

   Pero tivemos que traballar na optimización da velocidade de traballo. O sistema de fidelización na produción actualízase pola noite. Como parte dun dos lanzamentos, tivemos que facer cambios urxentes pola noite. Agardar durante media hora os resultados das probas automáticas ás tres da mañá non fixo feliz ao responsable do lanzamento (¡saúdos ardentes a Alexey Vasyukov!), e á mañá seguinte dixéronse moitas palabras amables cara ao noso sistema. Pero como resultado, estableceuse un estándar de 5 minutos para o traballo.

   Para acelerar o rendemento, utilizamos dous métodos: as probas automáticas comezaron a executarse en tres fíos paralelos, afortunadamente isto é moi cómodo debido á arquitectura do noso sistema de fidelización. E abandonamos o enfoque no que a proba automática non crea datos de proba por si mesma, senón que tenta atopar algo axeitado no sistema. Despois de facer os cambios, o tempo total de funcionamento reduciuse a 3-4 minutos.

7. Un proxecto con probas automáticas debería poderse despregar en varios postos. Ao comezo da nosa viaxe, houbo intentos de escribir os nosos propios ficheiros por lotes, pero quedou claro que unha instalación automatizada autoescrita era un horror completo e volvemos cara a solucións industriais. Debido a que o proxecto contén moito código directo (en primeiro lugar, almacenamos o código de autotest) e moi poucos datos (os datos principais son metadatos sobre autotests), a implementación no proxecto Liquibase resultou moi sinxela.

   É unha biblioteca de código aberto e independente da base de datos para rastrexar, xestionar e facer cumprir os cambios no esquema da base de datos. Xestionado a través da liña de comandos ou marcos como Apache Maven. O principio de funcionamento de Liquibase é bastante sinxelo. Temos un proxecto organizado dunha determinada maneira, que consiste en cambios ou scripts que hai que lanzar ao servidor de destino, e ficheiros de control que determinan en que secuencia e con que parámetros se deben instalar estes cambios.

   A nivel de DBMS, créase unha táboa especial na que Liquibase almacena o rexistro de transferencia. Cada cambio ten un hash calculado, que se compara cada vez entre o proxecto e o estado na base de datos. Grazas a Liquibase, podemos implementar facilmente cambios no noso sistema en calquera circuíto. Agora lánzanse as probas automáticas en circuítos de proba e lanzamento, así como en contedores (circuítos persoais dos desenvolvedores).

Entón, imos falar dos resultados do uso do noso sistema de probas unitarias.

1. Por suposto, en primeiro lugar, estamos convencidos de que comezamos a desenvolver un software mellor. As probas automáticas lánzanse a diario e atópanse decenas de erros en cada versión. Ademais, algúns destes erros só están indirectamente relacionados coa funcionalidade que realmente queriamos cambiar. Existen serias dúbidas de que estes erros se atoparon mediante probas manuais.
2. O equipo agora confía en que unha funcionalidade específica funciona correctamente... En primeiro lugar, isto refírese aos nosos procesos críticos. Por exemplo, nos últimos seis meses non tivemos problemas coa distribución de descontos e bonificacións nos recibos, a pesar dos cambios de lanzamento, aínda que en períodos anteriores producíronse erros con certa frecuencia.
3. Conseguimos reducir o número de iteracións de proba. Debido ao feito de que as probas automáticas están escritas para novas funcionalidades, os analistas e os probadores a tempo parcial reciben código de maior calidade, porque xa se comprobou.
4. Algúns dos desenvolvementos das probas automatizadas son utilizados polos desenvolvedores. Por exemplo, os datos de proba dos contedores créanse mediante o módulo de xeración de obxectos.
5. É importante que desenvolvemos unha "aceptación" do sistema de probas automatizadas por parte dos desenvolvedores. Hai unha comprensión de que isto é importante e útil. Pero pola miña propia experiencia podo dicir que isto está lonxe de ser así. Hai que escribir autotests, apoialos e desenvolvelos, hai que analizar os resultados e moitas veces estes custos de tempo simplemente non pagan a pena. É moito máis doado ir á produción e tratar os problemas alí. Aquí, os desenvolvedores fan fila e pídennos que cubramos a súa funcionalidade con probas automáticas.

Que hai a continuación

Falemos dos plans de desenvolvemento do proxecto de probas automatizadas.

Por suposto, mentres o sistema de fidelización de Sportmaster estea vivo e continúe desenvolvéndose, tamén é posible desenvolver autotests case infinitamente. Polo tanto, a principal dirección de desenvolvemento é ampliar a área de cobertura.

A medida que aumente o número de autotests, o seu tempo total de funcionamento aumentará de forma constante e teremos que volver á cuestión do rendemento. O máis probable é que a solución sexa aumentar o número de fíos paralelos.

Pero estas son formas obvias de desenvolvemento. Se falamos de algo máis non trivial, destacamos o seguinte:

1. Actualmente, a xestión de autotest realízase a nivel de DBMS, é dicir. Requírese coñecementos de PL/SQL para un traballo exitoso. Se é necesario, a xestión do sistema (por exemplo, o inicio ou a creación de metadatos), pode crear algún tipo de panel de administración usando Jenkins ou algo similar.
2. Todo o mundo adora os indicadores cuantitativos e cualitativos. Para as probas automatizadas, un indicador universal deste tipo é Cobertura de código ou métrica de cobertura de código. Usando este indicador, podemos determinar que porcentaxe do código do noso sistema en proba está cuberto por autotests. A partir da versión 12.2, Oracle ofrece a posibilidade de calcular esta métrica e ofrece o uso do paquete estándar DBMS_PLSQL_CODE_COVERAGE.

   O noso sistema de autotest ten pouco máis dun ano e quizais este sexa o momento de avaliar a nosa cobertura. No meu último proxecto (non un proxecto de Sportmaster) isto foi o que pasou. Un ano despois de traballar en autotests, a dirección púxose a tarefa de avaliar que porcentaxe do código cubrimos. Cunha cobertura superior ao 1%, a dirección estaría contenta. Nós, os desenvolvedores, esperabamos un resultado de preto do 10%. Instalamos a cobertura de código, mediuna e obtivemos un 20%. Para celebralo fomos buscar o premio, pero como o fomos e a onde fomos despois é unha historia completamente diferente.

3. As probas automáticas poden comprobar os servizos web expostos. Oracle permítenos facelo bastante ben e xa non atoparemos unha serie de problemas.
4. E, por suposto, o noso sistema de probas automatizadas pódese aplicar a outro proxecto. A solución que recibimos é universal e só require o uso de Oracle. Oín que outros proxectos de Sportmaster están interesados ​​en probas automáticas e quizais imos a eles.

Descubrimentos

Imos resumir. No proxecto do sistema de fidelización en Sportmaster, conseguimos implementar un sistema de probas automatizado. Está baseado na solución utPLSQL de Stephen Feuerstein. Ao redor de utPLSQL hai código de autotest e módulos auxiliares autoescritos: módulo de lanzamento, módulo de xeración de datos e outros. As probas automáticas lánzanse a diario e, o máis importante, funcionan e son útiles. Estamos seguros de que comezamos a lanzar software de maior calidade. Ao mesmo tempo, a solución resultante é universal e pódese aplicar libremente a calquera proxecto onde sexa necesario organizar probas automatizadas no DBMS Oracle.

PD Este artigo non é moi específico: hai moito texto e practicamente non hai exemplos técnicos. Se o tema é xeralmente interesante, entón estamos preparados para continuar con el e volver cunha continuación, onde lle contaremos o que cambiou nos últimos seis meses e proporcionaremos exemplos de código.

Escribe comentarios se hai puntos que deberían ser enfatizados no futuro ou preguntas que requiren divulgación.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Escribimos máis sobre isto?

• Si, claro

• Non, grazas

Votaron 12 usuarios. 4 usuarios abstivéronse.

Fonte: www.habr.com