Testes de unidade em um DBMS - como fazemos no Sportmaster, parte dois

Primeira parte - aqui.

Imagine a situação. Você se depara com a tarefa de desenvolver novas funcionalidades. Você tem desenvolvimentos de seus antecessores. Se presumirmos que você não tem obrigações morais, o que você faria?

Na maioria das vezes, todos os desenvolvimentos antigos são esquecidos e tudo começa novamente. Ninguém gosta de se aprofundar no código de outra pessoa, mas se tiver tempo, por que não começar a criar seu próprio sistema? Esta é uma abordagem típica e em grande parte correta. Mas em nosso projeto fizemos errado. Baseamos o futuro sistema de testes automáticos nos desenvolvimentos em testes unitários no utPLSQL de nossos antecessores e depois começamos a trabalhar em várias direções paralelas.

1. Restaurando testes de unidade antigos. Recuperação significa adaptar os testes ao estado existente do sistema de fidelidade e adaptar os testes aos padrões utPLSQL.
2. Resolver um problema entendendo o que exatamente, quais métodos e processos são cobertos pelos autotestes. Você deve manter essas informações em mente ou tirar conclusões com base diretamente no código do autoteste. Por isso decidimos criar um catálogo. Atribuímos um código mnemônico exclusivo a cada autoteste, criamos uma descrição e registramos configurações (por exemplo, em que condições ele deveria ser iniciado ou o que deveria acontecer se o lançamento do teste falhasse). Essencialmente, preenchemos os metadados sobre os autotestes e colocamos esses metadados em tabelas de esquema utPLSQL padrão.
3. Definir a estratégia de expansão, ou seja, seleção de funcionalidades que estão sujeitas a verificação por testes automatizados. Decidimos prestar atenção a três coisas: novas melhorias no sistema, incidentes de produção e processos-chave do sistema. Assim, estamos desenvolvendo paralelamente ao lançamento, garantindo sua maior qualidade, ampliando simultaneamente o escopo da regressão e garantindo a confiabilidade do sistema em locais críticos. O primeiro gargalo foi o processo de distribuição de descontos e bônus em cheque.
4. Naturalmente, começamos a desenvolver novos autotestes. Uma das primeiras tarefas de lançamento foi avaliar o desempenho de amostras predefinidas do sistema de fidelização. Nosso projeto possui um bloco de consultas SQL rigidamente fixas que selecionam clientes com base nas condições. Por exemplo, obtenha uma lista de todos os clientes cuja última compra foi em uma cidade específica ou uma lista de clientes cujo valor médio de compra está acima de um determinado valor. Depois de escrever autotestes, verificamos amostras predefinidas, registramos parâmetros de desempenho de benchmark e, adicionalmente, realizamos testes de carga.
5. Trabalhar com autotestes deve ser conveniente. As duas ações mais comuns são executar autotestes e criar dados de teste. Foi assim que surgiram dois módulos auxiliares em nosso sistema: um módulo de lançamento e um módulo de geração de dados.

   O iniciador é apresentado como um procedimento universal com um parâmetro de entrada de texto. Como parâmetro, você pode passar o código mnemônico do autoteste, o nome do pacote, o nome do teste, a configuração do autoteste ou uma palavra-chave reservada. O procedimento seleciona e executa todos os autotestes que atendem às condições.

   O módulo de geração de dados é apresentado na forma de um pacote no qual para cada objeto do sistema em teste (uma tabela no banco de dados) foi criado um procedimento especial que ali insere dados. Neste procedimento, os valores padrão são preenchidos ao máximo, o que garante a criação de objetos literalmente com um clique de um dedo. E para facilidade de uso, foram criados modelos para os dados gerados. Por exemplo, crie um cliente de uma certa idade com um telefone de teste e uma compra concluída.

