Como habilitar o teste local e automático de recursos baseados na pesquisa do Atlas
Avalie esse Artigo
O Atlas Search permite que você execute consultas de texto completo em seu banco de dados MongoDB. Nesta postagem, gostaria de mostrar como você pode usar container para escrever testes de integração para queries baseadas no Atlas Search, para que você possa executá-las localmente e em seu pipeline de CI/CD sem a necessidade de se conectar a uma MongoDB Atlas.
O MongoDB Atlas Search é uma combinação poderosa de um banco de dados orientado a documentos e recursos de pesquisa de texto completo. Isso não é valioso apenas para casos de uso em que você deseja realizar consultas de texto completo em seus dados. Com o Atlas Search, é possível habilitar facilmente casos de uso que seriam difíceis de implementar no MongoDB padrão devido a certas limitações.
Algumas dessas limitações nos atingiram em um projeto recente no qual desenvolvemos uma loja virtual. O requisito bastante óbvio para esta loja incluía que os clientes deveriam ser capazes de filtrar produtos e que os filtros deveriam mostrar quantos itens estão disponíveis em cada categoria. Ao longo do projeto, continuamos aumentando o número de filtros no aplicativo. Isso gerava dois problemas:
- Queremos que os clientes possam escolher filtros arbitrariamente. Como todo filtro precisa de um índice para ser executado com eficiência e como os índices não podem ser combinados (cruzados), isso leva a uma proliferação de índices difíceis de manter (além disso, o MongoDB permite apenas índices 64, adicionando outro nível de complexidade).
- Com o aumento do número de filtros, o cálculo das facetas para indicar o número de itens disponíveis em cada categoria também fica mais complexo e caro.
Como o esforço do desenvolvedor para lidar com essa complexidade com ferramentas padrão do MongoDB aumentou com o tempo, decidimos experimentar o Atlas Search. Sabemos que o Atlas Search é um Atlas Search de texto completo incorporado no MongoDB Atlas baseado no Apache Lucene e que o Lucene é uma ferramenta poderosa para o Atlas Search de texto, mas estamos realmente surpreendentes com a forma como ele suporta o nosso caso de uso de filtragem.
Com o Atlas Search, você pode criar um ou mais dos chamados índices de pesquisa que contêm seus documentos como um todo ou apenas partes deles. Portanto, você pode usar apenas um índice para todas as suas consultas sem a necessidade de manter índices adicionais, por exemplo, para as combinações de filtros mais usadas. Além disso, você também pode usar o índice de pesquisa para calcular as facetas necessárias para mostrar a disponibilidade do item sem escrever queries complexas que não são 100% de backup por um índice.
A desvantagem dessa abordagem é que o Atlas Search dificulta a gravação de testes de unidade ou integração. Ao usar o MongoDB padrão, você encontrará facilmente alguns plug-ins para sua estrutura de teste que fornecem um MongoDB na memória para executar seus testes ou usará algum tipo de contêiner de teste para definir o cenário para seus testes. Embora as consultas do Atlas Search se integrem perfeitamente aos pipelines de agregação do MongoDB no Atlas, o MongoDB padrão não pode processar esse tipo de estágio de agregação.
Para resolver esse problema, o Atlas CLI lançado recentemente permite iniciar uma instância local de um cluster MongoDB que pode realmente lidar com queries do Atlas Search. Internamente, ele inicia dois containers e, depois de distribuir seu índice de pesquisa via CLI, você pode executar seus testes localmente nesses containers. Embora isso permita que você execute seus testes localmente, pode ser complicado configurar esse cluster local e iniciá-lo/interrompê-lo sempre que você quiser executar seus testes. Isso deve ser feito por cada desenvolvedor em sua máquina local, adiciona complexidade à integração de novas pessoas que trabalham no software e é bastante difícil de integrar em um pipeline de CI/CD.
Portanto, nos perguntamos se existe uma maneira de fornecer uma solução que não precise de uma configuração manual para esses contêineres e permita a inicialização e o desligamento automáticos. Acontece que existe uma maneira de fazer exatamente isso, e a solução que encontramos é, na verdade, bastante enxuta e reutilizável que também pode ajudar nos testes automatizados em seu projeto.
A ideia chave dos container de teste é fornecer um ambiente descartável para testes. Como o nome sugere, ele é baseado em container, então, na primeira etapa, precisamos de uma imagem Docker ou um scriptDocker Compose para começar.
Atlas CLI usa duas imagens Docker para criar um ambiente que permite testar queries do Atlas Search localmente: MongoDB/MongoDB-enterprise-server é responsável por fornecer recursos de banco de dados e MongoDB/MongoDB-atlas-search fornece recursos de pesquisa de texto completo. Ambos os containers fazem parte de um cluster MongoDB, então eles precisam se comunicar uns com os outros.
Com base nessas informações, podemos criar um docker – compose.yml, onde definimos dois containers, criamos uma rede e definimos alguns parâmetros para permitir que os containers se comuniquem entre si. O exemplo abaixo mostra o docker –compose.yml completo necessário para este artigo. O nome dos containers é baseado na convenção de nomenclatura da arquitetura do Atlas Search: o container
mongod fornece os recursos do banco de dados, enquanto o containermongot fornece os recursos de pesquisa de texto completo. Como ambos os containers precisam se conhecer, usamos variáveis de ambiente para que cada um deles saiba onde encontrar o outro. Além disso, eles precisam de um segredo compartilhado para se conectarem uns aos outros, então isso também é definido usando outra variável de ambiente.Antes de podermos usar nosso ambiente em testes, ainda precisamos criar nosso índice Atlas Search. Além disso, precisamos inicializar o conjunto de réplicas necessário, pois os dois contêineres formam um cluster. Existem várias maneiras de conseguir isso:
- Uma maneira é usar a estrutura Testcontainers para iniciar o arquivo Docker Compose e uma estrutura de teste como o jest, que permite definir métodos de configuração e desmontagem para seus testes. No método de configuração, você pode inicializar o conjunto de réplica e criar o índice do Atlas Search. Uma vantagem dessa abordagem é que você não precisa iniciar o Docker Compose manualmente antes de executar os testes.
- Outra maneira é estender o arquivo Docker Compose por um terceiro container que simplesmente executa um script para realizar a inicialização do conjunto de réplicas e a criação do índice de pesquisa.
Como a primeira solução oferece uma melhor experiência ao desenvolvedor, permitindo que os testes sejam executados com apenas um comando, sem a necessidade de iniciar o ambiente Docker manualmente, vamos nos concentrar nessa. Além disso, isso nos permite executar facilmente nossos testes em nosso pipeline de CI/CD.
O seguinte trecho de código mostra uma implementação de uma função de configuração do jest. Em um primeiro momento, ele inicia o ambiente do Docker Compose que definimos antes. Depois que os containers são iniciados, o script cria uma connection string para poder se conectar ao cluster usando um MongoClient (lembre-se do parâmetro
directConnection=true!). O MongoClient se conecta ao cluster e emite um comando admin para inicializar o conjunto de réplicas. Como esse comando leva alguns milésimos de segundo para ser concluído, o script aguarda algum tempo antes de criar o índice do Atlas Search. Depois disso, carregamos uma definição de índice do Atlas Search do sistema de arquivos e usamos createSearchIndex para criar o índice no cluster. O conteúdo do arquivo de definição do índice pode ser criado simplesmente exportando a definição da interface do usuário da Web do Atlas . As únicas informações não incluídas nesta exportação são o nome do índice. Portanto, precisamos defini-lo explicitamente (importante: o nome precisa corresponder ao nome do índice em seu código de produção!). Depois disso, fechamos a conexão do banco de dados usada pelo MongoClient e salvamos uma referência ao ambiente Docker para desmontá-la após a execução dos testes.Ao escrever testes de integração para suas queries, você precisa inserir dados no banco de dados antes de executar os testes. Normalmente, você inseriria os dados necessários no início do teste, executaria suas consultas, verificaria os resultados e teria alguma lógica de limpeza que seria executada após cada teste. Como o índice do Atlas Search está localizado em outro container (
mongot) do que os dados reais (mongod), leva algum tempo até que o nó do Atlas Search tenha processado os eventos do chamado change stream e as queries $search retornam os dados esperados. Esse fato tem um impacto na duração dos testes, como mostram os três cenários a seguir:- Inserimos nossos dados de teste em cada teste como antes. Como a inserção ou atualização de documentos não faz com que o índice de pesquisa seja atualizado imediatamente (o
mongotprecisa ouvir os eventos do fluxo de alterações e processá-los), precisaríamos esperar algum tempo após a gravação dos dados para termos certeza de que a consulta retorna os dados esperados. Ou seja, precisaríamos incluir algum tipo de chamada sleep() em cada teste. - Criamos dados de teste para cada conjunto de testes. A inserção de dados de teste uma vez por conjunto de testes usando um método beforeAll() reduz o tempo que temos de esperar para que o contêiner
mongotprocesse as atualizações. A desvantagem dessa abordagem é que temos de preparar os dados de teste de forma que sejam adequados para todos os testes desse conjunto de testes. - Criamos dados de teste globais para todos os conjuntos de testes. Usando o método de configuração global da última seção, também poderíamos inserir dados no banco de dados antes de criar o índice. Quando a criação inicial do índice for concluída, estaremos prontos para executar nossos testes sem esperar que alguns eventos do change stream sejam processados. Mas também nesse cenário, seu gerenciamento de dados de teste fica mais complexo, pois você precisa criar dados de teste adequados a todos os seus cenários de teste.
Em nosso projeto, optamos pelo segundo cenário. Consideramos que ele oferece um bom compromisso entre os requisitos de tempo de execução e a complexidade do gerenciamento de dados de teste. Além disso, achamos que esses testes são testes de integração em que não precisamos testar todos os casos. Só precisamos garantir que a query possa ser executada e retorne os dados esperados.
O conjunto de testes exemplar mostrado abaixo segue a primeira abordagem. Antes de tudo, alguns documentos são inseridos no banco de dados. Depois disso, o método é forçado a "sleep" algum tempo antes que os testes reais sejam executados.
Antes de dar uma olhada em mais detalhes nele, deixamos o Atlas Search de lado pelos motivos errados: não precisvamos de pesquisas de texto completo e achamos que não era realmente possível fazer testes nele. Depois de usá-lo por um tempo, podemos dizer genuinamente que o Atlas Search não é apenas uma ótima ferramenta para aplicativos que usam recursos baseados em pesquisa de texto completo. Ele também pode ser usado para realizar padrões de query mais tradicionais e reduzir a carga no banco de dados. Quanto à parte de teste, houve algumas grandes melhorias desde que o recurso foi lançado inicialmente e, agora, chegamos a um estado em que a capacidade de teste não é mais um problema insolúvel, embora ainda exija alguma configuração.
Com as imagens de container fornecidas pelo MongoDB e um pouco da milagrosidade do Docker introduzidas neste artigo, agora é possível executar testes de integração para essas queries localmente e também em seu pipeline de CI/CD. Experimente, se ainda não fez isso, e deixe-nos saber como funciona para você.
Você pode encontrar o código fonte completo para o exemplo descrito nesta publicação no repositório GitHub. Ainda há algum espaço para melhorias que podem ser incorporadas à configuração do teste. Futuras atualizações das ferramentas podem nos permitir escrever testes sem a necessidade de esperar algum tempo antes de podermos continuar executando nossos testes para que, um dia, todos possamos escrever alguns testes de integração do MongoDB Atlas Search sem problemas.
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.