🥇Testes unitários em SGBD — como fazemos isso no Sportmaster, parte dois

A primeira parte — aqui.

Imagine a situação. Você tem a tarefa de desenvolver uma nova funcionalidade. Você possui insumos de seus antecessores. Se assumirmos que você não tem obrigações morais, o que você faria?

Na maioria das vezes, todos os insumos antigos são esquecidos e tudo começa do zero. Ninguém gosta de trabalhar no código de outra pessoa, e se houver tempo, por que não criar seu próprio sistema? Essa é uma abordagem típica e, em muitos aspectos, correta. Mas em nosso projeto, não fizemos assim. Nós baseamos o futuro sistema de teste automático em insumos de testes unitários em utPLSQL de antecessores, e então fomos trabalhar em várias direções paralelas.

A restauração de testes unitários antigos. Restauração significa adaptar os testes ao estado atual do sistema de lealdade e ajustar os testes aos padrões utPLSQL.
Resolvendo o problema de entendimento sobre o que exatamente, quais métodos e processos, estão cobertos por testes automáticos. Precisamos manter essas informações em mente ou tirar conclusões com base no código dos testes automáticos. Portanto, decidimos formar um catálogo. A cada teste automático, atribuímos um código mnemônico único, elaboramos uma descrição e registramos as configurações (por exemplo, em quais condições ele deve ser executado ou o que deve ocorrer se a execução do teste falhar). Essencialmente, preenchemos os metadados dos testes automáticos e colocamos esses metadados em tabelas padrão do esquema utPLSQL.
Definição da estratégia de expansão, ou seja, escolha das funcionalidades que devem ser verificadas por testes automáticos. Decidimos focar em três aspectos: novas melhorias do sistema, incidentes da produção e processos-chave do sistema. Assim, evoluímos paralelamente ao lançamento, garantindo maior qualidade, ampliando o escopo de regressão e assegurando a confiabilidade do sistema em pontos críticos. O primeiro ponto crítico foi o processo de distribuição de descontos e bônus no cheque.
Naturalmente, começamos a desenvolver novos testes automáticos. Uma das primeiras tarefas de lançamento foi avaliar o desempenho das amostras pré-definidas do sistema de fidelidade. Em nosso projeto, há um bloco de consultas SQL fixas, que selecionam clientes com base em critérios. Por exemplo, obter uma lista de todos os clientes cuja última compra foi em uma cidade específica, ou a lista de clientes cuja média de compra é superior a um certo valor. Ao escrever testes automatizados, verificamos as amostras pré-definidas, registramos parâmetros de desempenho de referência e ainda realizamos testes de carga.
O trabalho com testes automatizados deve ser conveniente. As duas ações mais frequentes são: iniciar os testes automatizados e criar dados de teste. Assim, surgiram na nossa sistema dois módulos auxiliares: um módulo de execução e um módulo de geração de dados.
O módulo de execução é apresentado como um único procedimento universal com um parâmetro de texto de entrada. Como parâmetro, pode-se passar um código mnemônico do teste automatizado, o nome do pacote, o nome do teste, a configuração do teste automatizado ou uma palavra-chave reservada. O procedimento seleciona e executa todos os testes automatizados que atendem às condições.
O módulo de geração de dados é apresentado como um pacote, no qual para cada objeto do sistema testado (tabela no banco de dados), foi criada uma procedimento especial que insere dados. Nesse procedimento, os valores padrões são preenchidos ao máximo, garantindo a criação de objetos com um simples toque. E, para facilitar o uso, foram criados templates dos dados gerados. Por exemplo, criar um cliente de uma certa idade com um telefone de teste e uma compra realizada.
Os testes automatizados devem ser executados e funcionar em um tempo aceitável para o seu sistema. Portanto, foi organizado um início noturno diário, cujos resultados geram um relatório que é enviado a toda a equipe de desenvolvimento por e-mail corporativo. Após a restauração de testes automatizados antigos e a criação de novos, o tempo total de execução foi de 30 minutos. Esse desempenho agradou a todos, já que a execução ocorreu fora do horário de trabalho.
Mas otimizar a velocidade de operação exigiu trabalho. A atualização do sistema de fidelidade em produção é realizada à noite. Durante um dos lançamentos, foi necessário fazer mudanças urgentes à noite. A espera de meia hora pelos resultados dos testes automatizados às três da manhã não deixou o responsável pelo lançamento feliz (cumprimentos calorosos a Alexey Vasyukov!), e na manhã seguinte muitas palavras gentis foram ditas sobre nosso sistema. Mas no final, foi estabelecido um padrão de 5 minutos para a operação.
Para acelerar o desempenho, usamos dois métodos: os testes automatizados passaram a ser executados em três fluxos paralelos, o que é muito conveniente devido à arquitetura do nosso sistema de fidelidade. E abandonamos a abordagem em que o teste automatizado não cria dados de teste para si, mas tenta encontrar algo adequado no sistema. Após as alterações, o tempo total de operação foi reduzido para 3-4 minutos.
O projeto com testes automatizados precisa ser capaz de ser implantado em várias plataformas. No início do caminho, houve tentativas de escrever nossos próprios scripts, mas ficou claro que uma instalação automatizada caseira é um completo pesadelo, e optamos por soluções industriais. Como o projeto possui muito código (principalmente armazenamos o código dos testes automatizados) e poucos dados (os dados principais são metadados sobre os testes automatizados), a implementação do Liquibase no projeto foi muito simples.
É uma biblioteca independente de banco de dados de código aberto para rastrear, gerenciar e aplicar alterações no esquema do banco de dados. Gerenciada por meio da linha de comando ou de frameworks como o Apache Maven. O princípio de funcionamento do Liquibase é bastante simples. Temos um projeto organizado de uma maneira específica, que consiste em alterações ou scripts que devem ser aplicados ao servidor de destino, e arquivos de controle que definem em que sequência e com quais parâmetros essas alterações devem ser instaladas.
No nível do SGBD, cria-se uma tabela especial onde o Liquibase armazena um registro das alterações. Cada modificação tem um hash calculado, que é comparado a cada vez entre o projeto e o estado no banco de dados. Graças ao Liquibase, conseguimos facilmente aplicar as mudanças do nosso sistema em qualquer ambiente. Os autotestes estão sendo executados atualmente em ambientes de teste e release, bem como em contêineres (ambientes pessoais dos desenvolvedores).

