Joel Andrews é um desenvolvedor poliglota que vive na chuvosa costa oeste do Canadá. Ele desempenha várias funções na Kashoo, incluindo desenvolvedor de back-end, administrador de banco de dados, desenvolvedor de DevOps, proprietário de produto e, ocasionalmente, desenvolvedor de front-end para Web e Android. Ele tem um amor profundo e permanente por Couchbase (especialmente Couchbase Mobile), o que o torna completamente imparcial ao discutir os prós e os contras de qualquer solução de armazenamento de dados.
Em meu artigo anterior postagem no blog, apresentei síncronosuma ferramenta útil de código aberto que criamos e usamos na Kashoo para facilitar o processo de criação de funções de sincronização abrangentes para o Couchbase Gateway de sincronização. Perto do final desse post, mencionei o fato de que o synctos inclui um módulo test-helper integrado que o ajuda a escrever testes que validam suas definições de documentos. É sempre uma boa ideia testar seu código/configuração em busca de bugs, e as definições de documentos do synctos não são diferentes.
Nesta postagem, mostrarei o que é necessário para começar a escrever suas próprias especificações/casos de teste. Antes de continuar, sugiro que você leia o postagem introdutóriaSe você ainda não o fez, para garantir que tenha uma compreensão geral do que é o synctos e como ele funciona.
Primeiro, você precisará instalar Node.js para usar o synctos. Depois de instalado, você deve criar um diretório de projeto vazio com um novo arquivo chamado "package.json":
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
{ "name" (nome): "synctos-test-examples", "devDependencies": { "expect.js": "^0.3.1", "mocha": "^3.2.0", "simple-mock": "^0.7.3", "synctos": "1.x" }, "scripts": { "teste": "./generate-sync-function.sh && node_modules/.bin/mocha" } } |
Esse arquivo informa ao gerenciador de pacotes do Node.js (npm) de quais dependências o synctos e seus casos de teste precisarão: expect.js para asserções de teste, mocha para executar seus testes, e simulação simples para funções de mocking/stubbing do Sync Gateway função de sincronização API. Ele também especifica o comando "test" que executará seus testes com o mocha.
Em seguida, execute o seguinte comando na raiz do diretório do projeto para baixar os pacotes necessários para o diretório local "node_modules":
|
1 |
npm instalar |
O projeto precisará de algumas definições de documentos, portanto, crie "my-example-doc-definitions.js" no diretório raiz do projeto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
{ exemploDoc: { typeFilter: simpleTypeFilter, canais: função(doc, oldDoc) { retorno { escrever: [ 'write-' + doc._id ] } }, validadores de propriedade: { foo: { tipo: 'string', necessário: verdadeiro, regexPattern: /^[a-z]{3}$/ } } } } |
Como você pode ver, essa é uma definição de documento muito simples para fins de demonstração. Suas próprias definições de documento serão, sem dúvida, maiores e mais complexas, mas os mesmos princípios se aplicam. O arquivo define uma única propriedade do documento (uma cadeia de caracteres obrigatória chamada "foo", cujo valor deve satisfazer a expressão regular especificada), um filtro de tipo simples que determina o tipo do documento com base no conteúdo da propriedade implícita "type" (ou seja, a propriedade "type" de um documento deve ser "exampleDoc" para corresponder a esse tipo de documento) e canais de documentos que são construídos dinamicamente a partir do ID do documento.
Agora, crie um novo arquivo chamado "generate-sync-function.sh" no diretório raiz do seu projeto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
#!/bin/sh -e # Determine o diretório do script atual, para que ele possa executar comandos a partir da raiz do projeto, independentemente de onde foi executado ProjectDir="$(dirname "$0")" # É aqui que a função de sincronização gerada será criada outputDir="$projectDir/build" # É aqui que o pacote synctos foi baixado pelo npm synctosDir="$projectDir/node_modules/synctos" # Verifique se o diretório de compilação existe mkdir -p "$outputDir" # Gerar a função de sincronização a partir do arquivo de definições do documento "$synctosDir"/fazer-sincronização-função "$projectDir/my-example-doc-definitions.js" "$outputDir/my-example-sync-function.js" |
Esse arquivo será usado para gerar a função de sincronização no diretório "build" do projeto como "my-example-sync-function.js". Certifique-se de que "generate-sync-function.sh" seja executável:
|
1 |
chmod a+x gerar-sincronização-função.sh |
Neste ponto, você tem tudo o que precisa para gerar uma função de sincronização a partir do arquivo de definições do documento:
./generate-sync-function.sh
Se você procurar no diretório "build", encontrará um arquivo de função de sincronização do Sync Gateway totalmente formado chamado "my-example-sync-function.js". Se você quiser, poderá inserir o conteúdo da função de sincronização em um Sync Gateway arquivo de configuração agora. Ao fazer isso, lembre-se de colocar a função de sincronização entre aspas (`), pois ela tem mais de uma linha.
Agora é hora de validar essa função de sincronização! Crie um diretório chamado "test" na raiz do projeto e adicione um arquivo chamado "my-example-spec.js":
|
1 2 3 4 5 6 7 8 9 |
var testHelper = exigir('../node_modules/synctos/etc/test-helper.js'); var Formato de erro = testHelper.validaçãoErrorFormatter; descrever("minhas definições de documento de exemplo, função() { // Os casos de teste ficam aqui! }); |
Esse é o esqueleto do arquivo de especificação. As duas primeiras linhas do arquivo importam o módulo test-helper do synctos e o formatador de mensagens de erro, o que facilitará muito o processo de escrever casos de teste. O bloco "describe" englobará todo o código que adicionaremos em etapas posteriores.
Em seguida, adicione o seguinte trecho dentro do bloco "describe" do arquivo de especificação:
|
1 2 3 4 5 |
antes de cada(função() { testHelper.inicial('build/my-example-sync-function.js'); }); |
Esse bloco garante que o módulo auxiliar de teste seja reinicializado no início de cada caso de teste (ou seja, antes de cada caso) com o conteúdo da função de sincronização gerada.
Abaixo do bloco "beforeEach" e ainda dentro do bloco "describe", adicione o seguinte caso de teste:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
ele('deve considerar o documento válido quando todas as restrições forem atendidas', função() { var doc = { _id: 'my-document-id', tipo: 'exampleDoc', foo: 'bar' } testHelper.verifyDocumentCreated(doc, [ 'write-' + doc._id ]); }); |
Agora estamos chegando a algum lugar. Aqui definimos o documento que gostaríamos de testar e estamos afirmando que o documento pode ser criado porque atende aos critérios especificados pela definição do documento. O segundo parâmetro da função "verifyDocumentCreated" espera uma lista completa dos canais do documento que são aceitos para a opção de gravação, o que permite verificar se a lógica de atribuição de canais da definição do documento está correta.
E quanto a um documento que é inválido? Adicione outro caso de teste:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
ele('deve considerar inválido um valor de foo que não tenha três letras', função() { var doc = { _id: 'my-document-id', tipo: 'exampleDoc', foo: 'inválido' } testHelper.verifyDocumentNotCreated( doc, doc.tipo, [ Formato de erro.regexPatternItemViolation('foo', /^[a-z]{3}$/) ], [ 'write-' + doc._id ]); }); |
Como a propriedade "foo" do documento não corresponde à expressão regular que foi especificada na definição do documento, esperamos que esse documento seja rejeitado. Algumas observações sobre os argumentos da função "verifyDocumentNotCreated":
- Este é o documento que está sendo testado.
- Esse é o nome esperado do tipo de documento.
- Uma lista completa de todos os erros esperados devido à falha. Observe que o "errorFormatter" expõe funções de formatação para todos os tipos de erro suportados.
- Uma lista completa dos canais de documentos esperados que são aceitos para a operação de gravação. Como no caso de teste anterior, isso ajuda a verificar se os canais corretos são atribuídos ao documento durante a operação.
Agora que há alguns casos de teste, você pode executar o conjunto de testes executando o seguinte na raiz do projeto:
|
1 |
npm teste |
Você verá que ambos os casos de teste foram executados e aprovados (indicado por uma marca de seleção verde ao lado de cada um)! Se um caso de teste falhar, o mocha (a ferramenta de execução de testes) gerará uma mensagem de erro detalhada que deverá ajudá-lo a descobrir onde está o problema.
Então, o que vem a seguir? Há muito mais que o módulo test-helper pode fazer para ajudá-lo a escrever suas especificações. Sua próxima parada deve ser o módulo de ajuda ao teste documentação para saber quais outras opções estão disponíveis; notavelmente, você descobrirá que também pode verificar o comportamento da função de sincronização quando um documento é substituído ou excluído (útil se seus documentos ou suas propriedades forem imutáveis). O formato de mensagem de erro de validação documentação também deve ser de grande ajuda na verificação de erros que são retornados quando uma revisão de documento é rejeitada. E, finalmente, você encontrará o código-fonte completo desses exemplos em GitHub.
Feliz teste!
