{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Testes unit\u00e1rios em SGBDs \u2014 como fazemos no Sportmaster, parte dois","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A primeira parte \u2014 aqui<\/a><\/noindex>.<\/i><\/p>\n

\"Testes<\/a><\/noindex><\/p>\n

Imagine a situa\u00e7\u00e3o. Voc\u00ea tem a tarefa de desenvolver uma nova funcionalidade. Voc\u00ea possui insumos de seus antecessores. Se assumirmos que voc\u00ea n\u00e3o tem obriga\u00e7\u00f5es morais, o que voc\u00ea faria?<\/p>\n

Na maioria das vezes, todos os insumos antigos s\u00e3o esquecidos e tudo come\u00e7a do zero. Ningu\u00e9m gosta de trabalhar no c\u00f3digo de outra pessoa, e se houver tempo, por que n\u00e3o criar seu pr\u00f3prio sistema? Essa \u00e9 uma abordagem t\u00edpica e, em muitos aspectos, correta. Mas em nosso projeto, n\u00e3o fizemos assim. N\u00f3s baseamos o futuro sistema de teste autom\u00e1tico em insumos de testes unit\u00e1rios em utPLSQL de antecessores, e ent\u00e3o fomos trabalhar em v\u00e1rias dire\u00e7\u00f5es paralelas.
\n<\/a><\/noindex><\/p>\n

    \n
  1. A restaura\u00e7\u00e3o de testes unit\u00e1rios antigos.<\/b> Restaura\u00e7\u00e3o significa adaptar os testes ao estado atual do sistema de lealdade e ajustar os testes aos padr\u00f5es utPLSQL. <\/li>\n
  2. Resolvendo o problema de entendimento sobre o que exatamente, quais m\u00e9todos e processos, est\u00e3o cobertos por testes autom\u00e1ticos. <\/b>Precisamos manter essas informa\u00e7\u00f5es em mente ou tirar conclus\u00f5es com base no c\u00f3digo dos testes autom\u00e1ticos. Portanto, decidimos formar um cat\u00e1logo. A cada teste autom\u00e1tico, atribu\u00edmos um c\u00f3digo mnem\u00f4nico \u00fanico, elaboramos uma descri\u00e7\u00e3o e registramos as configura\u00e7\u00f5es (por exemplo, em quais condi\u00e7\u00f5es ele deve ser executado ou o que deve ocorrer se a execu\u00e7\u00e3o do teste falhar). Essencialmente, preenchemos os metadados dos testes autom\u00e1ticos e colocamos esses metadados em tabelas padr\u00e3o do esquema utPLSQL.<\/li>\n
  3. Defini\u00e7\u00e3o da estrat\u00e9gia de expans\u00e3o, ou seja, escolha das funcionalidades que devem ser verificadas por testes autom\u00e1ticos.<\/b> Decidimos focar em tr\u00eas aspectos: novas melhorias do sistema, incidentes da produ\u00e7\u00e3o e processos-chave do sistema. Assim, evolu\u00edmos paralelamente ao lan\u00e7amento, garantindo maior qualidade, ampliando o escopo de regress\u00e3o e assegurando a confiabilidade do sistema em pontos cr\u00edticos. O primeiro ponto cr\u00edtico foi o processo de distribui\u00e7\u00e3o de descontos e b\u00f4nus no cheque.<\/li>\n
  4. Naturalmente, come\u00e7amos a desenvolver novos testes autom\u00e1ticos. <\/b>Uma das primeiras tarefas de lan\u00e7amento foi avaliar o desempenho das amostras pr\u00e9-definidas do sistema de fidelidade. Em nosso projeto, h\u00e1 um bloco de consultas SQL fixas, que selecionam clientes com base em crit\u00e9rios. Por exemplo, obter uma lista de todos os clientes cuja \u00faltima compra foi em uma cidade espec\u00edfica, ou a lista de clientes cuja m\u00e9dia de compra \u00e9 superior a um certo valor. Ao escrever testes automatizados, verificamos as amostras pr\u00e9-definidas, registramos par\u00e2metros de desempenho de refer\u00eancia e ainda realizamos testes de carga.<\/li>\n
  5. O trabalho com testes automatizados deve ser conveniente<\/b>. As duas a\u00e7\u00f5es mais frequentes s\u00e3o: iniciar os testes automatizados e criar dados de teste. Assim, surgiram na nossa sistema dois m\u00f3dulos auxiliares: um m\u00f3dulo de execu\u00e7\u00e3o e um m\u00f3dulo de gera\u00e7\u00e3o de dados.\n

    O m\u00f3dulo de execu\u00e7\u00e3o \u00e9 apresentado como um \u00fanico procedimento universal com um par\u00e2metro de texto de entrada. Como par\u00e2metro, pode-se passar um c\u00f3digo mnem\u00f4nico do teste automatizado, o nome do pacote, o nome do teste, a configura\u00e7\u00e3o do teste automatizado ou uma palavra-chave reservada. O procedimento seleciona e executa todos os testes automatizados que atendem \u00e0s condi\u00e7\u00f5es.<\/p>\n

    O m\u00f3dulo de gera\u00e7\u00e3o de dados \u00e9 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\u00f5es s\u00e3o preenchidos ao m\u00e1ximo, garantindo a cria\u00e7\u00e3o 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.<\/li>\n

  6. Os testes automatizados devem ser executados e funcionar em um tempo aceit\u00e1vel para o seu sistema. <\/b>Portanto, foi organizado um in\u00edcio noturno di\u00e1rio, cujos resultados geram um relat\u00f3rio que \u00e9 enviado a toda a equipe de desenvolvimento por e-mail corporativo. Ap\u00f3s a restaura\u00e7\u00e3o de testes automatizados antigos e a cria\u00e7\u00e3o de novos, o tempo total de execu\u00e7\u00e3o foi de 30 minutos. Esse desempenho agradou a todos, j\u00e1 que a execu\u00e7\u00e3o ocorreu fora do hor\u00e1rio de trabalho.\n

    Mas otimizar a velocidade de opera\u00e7\u00e3o exigiu trabalho. A atualiza\u00e7\u00e3o do sistema de fidelidade em produ\u00e7\u00e3o \u00e9 realizada \u00e0 noite. Durante um dos lan\u00e7amentos, foi necess\u00e1rio fazer mudan\u00e7as urgentes \u00e0 noite. A espera de meia hora pelos resultados dos testes automatizados \u00e0s tr\u00eas da manh\u00e3 n\u00e3o deixou o respons\u00e1vel pelo lan\u00e7amento feliz (cumprimentos calorosos a Alexey Vasyukov!), e na manh\u00e3 seguinte muitas palavras gentis foram ditas sobre nosso sistema. Mas no final, foi estabelecido um padr\u00e3o de 5 minutos para a opera\u00e7\u00e3o.<\/p>\n

    Para acelerar o desempenho, usamos dois m\u00e9todos: os testes automatizados passaram a ser executados em tr\u00eas fluxos paralelos, o que \u00e9 muito conveniente devido \u00e0 arquitetura do nosso sistema de fidelidade. E abandonamos a abordagem em que o teste automatizado n\u00e3o cria dados de teste para si, mas tenta encontrar algo adequado no sistema. Ap\u00f3s as altera\u00e7\u00f5es, o tempo total de opera\u00e7\u00e3o foi reduzido para 3-4 minutos.<\/li>\n

  7. O projeto com testes automatizados precisa ser capaz de ser implantado em v\u00e1rias plataformas.<\/b> No in\u00edcio do caminho, houve tentativas de escrever nossos pr\u00f3prios scripts, mas ficou claro que uma instala\u00e7\u00e3o automatizada caseira \u00e9 um completo pesadelo, e optamos por solu\u00e7\u00f5es industriais. Como o projeto possui muito c\u00f3digo (principalmente armazenamos o c\u00f3digo dos testes automatizados) e poucos dados (os dados principais s\u00e3o metadados sobre os testes automatizados), a implementa\u00e7\u00e3o do Liquibase no projeto foi muito simples.\n

    \u00c9 uma biblioteca independente de banco de dados de c\u00f3digo aberto para rastrear, gerenciar e aplicar altera\u00e7\u00f5es no esquema do banco de dados. Gerenciada por meio da linha de comando ou de frameworks como o Apache Maven. O princ\u00edpio de funcionamento do Liquibase \u00e9 bastante simples. Temos um projeto organizado de uma maneira espec\u00edfica, que consiste em altera\u00e7\u00f5es ou scripts que devem ser aplicados ao servidor de destino, e arquivos de controle que definem em que sequ\u00eancia e com quais par\u00e2metros essas altera\u00e7\u00f5es devem ser instaladas. <\/p>\n

    No n\u00edvel do SGBD, cria-se uma tabela especial onde o Liquibase armazena um registro das altera\u00e7\u00f5es. Cada modifica\u00e7\u00e3o tem um hash calculado, que \u00e9 comparado a cada vez entre o projeto e o estado no banco de dados. Gra\u00e7as ao Liquibase, conseguimos facilmente aplicar as mudan\u00e7as do nosso sistema em qualquer ambiente. Os autotestes est\u00e3o sendo executados atualmente em ambientes de teste e release, bem como em cont\u00eaineres (ambientes pessoais dos desenvolvedores).<\/li>\n<\/ol>\n

    \"Testes
    \n
    \nEnt\u00e3o, vamos falar sobre os resultados da aplica\u00e7\u00e3o do nosso sistema de testes unit\u00e1rios. <\/p>\n

      \n
    1. Certamente, em primeiro lugar, acreditamos que come\u00e7amos a desenvolver um software de melhor qualidade. Os autotestes s\u00e3o executados diariamente e em cada release, encontrando dezenas de erros. Al\u00e9m disso, parte desses erros est\u00e1 apenas indiretamente relacionada \u00e0 funcionalidade que realmente quer\u00edamos alterar. H\u00e1 grandes d\u00favidas de que esses erros foram encontrados pela testagem manual. <\/li>\n
    2. A equipe ganhou confian\u00e7a de que uma funcionalidade espec\u00edfica est\u00e1 funcionando corretamente\u2026 Isso se aplica em primeiro lugar aos nossos processos cr\u00edticos. Por exemplo, nos \u00faltimos seis meses, n\u00e3o tivemos problemas com a distribui\u00e7\u00e3o de descontos e b\u00f4nus nos recebimentos, apesar das mudan\u00e7as em cada release, enquanto em per\u00edodos anteriores, erros surgiam com certa periodicidade.<\/li>\n
    3. Conseguimos reduzir o n\u00famero de itera\u00e7\u00f5es de teste. Gra\u00e7as ao fato de que os autotestes s\u00e3o escritos para a nova funcionalidade, os analistas e, ao mesmo tempo, testadores recebem um c\u00f3digo de qualidade superior, pois j\u00e1 foi verificado.<\/li>\n
    4. Parte do trabalho do teste automatizado \u00e9 usada pelos desenvolvedores. Por exemplo, os dados de teste em cont\u00eaineres s\u00e3o criados com a ajuda de um m\u00f3dulo de gera\u00e7\u00e3o de objetos.<\/li>\n
    5. N\u00e3o menos importante, conseguimos estabelecer a 'aceita\u00e7\u00e3o' do sistema de testes automatizados por parte dos desenvolvedores. H\u00e1 uma compreens\u00e3o de que isso \u00e9 importante e \u00fatil. E pela minha experi\u00eancia, posso dizer que isso est\u00e1 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\u00e3o valem a pena. \u00c9 muito mais f\u00e1cil ir para a produ\u00e7\u00e3o e lidar com os problemas l\u00e1. No entanto, os desenvolvedores ficam na fila e pedem para que suas funcionalidades sejam cobertas por autotestes.<\/li>\n<\/ol>\n

      O que vem a seguir<\/h2>\n

      \n\"Testes
      \n
      \nVamos falar sobre os planos de desenvolvimento do projeto de testes automatizados.<\/p>\n

      Sem d\u00favida, enquanto o sistema de fidelidade da Sportmaster estiver ativo e continuar a se desenvolver, podemos tamb\u00e9m expandir praticamente infinitamente os testes automatizados. Portanto, a principal \u00e1rea de desenvolvimento \u00e9 a amplia\u00e7\u00e3o da cobertura.<\/p>\n

      \u00c0 medida que o n\u00famero de testes automatizados aumenta, o tempo total de execu\u00e7\u00e3o tamb\u00e9m crescer\u00e1 constantemente, e teremos que retornar \u00e0 quest\u00e3o do desempenho. Provavelmente, a solu\u00e7\u00e3o estar\u00e1 no aumento do n\u00famero de threads paralelas.<\/p>\n

      Mas esses s\u00e3o caminhos evidentes de desenvolvimento. Se falarmos sobre algo mais n\u00e3o trivial, destacamos o seguinte:<\/p>\n

        \n
      1. Atualmente, o gerenciamento dos testes automatizados \u00e9 feito a n\u00edvel de SGBD, ou seja, s\u00e3o necess\u00e1rias habilidades em PL\/SQL para operar com sucesso. Se necess\u00e1rio, a administra\u00e7\u00e3o do sistema (por exemplo, execu\u00e7\u00e3o de testes ou cria\u00e7\u00e3o de metadados) pode ser realizada por meio de uma interface administrativa, utilizando Jenkins ou algo semelhante.<\/li>\n
      2. Todos adoram indicadores quantitativos e qualitativos. Para testes automatizados, um indicador universal \u00e9 a Cobertura de C\u00f3digo ou a m\u00e9trica de cobertura de c\u00f3digo. Com essa m\u00e9trica, podemos determinar qual a porcentagem do c\u00f3digo do nosso sistema de teste \u00e9 coberta pelos testes automatizados. A partir da vers\u00e3o 12.2, o Oracle oferece possibilidades para calcular essa m\u00e9trica e sugere o uso do pacote padr\u00e3o DBMS_PLSQL_CODE_COVERAGE.\n

        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\u00e3o da Sportmaster), foi assim que aconteceu. Um ano ap\u00f3s come\u00e7armos a trabalhar nos testes automatizados, a ger\u00eancia nos pediu para avaliar qual a porcentagem de c\u00f3digo que est\u00e1vamos cobrindo. Com uma cobertura superior a 1%, a ger\u00eancia ficaria feliz. N\u00f3s, desenvolvedores, esper\u00e1vamos um resultado em torno de 10%. Implementamos a cobertura de c\u00f3digo, medimos e obtivemos 20%. Entusiasmados, fomos em busca de uma recompensa, mas como conseguimos essa recompensa e para onde fomos depois, \u00e9 uma hist\u00f3ria completamente diferente.<\/li>\n

      3. Os testes automatizados podem verificar os servi\u00e7os web expostos. O Oracle permite isso de forma adequada, e n\u00e3o encontraremos mais uma s\u00e9rie de problemas. <\/li>\n
      4. E, naturalmente, nosso sistema de testes automatizados pode ser aplicado em outro projeto. A solu\u00e7\u00e3o que desenvolvemos \u00e9 universal e apenas requer o uso do Oracle. Eu ouvi que em outros projetos do Sportmaster h\u00e1 interesse em testes automatizados e, possivelmente, iremos at\u00e9 eles.<\/li>\n<\/ol>\n

        <\/p>\n

        Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n

        \nVamos resumir. No projeto do sistema de fidelidade do Sportmaster, conseguimos implementar um sistema de testes automatizados. Sua base \u00e9 a solu\u00e7\u00e3o utPLSQL de Steven Feuerstein. Ao redor da utPLSQL est\u00e1 o c\u00f3digo dos autotestes e m\u00f3dulos auxiliares desenvolvidos internamente: m\u00f3dulo de execu\u00e7\u00e3o, m\u00f3dulo de gera\u00e7\u00e3o de dados e outros. Os autotestes s\u00e3o executados diariamente e, o mais importante, funcionam e trazem benef\u00edcios. Estamos convencidos de que come\u00e7amos a lan\u00e7ar software de maior qualidade. Al\u00e9m disso, a solu\u00e7\u00e3o obtida \u00e9 universal e pode ser aplicada livremente em qualquer projeto onde seja necess\u00e1rio organizar testes automatizados em um SGBD Oracle.<\/p>\n

        P.S. Este artigo acabou n\u00e3o sendo muito espec\u00edfico: h\u00e1 muito texto e praticamente nenhuma exemplo t\u00e9cnico. Se o tema for de interesse geral, estamos prontos para continuar e retornar com uma sequ\u00eancia, onde contaremos o que mudou nos \u00faltimos seis meses e apresentaremos exemplos de c\u00f3digo.<\/p>\n

        Escreva coment\u00e1rios se houver pontos que devem ser enfatizados no futuro, ou perguntas que precisam ser esclarecidas.<\/i><\/p>\n

        Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n

        Devemos continuar escrevendo sobre isso?<\/h2>\n