Então, vamos falar sobre os resultados da aplicação do nosso sistema de testes unitários.

Certamente, em primeiro lugar, acreditamos que começamos a desenvolver um software de melhor qualidade. Os autotestes são executados diariamente e em cada release, encontrando dezenas de erros. Além disso, parte desses erros está apenas indiretamente relacionada à funcionalidade que realmente queríamos alterar. Há grandes dúvidas de que esses erros foram encontrados pela testagem manual.
A equipe ganhou confiança de que uma funcionalidade específica está funcionando corretamente… Isso se aplica em primeiro lugar aos nossos processos críticos. Por exemplo, nos últimos seis meses, não tivemos problemas com a distribuição de descontos e bônus nos recebimentos, apesar das mudanças em cada release, enquanto em períodos anteriores, erros surgiam com certa periodicidade.
Conseguimos reduzir o número de iterações de teste. Graças ao fato de que os autotestes são escritos para a nova funcionalidade, os analistas e, ao mesmo tempo, testadores recebem um código de qualidade superior, pois já foi verificado.
Parte do trabalho do teste automatizado é usada pelos desenvolvedores. Por exemplo, os dados de teste em contêineres são criados com a ajuda de um módulo de geração de objetos.
Não menos importante, conseguimos estabelecer a 'aceitação' do sistema de testes automatizados por parte dos desenvolvedores. Há uma compreensão de que isso é importante e útil. E pela minha experiência, posso dizer que isso está longe de ser verdade. Os autotestes precisam ser escritos, mantidos e desenvolvidos, os resultados precisam ser analisados, e muitas vezes, esses custos de tempo simplesmente não valem a pena. É muito mais fácil ir para a produção e lidar com os problemas lá. No entanto, os desenvolvedores ficam na fila e pedem para que suas funcionalidades sejam cobertas por autotestes.