6. Os autotestes devem ser iniciados e executados em um horário aceitável para o seu sistema. Para isso, foi organizado um lançamento noturno diário, a partir do qual é gerado um relatório de resultados e enviado a toda a equipe de desenvolvimento via correio corporativo. Após restaurar autotestes antigos e criar novos, o tempo total de operação foi de 30 minutos. Este desempenho agradou a todos, uma vez que o lançamento ocorreu fora do horário comercial.

   Mas tivemos que trabalhar para otimizar a velocidade do trabalho. O sistema de fidelidade em produção é atualizado à noite. Como parte de um dos lançamentos, tivemos que fazer alterações urgentes à noite. Esperar meia hora pelos resultados dos autotestes às três da manhã não deixou feliz o responsável pelo lançamento (saudações calorosas a Alexey Vasyukov!), e na manhã seguinte muitas palavras gentis foram ditas ao nosso sistema. Mas, como resultado, foi estabelecido um padrão de trabalho de 5 minutos.

   Para acelerar o desempenho, utilizamos dois métodos: os autotestes passaram a rodar em três threads paralelos, felizmente isso é muito conveniente devido à arquitetura do nosso sistema de fidelidade. E abandonamos a abordagem em que o autoteste não cria dados de teste para si mesmo, mas tenta encontrar algo adequado no sistema. Após fazer as alterações, o tempo total de operação foi reduzido para 3-4 minutos.

7. Um projeto com testes automáticos deverá poder ser implantado em diversos estandes. No início de nossa jornada, houve tentativas de escrever nossos próprios arquivos em lote, mas ficou claro que uma instalação automatizada escrita por nós mesmos era um horror completo, e nos voltamos para soluções industriais. Devido ao fato do projeto conter muito código direto (em primeiro lugar, armazenamos o código do autoteste) e muito poucos dados (os dados principais são metadados sobre autotestes), a implementação no projeto Liquibase acabou sendo muito simples.

   É uma biblioteca de código aberto independente de banco de dados para rastrear, gerenciar e impor alterações no esquema do banco de dados. Gerenciado por linha de comando ou estruturas como Apache Maven. O princípio de funcionamento do Liquibase é bastante simples. Temos um projeto organizado de uma determinada forma, que consiste em alterações ou scripts que precisam ser implementados no servidor de destino, e arquivos de controle que determinam em que sequência e com quais parâmetros essas alterações devem ser instaladas.

   No nível do SGBD, é criada uma tabela especial na qual o Liquibase armazena o log de rollover. Cada alteração possui um hash calculado, que é comparado a cada vez entre o projeto e o estado no banco de dados. Graças ao Liquibase, podemos implementar facilmente alterações em nosso sistema em qualquer circuito. Os autotestes agora são lançados em circuitos de teste e liberação, bem como em contêineres (circuitos pessoais dos desenvolvedores).

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

1. É claro que, em primeiro lugar, estamos convencidos de que começamos a desenvolver software melhor. Os autotestes são lançados diariamente e dezenas de erros são encontrados a cada versão. Além disso, alguns destes erros estão apenas indiretamente relacionados com a funcionalidade que realmente queríamos alterar. Há sérias dúvidas de que esses erros tenham sido encontrados por testes manuais.
2. A equipe agora tem confiança de que funcionalidades específicas estão funcionando corretamente... Em primeiro lugar, isso diz respeito 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 recibos, apesar das alterações de lançamento, embora em períodos anteriores tenham ocorrido erros com alguma frequência
3. Conseguimos reduzir o número de iterações de teste. Devido ao fato dos autotestes serem escritos para novas funcionalidades, analistas e testadores de meio período recebem código de maior qualidade, porque já foi verificado.
4. Alguns dos desenvolvimentos em testes automatizados são usados ​​por desenvolvedores. Por exemplo, os dados de teste em contêineres são criados usando o módulo de geração de objetos.
5. É importante que tenhamos desenvolvido uma “aceitação” do sistema de testes automatizados por parte dos desenvolvedores. Há um entendimento de que isso é importante e útil. Mas, por experiência própria, posso dizer que isso está longe de ser o caso. Os autotestes precisam ser escritos, precisam ser apoiados e desenvolvidos, os resultados devem 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á. Aqui, os desenvolvedores fazem fila e nos pedem para cobrir suas funcionalidades com autotestes.