O que vem a seguir

Vamos falar sobre os planos de desenvolvimento do projeto de testes automatizados.

Sem dúvida, enquanto o sistema de fidelidade da Sportmaster estiver ativo e continuar a se desenvolver, podemos também expandir praticamente infinitamente os testes automatizados. Portanto, a principal área de desenvolvimento é a ampliação da cobertura.

À medida que o número de testes automatizados aumenta, o tempo total de execução também crescerá constantemente, e teremos que retornar à questão do desempenho. Provavelmente, a solução estará no aumento do número de threads paralelas.

Mas esses são caminhos evidentes de desenvolvimento. Se falarmos sobre algo mais não trivial, destacamos o seguinte:

Atualmente, o gerenciamento dos testes automatizados é feito a nível de SGBD, ou seja, são necessárias habilidades em PL/SQL para operar com sucesso. Se necessário, a administração do sistema (por exemplo, execução de testes ou criação de metadados) pode ser realizada por meio de uma interface administrativa, utilizando Jenkins ou algo semelhante.
Todos adoram indicadores quantitativos e qualitativos. Para testes automatizados, um indicador universal é a Cobertura de Código ou a métrica de cobertura de código. Com essa métrica, podemos determinar qual a porcentagem do código do nosso sistema de teste é coberta pelos testes automatizados. A partir da versão 12.2, o Oracle oferece possibilidades para calcular essa métrica e sugere o uso do pacote padrão DBMS_PLSQL_CODE_COVERAGE.
O nosso sistema de testes automatizados tem pouco mais de um ano e, talvez, agora seja o momento certo para avaliar a cobertura. No meu projeto anterior (não da Sportmaster), foi assim que aconteceu. Um ano após começarmos a trabalhar nos testes automatizados, a gerência nos pediu para avaliar qual a porcentagem de código que estávamos cobrindo. Com uma cobertura superior a 1%, a gerência ficaria feliz. Nós, desenvolvedores, esperávamos um resultado em torno de 10%. Implementamos a cobertura de código, medimos e obtivemos 20%. Entusiasmados, fomos em busca de uma recompensa, mas como conseguimos essa recompensa e para onde fomos depois, é uma história completamente diferente.
Os testes automatizados podem verificar os serviços web expostos. O Oracle permite isso de forma adequada, e não encontraremos mais uma série de problemas.
E, naturalmente, nosso sistema de testes automatizados pode ser aplicado em outro projeto. A solução que desenvolvemos é universal e apenas requer o uso do Oracle. Eu ouvi que em outros projetos do Sportmaster há interesse em testes automatizados e, possivelmente, iremos até eles.

Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.

Vamos resumir. No projeto do sistema de fidelidade do Sportmaster, conseguimos implementar um sistema de testes automatizados. Sua base é a solução utPLSQL de Steven Feuerstein. Ao redor da utPLSQL está o código dos autotestes e módulos auxiliares desenvolvidos internamente: módulo de execução, módulo de geração de dados e outros. Os autotestes são executados diariamente e, o mais importante, funcionam e trazem benefícios. Estamos convencidos de que começamos a lançar software de maior qualidade. Além disso, a solução obtida é universal e pode ser aplicada livremente em qualquer projeto onde seja necessário organizar testes automatizados em um SGBD Oracle.

P.S. Este artigo acabou não sendo muito específico: há muito texto e praticamente nenhuma exemplo técnico. Se o tema for de interesse geral, estamos prontos para continuar e retornar com uma sequência, onde contaremos o que mudou nos últimos seis meses e apresentaremos exemplos de código.

Escreva comentários se houver pontos que devem ser enfatizados no futuro, ou perguntas que precisam ser esclarecidas.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.