Qual é o próximo

Vamos falar sobre os planos de desenvolvimento do projeto de teste automatizado.

É claro que, enquanto o sistema de fidelidade da Sportmaster estiver vivo e continuar a se desenvolver, também será possível desenvolver autotestes quase indefinidamente. Portanto, a principal direção de desenvolvimento é a expansão da área de cobertura.

À medida que o número de autotestes aumenta, seu tempo total de operação aumentará constantemente e teremos que voltar novamente à questão do desempenho. Muito provavelmente, a solução será aumentar o número de threads paralelos.

Mas estas são formas óbvias de desenvolvimento. Se falamos de algo mais não trivial, destacamos o seguinte:

1. Atualmente, o gerenciamento do autoteste é realizado no nível do SGBD, ou seja, conhecimento de PL/SQL é necessário para um trabalho bem-sucedido. Se for necessário gerenciar o sistema (por exemplo, iniciar ou criar metadados), você pode criar algum tipo de painel de administração usando Jenkins ou algo semelhante.
2. Todo mundo adora indicadores quantitativos e qualitativos. Para testes automatizados, esse indicador universal é a cobertura de código ou métrica de cobertura de código. Usando este indicador, podemos determinar qual porcentagem do código do nosso sistema em teste é coberta por autotestes. A partir da versão 12.2, o Oracle oferece a capacidade de calcular essa métrica e oferece o uso do pacote padrão DBMS_PLSQL_CODE_COVERAGE.

   Nosso sistema de autoteste tem pouco mais de um ano e talvez agora seja a hora de avaliar nossa cobertura. No meu último projeto (não um projeto Sportmaster) foi isso que aconteceu. Um ano depois de trabalhar nos autotestes, a administração definiu a tarefa de avaliar qual porcentagem do código cobrimos. Com uma cobertura superior a 1%, a administração ficaria satisfeita. Nós, os desenvolvedores, esperávamos um resultado de cerca de 10%. Instalamos a cobertura de código, medimos e obtivemos 20%. Para comemorar fomos buscar o prêmio, mas como fomos buscá-lo e para onde fomos depois é uma história completamente diferente.

3. Os autotestes podem verificar serviços da web expostos. A Oracle nos permite fazer isso muito bem e não encontraremos mais vários problemas.
4. E, claro, nosso sistema de testes automatizados pode ser aplicado a outro projeto. A solução que recebemos é universal e requer apenas o uso do Oracle. Ouvi dizer que outros projetos da Sportmaster estão interessados ​​em testes automáticos e talvez iremos até eles.

Descobertas

Vamos resumir. No projeto do sistema de fidelização da Sportmaster, conseguimos implementar um sistema de testes automatizados. É baseado na solução utPLSQL de Stephen Feuerstein. Em torno do utPLSQL existe código de autoteste e módulos auxiliares auto-escritos: módulo de lançamento, módulo de geração de dados e outros. Os autotestes são lançados diariamente e, o mais importante, funcionam e são úteis. Estamos confiantes de que começamos a lançar software de maior qualidade. Ao mesmo tempo, a solução resultante é universal e pode ser aplicada livremente a qualquer projeto onde seja necessário organizar testes automatizados no SGBD Oracle.

PS Este artigo não é muito específico: há muito texto e praticamente nenhum exemplo técnico. Se o tópico for geralmente interessante, estamos prontos para continuá-lo e voltar com uma continuação, onde contaremos o que mudou nos últimos seis meses e forneceremos exemplos de código.

Escreva comentários se houver pontos que devam ser enfatizados no futuro ou questões que exijam divulgação.

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

Vamos escrever mais sobre isso?

• Sim, claro

• Não, obrigado

12 usuários votaram. 4 usuários se abstiveram.

Fonte: habr.com