\nFinal

Este capítulo encerra o livro. Agora você deve possuir o conhecimento e as ferramentas necessárias para começar a construir suas próprias APIs escaláveis com Node.js seguindo os melhores padrões de qualidade.\nVamos continuar essa conversa no youtube, onde vou seguir publicando conteúdo atualizado.

Obrigado pela jornada!

",{"_428":429,"_38":39,"_42":43,"_40":41,"_61":62,"_430":431,"_531":426},"previewContent","

Sumário

\n Introdução\n
\n Sobre o autor\n
\n Agradecimentos\n
\n Introdução ao Node.js\n
- \n O Google V8\n
- \n Entendendo o Node.js single thread\n
- \n I/O assíncrono não bloqueante\n
- \n Event Loop\n
- \n Call Stack\n
- \n Multithreading\n
- \n Task Queue\n
- \n Micro e Macro Tasks\n
\n
\n Configuração do ambiente de desenvolvimento\n
- \n O que é um transpiler\n
- \n Gerenciamento de projeto e dependências\n
\n
\n Iniciando o projeto\n
- \n Configuração inicial\n
- \n Configurando suporte ao Ecmascript 6\n
- \n Configurando o servidor web\n
- \n Entendendo o Middleware pattern\n
- \n Middlewares no Express\n
\n
\n Desenvolvimento guiado por testes\n
- \n TDD - Test Driven Development\n
- \n Os ciclos do TDD\n
- \n A pirâmide de testes\n
- \n Os tipos de testes\n
- \n Test Doubles\n
- \n O ambiente de testes em javascript\n
\n
\n Configurando testes de integração\n
- \n Instalando Mocha, Chai e Supertest\n
- \n Separando execução de configuração\n
- \n Configurando os testes\n
- \n Criando o primeiro caso de teste\n
- \n Executando os testes\n
- \n Fazendo os testes passarem\n
\n
\n Estrutura de diretórios e arquivos\n
- \n O diretório raiz\n
- \n O que fica no diretório raiz?\n
- \n Dentro do diretório source\n
- \n Responsabilidades diferentes dentro de um mesmo source\n
- \n Server e Client no mesmo repositório\n
- \n Separação por funcionalidade\n
- \n Conversão de nomes\n
\n
\n Rotas com o express router\n
- \n Separando as rotas\n
- \n Rotas por recurso\n
- \n Router paths\n
- \n Executando os testes\n
\n
\n Controllers\n
- \n Configurando os testes de unidade\n
- \n Testando o controller unitariamente\n
- \n Mocks, Stubs e Spies com Sinon.js\n
- \n Integrando controllers e rotas\n
\n
\n Configurando o MongoDB como banco de dados\n
- \n Introdução ao MongoDB\n
- \n Configurando o banco de dados com Mongoose\n
- \n Integrando o Mongoose com a aplicação\n
- \n Alterando a inicilização\n
\n
\n O padrão MVC\n
- \n Voltando ao tempo do Smalltalk\n
- \n MVC no javascript\n
- \n Models\n
- \n Views\n
- \n Controllers\n
- \n As vantagens de utilizar MVC\n
- \n MVC em API\n
\n
\n Models\n
- \n Criando o model com Mongoose\n
- \n Singleton Design Pattern\n
- \n Integrando models e controllers\n
- \n Atualizando o controller para utilizar o model\n
- \n Testando casos de erro\n
\n
\n O passo Refactor do TDD\n
- \n Integração entre rota, controller e model\n
\n
\n Behaviour Driven Development - BDD\n
- \n Como o BDD funciona\n
- \n O outside-in\n
- \n BDD com Mocha e Chai\n
\n
\n Operações de CRUD\n
- \n Busca por id\n
- \n Criando um recurso\n
- \n Atualizando um recurso\n
- \n Deletando um recurso\n
\n
\n Configuração por ambiente\n
- \n Alterando a arquitetura\n
- \n Configurações por ambiente\n
- \n Utilizando o módulo node-config\n
\n
\n Usuários e autenticação\n
- \n Encriptando senhas com Bcrypt\n
- \n Middlewares no Mongoose\n
\n
\n Autenticação e controle de acesso com Access Control List - ACL\n
- \n Express ACL\n
- \n Autenticação com JSON Web Token\n
- \n Criando Middlewares\n
\n
\n Estilo de código e formatação\n
- \n Eslint\n
- \n Prettier\n
- \n Configuração\n
\n
\n Final\n

\nIntrodução

\n\n

Javascript é uma das linguagens atuais mais populares entre os desenvolvedores (segundo o Stack Overflow Survey de 2017). Sorte de quem pode trabalhar com Javascript ou está entrando em um projeto onde terá a oportunidade de aprender essa linguagem. \nJavascript é dona de uma fatia ainda única no mercado, pois é uma linguagem criada para browsers, para atualizar conteúdo dinamicamente, para ser não bloqueante, permitindo que ações sejam realizadas enquanto outras ainda estão sendo processadas.\nO contexto dos browsers contribuiu para que Javascript evoluísse de uma forma diferente das demais linguagens, focando em performance e em possibilitar a criação de interfaces com uma melhor experiência para o usuário.

\n\n

Conforme os browsers evoluem, o javascript também precisa evoluir. Uma prova desse processo de crescimento foi a criação do AJAX. Um dos pioneiros nesse paradigma foi o Google, com o intuito de melhorar a experiência de uso do Gmail e evitar que a cada email aberto gerasse uma nova atualização da página; esse tipo de cenário propiciou o começo dos trabalhos para habilitar chamadas HTTP a partir do javascript e assim evitar a necessidade de atualizar a página para receber conteúdo de um servidor e mostrar na tela. Em 18 de Fevereiro de 2005 Jesse James Garrett publicou o artigo Ajax new approach web applications disseminando o termo AJAX a comunidade, termo esse que revolucionou a maneira de comunicar com servidores até então conhecida.

\n\n

Com o surgimento da “nuvem”, as aplicações precisavam se tornar escaláveis. A arquitetura de software teve que se atualizar, as aplicações precisavam tirar o maior proveito de uma única máquina e utilizar o mínimo de recurso possível. Quando surge a necessidade de aumentar recursos, ao invés de fazer upgrade em uma máquina física, uma nova máquina virtual com uma nova instância da aplicação seria inicializada, permitindo a divisão da carga e dando origem a termos como micro-serviços. Nessa mesma época, Javascript chegou ao server side com o aparecimento do Node.js, novamente revolucionando a maneira de desenvolver software.

\n\n

O Node.js trouxe todo o poder de Javascript para o server side, tornando-se o principal aliado de grandes empresas como Uber e Netflix, as quais lidam com milhares de requisições diariamente. A característica de trabalhar de forma assíncrona e ser guiado por eventos possibilitou a criação de aplicações que precisam de conexão em tempo real.

\n\n

A comunidade Javascript é vasta e muito colaborativa, diariamente circulam centenas de novas bibliotecas e frameworks, tanto para front-end quando para back-end. Esse dinamismo confunde os desenvolvedores Node.js, pois diferente de outras linguagens consolidadas no server-side como Java, que possui frameworks como SpringMVC para desenvolvimento web e Ruby, com o framework Ruby on Rails, o Node.js possui uma gama gigantesca de frameworks web e a maioria deles não mantém uma convenção.\nA falta de convenções estabelecidas dificulta o caminho dos novos desenvolvedores, pois cada projeto possui uma arquitetura única o que torna complexa a escolha de um padrão e a comparação das vantagens de cada um. Além disso, Javascript e Node.js não possuem uma bateria de ferramentas de teste completa como os pacotes xUnit, comuns em outras linguagens. Cada projeto possui a sua combinação de ferramentas de testes para os mais determinados cenários, o que contribui com a confusão quando se está começando.

\n\n

Esse livro tem como objetivo ajudar você a criar aplicações em Node.js utilizando os padrões mais reconhecidos da comunidade e seguindo os mais atuais padrões de qualidade para o desenvolvimento de software.

\n\n

O livro guiará você para entender:

\n\n

Qual o diferencial do Node.js quando comparado a outras linguagens
Como desenvolver aplicações com Node.js utilizando as últimas funcionalidades do Ecmascript
Como construir aplicações modularizadas e desacopladas
Como integrar com banco de dados NoSQL utilizando MongoDB
Como desenvolver guiado por testes com TDD
Por que testes facilitam o desenvolvimento
Como testar aplicações em Javascript
Como desenhar APIs seguindo o padrão REST
Como prover autenticação e segurança de APIs

\n\n

Para que seja possível reproduzir cenários comuns do dia a dia do desenvolvimento, será criada no decorrer do livro, uma API que servirá como guia para a introdução dos mais diferentes tópicos. A API terá o domínio de uma loja virtual, pois é um caso no qual é possível cobrir os mais diversos cenários do desenvolvimento de aplicações com Node.js.\nTodo o desenvolvimento será guiado por testes, seguindo o padrão conhecido como TDD (Test Driven Development), introduzindo as mais diferentes e complexas necessidades de testes.

\n\n

No final desse livro você terá desenvolvido uma aplicação resiliente, seguindo as melhores práticas do desenvolvimento de software e com cobertura de testes. Você estará pronto para desenvolver aplicações utilizando Node.js e seguindo os princípios do TDD.

\n\n\n

\nSobre o autor

\n\n

Waldemar Neto é engenheiro de software, contribuidor open-source, palestrante e criador de conteúdo. Começou sua carreira desenvolvendo servidores open source de MMRPGs em meados de 2004 e hoje possui mais de 15 anos de experiência na área de desenvolvimento.\nPassou por outras grandes empresas como Thoughtworks e POSSIBLE e atualmente é engenheiro de software na Atlassian (Sydney/Austrália).

\n\n

Waldemar é apaixonado por metodologias ágeis e em seu tempo livre busca contribuir para a comunidade, principalmente criando conteúdo relacionado a microsserviços, apis e qualidade de software.

\n\n

\nAgradecimentos

\n\n

Quando comecei esse livro em 2017 minha ideia era criar um conteúdo único que trouxesse de forma simples e contínua conhecimento sobre Node.js, APIs e qualidade de software, algo que eu mesmo sentia muita falta na comunidade.

\n\n

Logo nos primeiros capítulos publicados comecei a receber um ótimo feedback dos leitores, fiquei muito grato em saber que estava focando na coisa certa. Durante os 3 anos que o livro estava em desenvolvimento eu venho recebendo contribuições e feedback constante o que me ajudou a finalizar esse projeto.

\n\n

Sou muito grato a comunidade brasileira do NodeBR e a os amigos e parentes que me ajudaram nessa trajetória. Um agradecimento especial aos meus ex colegas de Thoughtworks Rafael Gomes (Gomex), Glauco Vinicius, Lucas Lago, Juraci Vieira, William Calderipe, Mateus Tait e principalmente a minha namorada Andressa Costa pelas constantes revisões.

\n\n\n

\nIntrodução ao Node.js

\n\n

Node.js não é uma linguagem de programação, tampouco um framework. A definição mais apropriada seria: um ambiente de runtime para Javascript que roda em cima de uma engine conhecida como Google v8.\nO Node.js nasceu de uma ideia do Ryan Dahl que buscava uma solução para o problema de acompanhar o progresso de upload de arquivos sem ter a necessidade de fazer pooling no servidor. Em 2009 na JSConf EU ele apresentou o Node.js e introduziu o Javascript server-side com I/O não bloqueante, ganhando assim o interesse da comunidade que começou a contribuir com o projeto desde a versão 0.x.

\n\n

A primeira versão do NPM (Node Package Manager), o gerenciador de pacotes oficial do Node.js, foi lançada em 2011 permitindo aos desenvolvedores a criação e publicação de suas próprias bibliotecas e ferramentas. O NPM é tão importante quanto o próprio Node.js e desempenha um fator chave para o sucesso do mesmo.

\n\n

Nessa época não era fácil usar o Node. A frequência com que breaking changes eram incorporadas quase impossibilitava a manutenção dos projetos. O cenário se estabilizou com o lançamento da versão 0.8, que se manteve com baixo número de breaking changes.\nMesmo com a frequência alta de atualizações, a comunidade se manteve ativa. Frameworks como Express e Socket.IO já estavam em desenvolvimento desde 2010 e acompanharam, lado a lado, as versões da tecnologia.

\n\n

O crescimento do Node.js foi rápido e teve altos e baixos, como a saída do Ryan Dahl em 2012 e a separação dos core committers do Node.js em 2014, causada pela discordância dos mesmos com a forma como a Joyent (empresa na qual Ryan trabalhava antes de sair do projeto) administrava o projeto. Os core committers decidiram fazer um fork do projeto e chamá-lo de IO.js com a intenção de prover releases mais rápidas e acompanhar as melhorias do Google V8.

\n\n

Essa separação trouxe dor de cabeça para a comunidade, que não sabia qual dos dois projetos deveria usar. Então, Joyent e outras grandes empresas como IBM, Paypal e Microsoft se uniram para ajudar a comunidade Node.js, criando a Node.js Foundation. A [Node.js Foundation] tem como missão a administração transparente e o encorajamento da participação da comunidade. Com isso, os projetos Node.js e IO.js se fundiram e foi lançada a primeira versão estável do Node.js, a versão 4.0.

\n\n

\nO Google V8

\n\n

O V8 é uma engine (motor) criada pela Google para ser usada no browser chrome. Em 2008 a Google tornou o V8 open source e passou a chamá-lo de Chromium project. Essa mudança possibilitou que a comunidade entendesse a engine em sí, além de compreender como o javascript é interpretado e compilado pela mesma.

\n\n

O javascript é uma linguagem interpretada, o que o coloca em desvantagem quando comparado com linguagens compiladas, pois cada linha de código precisa ser interpretada enquanto o código é executado. O V8 compila o código para linguagem de máquina, além de otimizar drasticamente a execução usando heurísticas, permitindo que a execução seja feita em cima do código compilado e não interpretado.

\n\n

\nEntendendo o Node.js single thread

\n\n

A primeira vista o modelo single thread parece não fazer sentido, qual seria a vantagem de limitar a execução da aplicação em somente uma thread? Linguagens como Java, PHP e Ruby seguem um modelo onde cada nova requisição roda em uma thread separada do sistema operacional. Esse modelo é eficiente mas tem um custo de recursos muito alto, nem sempre é necessário todo o recurso computacional aplicado para executar uma nova thread. \nO Node.js foi criado para solucionar esse problema, usar programação assíncrona e recursos compartilhados para tirar maior proveito de uma thread.

\n\n

O cenário mais comum é um servidor web que recebe milhões de requisições por segundo; Se o servidor iniciar uma nova thread para cada requisição vai gerar um alto custo de recursos e cada vez mais será necessário adicionar novos servidores para suportar a demanda. O modelo assíncrono single thread consegue processar mais requisições concorrentes do que o exemplo anterior, com um número bem menor de recursos.

\n\n

Ser single thread não significa que o Node.js não usa threads internamente, para entender mais sobre essa parte devemos primeiro entender o conceito de I/O assíncrono não bloqueante.

\n\n

\nI/O assíncrono não bloqueante

\n\n

Trabalhar de forma não bloqueante facilita a execução paralela e o aproveitamento de recursos, essa provavelmente é a característica mais poderosa do Node.js, \nPara entender melhor vamos pensar em um exemplo comum do dia a dia. Imagine que temos uma função que realiza várias ações, entre elas uma operação matemática, a leitura de um arquivo de disco e em seguida transforma o resultado em uma String. Em linguagens bloqueantes, como PHP e Ruby, cada ação será executada apenas depois que a ação anterior for encerrada. No exemplo citado a ação de transformar a String precisa esperar uma ação de ler um arquivo de disco, que pode ser uma operação pesada, certo?\nVamos ver um exemplo de forma síncrona, ou seja, bloqueante:

\n\n

 1 const fs = require('fs');\n 2 let fileContent;\n 3 const someMath = 1+1;\n 4 \n 5 try {\n 6   fileContent = fs.readFileSync('big-file.txt', 'utf-8');\n 7   console.log('file has been read');\n 8 } catch (err) {\n 9   console.log(err);\n10 }\n11 \n12 const text = `The sum is ${ someMath }`;\n13 \n14 console.log(text);\n

\n\n\n\n

A linha 14 do exemplo acima, com o console.log, imprimirá o resultado de 1+1 somente após a função readFileSync do módulo de file system executar, mesmo não possuindo ligação alguma com o resultado da leitura do arquivo.

\n\n

Esse é o problema que o Node.js se propôs a resolver, possibilitar que ações não dependentes entre sí sejam desbloqueadas. Para solucionar esse problema o Node.js depende de uma funcionalidade chamada high order functions. As high order functions possibilitam passar uma função por parâmetro para outra função, as funções passadas como parâmetro serão executadas posteriormente, como no exemplo a seguir:

\n\n

 1 const fs = require('fs');\n 2 \n 3 const someMath = 1+1;\n 4 \n 5 fs.readFile('big-file.txt', 'utf-8', function (err, content) {\n 6     if (err) {\n 7       return console.log(err)\n 8     }\n 9     console.log(content)\n10 });\n11 \n12 const text = `The response is ${ someMath }`;\n13 \n14 console.log(text);\n

\n\n\n\n

No exemplo acima usamos a função readFile do módulo file system, assíncrona por padrão. Para que seja possível executar alguma ação quando a função terminar de ler o arquivo é necessário passar uma função por parâmetro, essa função será chamada automaticamente quando a função readFile finalizar a leitura.\nFunções passadas por parâmetro para serem chamadas quando a ação é finalizada são chamadas de callbacks. No exemplo acima o callback recebe dois parâmetros injetados automaticamente pelo readFile: err, que em caso de erro na execução irá possibilitar o tratamento do erro dentro do callback, e content que é a resposta da leitura do arquivo.

\n\n

Para entender como o Node.js faz para ter sucesso com o modelo assíncrono é necessário entender também o Event Loop.

\n\n

\nEvent Loop

\n\n

O Node.js é uma linguagem guiada por eventos. O conceito de Event Driven é bastante aplicado em interfaces para o usuário, o javascript possui diversas APIs baseadas em eventos para interações com o DOM como por exemplo eventos como click, scroll, change são muito comuns no contexto do front-end com javascript.

\n\n

Event Driven é um fluxo de controle determinado por eventos ou alterações de estado, a maioria das implementações possuem um core (núcleo) que escuta todos os eventos e chama seus respectivos callbacks quando eles são lançados (ou tem seu estado alterado), esse é o resumo do Event Loop do Node.js.

\n\n

Separadamente, a responsabilidade do Event Loop parece simples mas quando nos aprofundamos no funcionamento do Node.js notamos que o Event Loop é a peça chave para o sucesso do modelo event driven. Nos próximos tópicos vamos entender cada um dos componentes que formam o ambiente do Node.js, como funcionam e como se conectam.

\n\n

\nCall Stack

\n\n

A stack (pilha) é um conceito bem comum no mundo das linguagens de programação, frequentemente se ouve algo do tipo: “Estourou a pilha!”. No Node.js, e no javascript em geral, esse conceito não se difere muito de outras linguagens, sempre que uma função é executada ela entra na stack, que executa somente uma coisa por vez, ou seja, o código posterior ao que está rodando precisa esperar a função atual terminar de executar para seguir adiante.\nVamos ver um exemplo:

\n\n

 1 function generateBornDateFromAge(age) {\n 2   return 2016 - age;\n 3 }\n 4 \n 5 function generateUserDescription(name, surName, age) {\n 6   const fullName = `${name} ${surName}`;\n 7   const bornDate = generateBornDateFromAge(age);\n 8 \n 9   return `${fullName} is ${age} old and was born in ${bornDate}`;\n10 }\n11 \n12 generateUserDescription(\"Waldemar\", \"Neto\", 26);\n

\n\n\n\n

Para quem já é familiarizado com javascript não há nada especial acontecendo aqui. A função generateUserDescription é chamada recebendo nome, sobrenome e idade de um usuário e retorna uma sentença com as informações colhidas. A função generateUserDescription depende da função generateBornDateFromAge para calcular o ano que o usuário nasceu. Essa dependência será perfeita para entendermos como a stack funciona.

\n\n\n

\n\n\n

No momento em que a função generateUserInformation é invocada ela vai depender da função generateBornDateFromAge para descobrir o ano em que o usuário nasceu com base no parâmetro age. Quando a função generateBornDateFromAge for invocada pela função generateUserInformation ela será adicionada a stack como no exemplo a seguir:

\n\n\n

\n\n\n

Conforme a função generateUserInformation vai sendo interpretada os valores vão sendo atribuídos às respectivas variáveis dentro de seu escopo, como no exemplo anterior. Para atribuir o valor a variável bornDate foi necessário invocar a função generateBornDateFromAge que quando invocada é imediatamente adicionada a stack até que a execução termine e a resposta seja retornada.\nApós o retorno a stack ficará assim:

\n\n\n

\n\n\n

O último passo da função será concatenar as variáveis e criar uma frase, isso não irá adicionar mais nada a stack. Quando a função generateUserInformation terminar, as demais linhas serão interpretadas. No nosso exemplo o console.log será executado e vai imprimir o valor da variável userInformation.

\n\n\n

\n\n\n

Como a stack só executa uma tarefa por vez foi necessário esperar que a função anterior executasse e finalizasse, para que o console.log pudesse ser adicionado a stack.\nEntendendo o funcionamento da stack podemos concluir que funções que precisam de muito tempo para execução irão ocupar mais tempo na stack e assim impedir a chamada das próximas linhas.

\n\n

\nMultithreading

\n\n

Mas o Node.js não é single thread? Essa é a pergunta que os desenvolvedores Node.js provavelmente mais escutam. Na verdade quem é single thread é o V8. A stack que vimos no capitulo anterior faz parte do V8, ou seja, ela é single thread.\nPara que seja possível executar tarefas assíncronas o Node.js conta com diversas outras APIs, algumas delas providas pelos próprios sistemas operacionais, como é o caso de eventos de disco, sockets TCP e UDP. Quem toma conta dessa parte de I/O assíncrono, de administrar múltiplas threads e enviar notificações é a libuv.

\n\n

A libuv é uma biblioteca open source multiplataforma escrita em C, criada inicialmente para o Node.js e hoje usada por diversos outros projetos como Julia e Luvit.

\n\n

O exemplo a seguir mostra uma função assíncrona sendo executada:

\n\n\n

\n\n\n

Nesse exemplo a função readFile do módulo de file system do Node.js é executada na stack e jogada para uma thread, a stack segue executando as próximas funções enquanto a função readFile está sendo administrada pela libuv em outra thread. Quando ela terminar, o callback sera adicionado a uma fila chamada Task Queue para ser executado pela stack assim que ela estiver livre.

\n\n\n

\n\n\n

\nTask Queue

\n\n

Como vimos no capítulo anterior, algumas ações como I/O são enviadas para serem executadas em outra thread permitindo que o V8 siga trabalhando e a stack siga executando as próximas funções. Essas funções enviadas para que sejam executadas em outra thread precisam de um callback. Um callback é basicamente uma função que será executada quando a função principal terminar.\nEsses callbacks podem ter responsabilidades diversas, como por exemplo, chamar outras funções e executar alguma lógica.\nComo o V8 é single thread e só existe uma stack, os callbacks precisam esperar a sua vez de serem chamados. Enquanto esperam, os callbacks ficam em um lugar chamado task queue ou fila de tarefas. Sempre que a thread principal finalizar uma tarefa, o que significa que a stack estará vazia, uma nova tarefa é movida da task queue para a stack onde será executada.\nPara entender melhor vamos ver a imagem abaixo:

\n\n\n

\n\n\n

Esse loop, conhecido como Event Loop, é infinito e será responsável por chamar as próximas tarefas da task queue enquanto o Node.js estiver rodando.

\n\n

\nMicro e Macro Tasks

\n\n

Até aqui vimos como funciona a stack, o multithread e também como são enfileirados os callbacks na task queue. Agora vamos conhecer os tipos de tasks (tarefas) que são enfileiradas na task queue, que podem ser micro tasks ou macro tasks.

\n\n

\nMacro tasks

\n\n

Alguns exemplos conhecidos de macro tasks são: setTimeout, I/O, setInterval. Segundo a especificação do WHATWG somente uma macro task deve ser processada em um ciclo do Event Loop.

\n\n

\nMicro tasks

\n\n

Alguns exemplos conhecidos de micro tasks são as promises e o process.nextTick. As micro tasks normalmente são tarefas que devem ser executadas rapidamente após alguma ação, ou realizar algo assíncrono sem a necessidade de inserir uma nova task na task queue.\nA especificação do WHATWG diz que após o Event Loop processar a macro task da task queue todas as micro tasks disponíveis devem ser processadas e, caso elas chamem outras micro tasks, essas também devem ser resolvidas para que somente então ele chame a próxima macro task.

\n\n

O exemplo abaixo demonstra como funciona esse fluxo:

\n\n\n

\n\n\n\n

\nConfiguração do ambiente de desenvolvimento

\n\n

Durante todo o livro a versão usada do Node.js será a 6.9.1 LTS (long term support). Para que seja possível usar as funcionalidades mais atuais do javascript será necessário o Ecmascript na versão 6 ES6 (ES2015 ou javascript 2015), aqui iremos chamar de ES6.

\n\n

Como a versão do Node.js que usaremos não dá suporte inteiramente ao ES6 será necessário o uso de um transpiler que vai tornar possível a utilização de 100% das funcionalidades do ES6.

\n\n

\nO que é um transpiler

Transpilers também são conhecidos como compiladores source-to-source. Usando um transpiler é possível escrever código utilizando as funcionalidade do ES6 ou versões mais novas e transformar o código final em um código suportado pela versão do Node.js que estaremos usando, no caso a 6.x. Um dos transpilers mais conhecidos do universo javascript é o Babel.js. \nCriado em 2015 por Sebastian McKenzie, o Babel permite utilizar as últimas funcionalidades do javascript e ainda assim executar o código em browser engines que ainda não as suportam nativamente, como no caso do v8 (engine do chrome na qual o Node.js roda), pois ele traduz o código gerado para uma forma entendível.

\n\n

\nGerenciamento de projeto e dependências

A maioria das linguagens possuem um gerenciador, tanto para automatizar tarefas, build, executar testes quanto para gerenciar dependencias. O javascript possui uma variada gama de gerenciadores, como o Grunt, Gulp e Brocoli para gerenciar e automatizar tarefas e o Bower para gerenciar dependencias de projetos front-end. Para o ambiente Node.js é necessário um gerenciador que também permita a automatização de tarefas e customização de scripts.

\n\n

Nesse cenário entra o npm (Node Package Manager), criado por Isaac Z. Schlueter o npm foi adotado pelo Node.js e é instalado automaticamente junto ao Node. O npm registry armazena mais de 400,000 pacotes públicos e privados de milhares de desenvolvedores e empresas possibilitando a divisão e contribuição de pacotes entre a comunidade. \n O cliente do npm (interface de linha de comando) permite utilizar o npm para criar projetos, automatizar tarefas e gerenciar dependências.

\n\n\n

\nIniciando o projeto

\n\n

Para iniciar um projeto em Node.js a primeira coisa a fazer é inicializar o npm no diretório onde ficará a aplicação. Para isso, primeiro certifique-se de já ter instalado o Node.js e o npm em seu computador, caso ainda não os tenha vá até o site do Node.js e faça o download https://nodejs.org/en/download/. Ele irá instalar automaticamente também o npm.

\n\n

\nConfiguração inicial

Crie o diretório onde ficará sua aplicação, após isso, dentro do diretório execute o seguinte comando:

\n\n

1 $ npm init\n

\n\n\n\n

Semelhante ao git, o npm inicializará um novo projeto nesse diretório, depois de executar o comando o npm vai apresentar uma série de perguntas (não é necessário respondê-las agora, basta pressionar enter. Você poderá editar o arquivo de configuração depois) como:

\n\n

\nname, referente ao nome do projeto.
\nversion, referente a versão.
\ndescription, referente a descrição do projeto que está sendo criado.
\nentry point, arquivo que será o ponto de entrada caso o projeto seja importado por outro.
\ntest command, comando que executará os testes de aplicação.
\ngit repository, repositório git do projeto.
\nkeywords, palavras chave para ajudar outros desenvolvedores a encontrar o seu projeto no npm.
\nauthor, autor do projeto.
\nlicense referente a licença de uso do código.

\n\n

Após isso um arquivo chamado package.json será criado com o conteúdo semelhante a:

\n\n

 1 {\n 2   \"name\": \"node-book\",\n 3     \"version\": \"1.0.0\",\n 4     \"description\": \"\",\n 5     \"main\": \"index.js\",\n 6     \"scripts\": {\n 7       \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n 8     },\n 9     \"author\": \"\",\n10     \"license\": \"ISC\"\n11 }\n

\n\n\n\n

O package.json é responsável por guardar as configurações npm do nosso projeto, nele ficarão nossos scripts para executar a aplicação e os testes.

\n\n

\nConfigurando suporte ao Ecmascript 6

\n\n

Como vimos anteriormente o Babel sera responsável por nos permitir usar as funcionalidades do ES6, para isso precisamos instalar os pacotes e configurar o nosso ambiente para suportar o ES6 por padrão em nossa aplicação.\nO primeiro passo é instalar os pacotes do Babel:

\n\n

1 $ npm install --save-dev @babel/cli@^7.7.4 @babel/core@^7.7.4 @babel/node@^7.7.4\n

\n\n\n\n

Após instalar o Babel é necessário instalar o preset que será usado, no nosso caso será o ES6:

\n\n

1 $ npm install --save-dev @babel/preset-env@^7.7.4\n

\n\n\n\n

Note que sempre usamos --save-dev para instalar dependências referentes ao Babel pois ele não deve ser usado diretamente em produção, para produção vamos compilar o código, veremos isso mais adiante.

\n\n

O último passo é informar para o Babel qual preset iremos usar, para isso basta criar um arquivo no diretório raiz da nossa aplicação chamado .babelrc com as seguintes configurações:

\n\n

 1 {\n 2   \"presets\": [\n 3     [\n 4       \"@babel/preset-env\",\n 5       {\n 6         \"targets\": {\n 7           \"node\": true\n 8         }\n 9       }\n10     ]\n11   ]\n12 }\n

\n\n\n\n

Feito isso a aplicação já estará suportando 100% o ES6 e será possível utilizar as funcionalidades da versão. O env informa ao Babel pela ler o ambiente de desenvolvimento e adicionar as funcionalidades que estão faltando para a versão do Node.js que esta sendo utilizada.\nO código dessa etapa está disponivel neste link.

\n\n

\nConfigurando o servidor web

\n\n

Como iremos desenvolver uma aplicação web precisaremos de um servidor que nos ajude a trabalhar com requisições HTTP, transporte de dados, rotas e etc. Existem muitas opções no universo Node.js como o Sails.js, Hapi.js e Koa.js. Vamos optar pelo Express.js por possuir um bom tempo de atividade, muito conteúdo na comunidade e é mantido pela Node Foundation.

\n\n

O Express é um framework para desenvolvimento web para Node.js inspirado no Sinatra que é uma alternativa entre outros frameworks web para a linguagem ruby. Criado por TJ Holowaychuk o Express foi adquirido pela StrongLoop em 2014 e é administrado atualmente pela Node.js Foundation.

\n\n

Para começar será necessário instalar dois modulos: o express e o body-parser. Conforme o exemplo a seguir:

\n\n

1 $ npm install express@^4.14.0 body-parser@^1.15.2\n

\n\n\n\n

Quando uma requisição do tipo POST ou PUT é realizada, o corpo da requisição é transportado como texto. Para que seja possível transportar dados como JSON (JavaScript Object Notation) por exemplo existe o modulo body-parser que é um conjunto de middlewares para o express que analisa o corpo de uma requisição e transforma em algo definido, no nosso caso, em JSON.

\n\n

Agora vamos criar um arquivo chamado server.js no diretório raiz e nele vamos fazer a configuração básica do express:

\n\n

 1 import express from 'express';\n 2 import bodyParser from 'body-parser';\n 3 \n 4 const app = express();\n 5 app.use(bodyParser.json());\n 6 \n 7 app.get('/', (req, res) => res.send('Hello World!'));\n 8 \n 9 app.listen(3000, () => {\n10   console.log('Example app listening on port 3000!');\n11 });\n

\n\n\n\n

A primeira instrução no exemplo acima é a importação dos módulos express e body-parser que foram instalados anteriormente. Em seguida uma nova instância do express é criada e associada a constante app. Para utilizar o body-parser é necessário configurar o express para utilizar o middleware, o express possui um método chamado use onde é possível passar middlewares como parâmetro, no código acima foi passado o bodyParser.json() responsável por transformar o corpo das requisições em JSON.

\n\n

A seguir é criada uma rota, os verbos HTTP como GET, POST, PUT, DELETE são funções no express que recebem como parâmetro um padrão de rota, no caso acima /, e uma função de callback que será chamada quando a rota receber uma requisição. Os parametros req e res representam request (requisição) e response (resposta) e serão injetados automaticamente pelo express quando a requisição for recebida.\nPara finalizar, a função listen é chamada recebendo um número referente a porta na qual a aplicação ficará exposta, no nosso caso é a porta 3000.

\n\n

O último passo é configurar o package.json para iniciar nossa aplicação, para isso vamos adicionar um script de start dentro do objeto scripts:

\n\n

1   \"scripts\": {\n2     \"build\": \"babel src --out-dir dist\",\n3     \"start\": \"npm run build && node dist/server.js\",\n4     \"start:dev\": \"babel-node src/server.js\",\n5     \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n6   },\n

\n\n\n

### Build\nO Comando build utiliza o Babel para transpilar o código que foi escrito em Javascript suportado pelo ambiente, por exemplo se voce está utilizando Node na versão 12 e utilizando imports (ES6 Modules) o Babel vai transformar essa funcionalidade em algo suportado pela versão 12.\nNote que o código depois de transpilado será salvo no diretório dist. Esse código que deve ser utilizado em produção.

\n\n

\nStart

O start é indicado para utilizar em produção, ele vai executar o comando build antes e depois iniciar a aplicação a partir do código transpilado.

\n\n

\nStart dev

A diferença do start e do start:dev e que o start:dev utilizada o babel-node que transpila e inicia a aplicação ao mesmo tempo, vamo adicinar mais coisas a esse comando logo.

\n\n

Alterado o package.json basta executar o comando:

\n\n

1 $ npm start\n

\n\n\n\n

Agora a aplicação estará disponível em http://localhost:3000/.\nO código dessa etapa está disponivel neste link.

\n\n

\nEntendendo o Middleware pattern

\n\n

\n
Note esta etapa não faz parte do código da API que estamos construindo, o código é somente exemplo de implementação.
\n

\n\n

O padrão de Middleware implementado pelo express já é bem conhecido e tem sido usado por desenvolvedores em outras linguagens há muitos anos. Podemos dizer que se trata de uma implementação do padrão intercepting filter pattern do chain of responsibility.

\n\n

A implementação representa um pipeline de processamento onde handlers, units e filters são funções. Essas funções são conectadas criando uma sequência de processamento assíncrona que permite pré-processamento, processamento e pós-processamento de qualquer tipo de dado.

\n\n

Uma das principais vantagens desse pattern é a facilidade de adicionar plugins de maneira não intrusiva.

\n\n

O diagrama abaixo representa a implementação do Middleware pattern:

\n\n\n

\n\n\n

O primeiro componente que devemos observar no diagrama acima é o Middleware Manager, ele é responsável por organizar e executar as funções. Alguns dos detalhes mais importantes dessa implementação são:

\n\n

Novos middlewares podem ser invocados usando a função `use() (o nome não precisa ser estritamente use, aqui estamos usando o express como base). Geralmente novos middlewares são adicionados ao final do pipeline, mas essa não é uma regra obrigatória.\n Quando um novo dado é recebido para processamento, o middleware registrado é invocado em um fluxo de execução assíncrono. Cada unidade no pipeline recebe o resultado da anterior como input.\n Cada pedaço do middleware pode decidir parar o processamento simplesmente não chamando o callback, ou em caso de erro, passando o erro por callback. Normalmente erros disparam um fluxo diferente de processamento que é dedicado ao tratamento de erros.

\n\n

O exemplo abaixo mostra um caminho de erro:

\n\n\n

\n\n\n

No express, por exemplo, o caminho padrão espera os parâmetros request, response e next, caso receba um quarto parâmetro, que normalmente é nomeado como error, ele vai buscar um caminho diferente.

\n\n

Não há restrições de como os dados são processados ou propagados no pipeline. Algumas estratégias são:

\n\n

Incrementar os dados com propriedades ou funções.
Substituir os dados com o resultado de algum tipo de processamento.
Manter a imutabilidade dos dados sempre retornando uma cópia como resultado do processamento.

\n\n

A implementação correta depende de como o Middleware Manager é implementado e do tipo de dados que serão processados no próprio middleware. Para saber mais sobre o pattern sugiro a leitura do livro Node.js Design Patterns.

\n\n

\nMiddlewares no Express

\n\n

O exemplo a seguir mostra uma aplicação express simples, com uma rota que devolve um “Hello world” quando chamada:

\n\n

 1 const express = require('express');\n 2 \n 3 const app = express();\n 4 \n 5 app.get('/', function(req, res, next) {\n 6 \tconsole.log('route / called');\n 7   res.send('Hello World!');\n 8 });\n 9 \n10 app.listen(3000, () => {\n11 \tconsole.log('app is running');\n12 });\n

\n\n\n

Agora vamos adicionar uma mensagem no console que deve aparecer antes da mensagem da rota:

\n\n

 1 const express = require('express');\n 2 \n 3 const app = express();\n 4 \n 5 app.use((req, res, next) => {\n 6   console.log('will run before any route');\n 7   next();\n 8 });\n 9 \n10 app.get('/', function(req, res, next) {\n11 \tconsole.log('route / called');\n12   res.send('Hello World!');\n13 });\n14 \n15 app.listen(3000, () => {\n16 \tconsole.log('app is running');\n17 });\n

\n\n\n\n

Middlewares são apenas funções que recebem os parâmetros requisição (req), resposta (res) e próximo (next), executam alguma lógica e chamam o próximo middleware chamando next. No exemplo acima chamamos o use passando uma função que será o middleware, ela mostra a mensagem no console e depois chama o next().

\n\n

Se executarmos esse código e acessarmos a rota / a saída no terminal será:

\n\n

1 app is running\n2 will run before any route\n3 route / called\n

\n\n\n\n

Ok! Mas como eu sabia que iria executar antes? Como vimos anteriormente no middleware pattern, o middleware manager executa uma sequência de middlewares, então a ordem do use interfere na execução, por exemplo, se invertermos a ordem, como no código abaixo:

\n\n

 1 const express = require('express');\n 2 \n 3 const app = express();\n 4 \n 5 \n 6 app.get('/', function(req, res, next) {\n 7 \tconsole.log('route / called');\n 8   res.send('Hello World!');\n 9 });\n10 \n11 app.use((req, res, next) => {\n12 \tconsole.log('will run before any route');\n13 \tnext();\n14 });\n15 \n16 app.listen(3000, () => {\n17 \tconsole.log('app is running');\n18 });\n

\n\n\n\n

A saida será:

\n\n

1 app is running\n2 route / called\n

\n\n\n\n

Dessa vez o nosso middleware não foi chamado, isso acontece porque a rota chama a função res.send() invés de next(), ou seja, ela quebra a sequência de middlewares.

\n\n

Também é possível usar middlewares em rotas específicas, como abaixo:

\n\n

 1 const express = require('express');\n 2 \n 3 const app = express();\n 4 \n 5 app.use('/users', (req, res, next) => {\n 6 \tconsole.log('will run before users route');\n 7 \tnext();\n 8 });\n 9 \n10 app.get('/', function(req, res, next) {\n11 \tconsole.log('route / called');\n12   res.send('Hello World!');\n13 });\n14 \n15 app.get('/users', function(req, res, next) {\n16 \tconsole.log('route /users called');\n17 \tres.send('Hello World!');\n18 });\n19 \n20 app.listen(3000, () => {\n21 \tconsole.log('app is running');\n22 });\n

\n\n\n\n

Caso seja feita uma chamada para / a saída sera:

\n\n

1 app is running\n2 route / called\n

\n\n\n\n

Já para /users veremos a seguinte saída no terminal:

\n\n

1 app is running\n2 will run before users route\n3 route /users called\n

\n\n\n\n

O express também possibilita ter caminhos diferentes em caso de erro:

\n\n

 1 const express = require('express');\n 2 \n 3 const app = express();\n 4 \n 5 app.use((req, res, next) => {\n 6 \tconsole.log('will run before any route');\n 7 \tnext();\n 8 });\n 9 \n10 app.use((err, req, res, next) => {\n11 \tconsole.log('something goes wrong');\n12 \tres.status(500).send(err.message);\n13 });\n14 \n15 app.get('/', function(req, res, next) {\n16 \tconsole.log('route / called');\n17   res.send('Hello World!');\n18 });\n19 \n20 \n21 app.listen(3000, () => {\n22 \tconsole.log('app is running');\n23 });\n

\n\n\n\n

Não mudamos nada no código de exemplo, apenas adicionamos mais um middleware que recebe o parâmetro err. Executando o código teremos a seguinte saída:

\n\n

1 app is running\n2 will run before any route\n3 route / called\n

\n\n\n\n

Apenas o primeiro middleware foi chamado, o middleware de erro não. Vamos ver o que acontece quando passamos um erro para o next do primeiro middleware.

\n\n

 1 const express = require('express');\n 2 \n 3 const app = express();\n 4 \n 5 app.use((req, res, next) => {\n 6 \tconsole.log('will run before any route');\n 7 \tnext(new Error('failed!'));\n 8 });\n 9 \n10 app.use((err, req, res, next) => {\n11 \tconsole.log('something goes wrong');\n12 \tres.status(500).send(err.message);\n13 });\n14 \n15 app.get('/', function(req, res, next) {\n16 \tconsole.log('route / called');\n17   res.send('Hello World!');\n18 });\n19 \n20 \n21 app.listen(3000, () => {\n22 \tconsole.log('app is running');\n23 });\n

\n\n\n\n

A saída será:

\n\n

1 app is running\n2 will run before any route\n3 something goes wrong\n

\n\n\n\n

Essas são as formas mais comuns de utilizar middlewares, mas suas combinações são infinitas. Ao decorrer do livro utilizaremos middlewares para casos distintos.

\n\n\n

\nDesenvolvimento guiado por testes

\n\n

Agora que vamos começar a desenvolver nossa aplicação precisamos garantir que a responsabilidade, as possíveis rotas, as requisições e as respostas estão sendo atendidas; que estamos entregando o que prometemos e que está tudo funcionando. Para isso, vamos seguir um modelo conhecido como TDD (Test Driven Development ou Desenvolvimento Guiado por Testes).

\n\n

\nTDD - Test Driven Development

O TDD é um processo de desenvolvimento de software que visa o feedback rápido e a garantia de que o comportamento da aplicação está cumprindo o que é requerido. Para isso, o processo funciona em ciclos pequenos e os requerimentos são escritos como casos de teste.

\n\n

A prática do TDD aumentou depois que Kent Beck publicou o livro TDD - Test Driven Development e fomentou a discussão em torno do tema. Grandes figuras da comunidade ágil como Martin Fowler também influenciaram na adoção dessa prática publicando artigos, ministrando palestras e compartilhando cases de sucesso.

\n\n

\nOs ciclos do TDD

\n\n

Quando desenvolvemos guiados por testes, o teste acaba se tornando uma consequência do processo, ja que vai ser ele que vai determinar o comportamento esperado da implementação. Para que seja possível validar todas as etapas, o TDD se divide em ciclos que seguem um padrão conhecido como: Red, Green, Refactor.

\n\n

\nRed

\n\n

Significa escrever o teste antes da funcionalidade e executá-lo. Nesse momento, como a funcionalidade ainda não foi implementada, o teste deve quebrar. Essa fase também serve para verificar se não há erros na sintáxe e na semântica.

\n\n

\nGreen

\n\n

Refere-se a etapa em que a funcionalidade é adicionada para que o teste passe. Nesse momento ainda não é necessário ter a lógica definida mas é importante atender aos requerimentos do teste. Aqui podem ser deixados to-dos, dados estáticos, fixmes, ou seja, o suficiente para o teste passar.

\n\n

\nRefactor

\n\n

É onde se aplica a lógica necessária. Como o teste já foi validado nos passos anteriores, o refactor garantirá que a funcionalidade está sendo implementada corretamente. Nesse momento devem ser removidos os dados estáticos e todos itens adicionadas apenas para forçar o teste a passar, em seguida deve ser feita a implementação real para que o teste volte a passar.\nA imagem abaixo representa o ciclo do TDD:

\n\n\n

\n\n\n

\nA pirâmide de testes

\n\n

A pirâmide de testes é um conceito criado por Mike Cohn, escritor do livro Succeeding with Agile. O livro propõe que hajam mais testes de baixo nível, ou seja, testes de unidade, depois testes de integração e no topo os testes que envolvem interface.

\n\n\n

\n\n\n

O autor observa que os testes de interface são custosos, para alguns testes é necessário inclusive licença de softwares. Apesar de valioso, esse tipo de teste necessita da preparação de todo um ambiente para rodar e tende a ocupar muito tempo.\n O que Mike defende é ter a base do desenvolvimento com uma grande cobertura de testes de unidade; no segundo nível, garantir a integração entre os serviços e componentes com testes de integração, sem precisar envolver a interface do usuário. E no topo, possuir testes que envolvam o fluxo completo de interação com a UI, para validar todo o fluxo.

\n\n

Vale lembrar que testes de unidade e integração podem ser feitos em qualquer parte da aplicação, tanto no lado do servidor quanto no lado do cliente, isso elimina a necessidade de ter testes complexos envolvendo todo o fluxo.

\n\n

\nOs tipos de testes

\n\n

Atualmente contamos com uma variada gama de testes, sempre em crescimento de acordo com o surgimento de novas necessidades. Os mais comuns são os teste de unidade e integração, nos quais iremos focar aqui.

\n\n

\nTestes de unidade (Unit tests)

\n\n

Testes de unidade são a base da pirâmide de testes. Segundo Martin Fowler testes unitários são de baixo nível, com foco em pequenas partes do software e tendem a ser mais rapidamente executados quando comparados com outros testes, pois testam partes isoladas.

\n\n

Mas o que é uma unidade afinal? Esse conceito é divergente e pode variar de projeto, linguagem, time e paradigma de programação. Linguagens orientadas a objeto tendem a ter classes como uma unidade, já linguagens procedurais ou funcionais consideram normalmente funções como sendo uma unidade. Essa definição é algo muito relativo e depende do contexto e do acordo dos desenvolvedores envolvidos no processo. Nada impede que um grupo de classes relacionadas entre sí ou funções, sejam uma unidade.

\n\n

No fundo, o que define uma unidade é o comportamento e a facilidade de ser isolada das suas dependências (dependências podem ser classes ou funções que tenham algum tipo de interação com a unidade).\n Digamos que, por exemplo, decidimos que as nossas unidade serão as classes e estamos testando uma função da classe Billing que depende de uma função da classe Orders. A imagem abaixo ilustra a dependência:

\n\n\n

\n\n\n

Para testar unitariamente é necessário isolar a classe Billing da sua dependência, a classe Orders, como na imagem a seguir:

\n\n\n

\n\n\n

Esse isolamento pode ser feito de diversas maneiras, por exemplo utilizando mocks ou stubs ou qualquer outra técnica de substituição de dependência e comportamento. O importante é que seja possível isolar a unidade e ter o comportamento esperado da dependência.

\n\n

\nTestes de integração (Integration tests)

\n\n

Testes de integração servem para verificar se a comunicação entre os componentes de um sistema está ocorrendo conforme o esperado. Diferente dos testes de unidade, onde a unidade é isolada de duas dependências, no teste de integração deve ser testado o comportamento da interação entre as unidades. \n Não há um nível de granularidade específico, a integração pode ser testada em qualquer nível, seja a interação entre camadas, classes ou até mesmo serviços.

\n\n

No exemplo a seguir temos uma arquitetura comum de aplicações Node.js e desejamos testar a integração entre as rotas, controllers, models e banco de dados:

\n\n\n

\n\n\n

Nossa integração pode ser desde a rota até salvar no banco de dados (nesse caso, MongoDB), dessa maneira é possível validar todo o fluxo até o dado ser salvo no banco, como na imagem a seguir:

\n\n\n

\n\n\n

Esse teste é custoso porém imprescindível. Será necessário limpar o banco de dados a cada teste e criar os dados novamente, além de custar tempo e depender de um serviço externo como o MongoDB. Um grau de interação desse nível terá vários possíveis casos de teste, como por exemplo: o usuário mandou um dado errado e deve receber um erro de validação. Para esse tipo de cenário pode ser melhor diminuir a granularidade do teste para que seja possível ter mais casos de teste.\n Para um caso onde o controller chama o model passando dados inválidos e a válidação deve emitir um erro, poderíamos testar a integração entre o controller e o model, como no exemplo a seguir:

\n\n\n

\n\n\n

Nesse exemplo todos os componentes do sistema são facilmente desacopláveis, podem haver casos onde o model depende diretamente do banco de dados e como queremos apenas testar a validação não precisamos inserir nada no banco, nesse caso é possível substituir o banco de dados ou qualquer outra dependência por um mock ou stub para reproduzir o comportamento de um banco de dados sem realmente chamar o banco.

\n\n\n

\n\n\n

\nTeste de integração de contrato (Integration contract tests)

\n\n

Testes de contrato ganharam muita força devido ao crescimento das APIs e dos micro serviços. Normalmente, quando testamos a nossa aplicação, mesmo com o teste de integração, tendemos a não usar os serviços externos e sim um substituto que devolve a resposta esperada. Isso por que serviços externos podem afetar no tempo de resposta da requisição, podem cair, aumentar o custo e isso pode afetar nossos testes.\n Mas por outro lado, quando isolamos nossa aplicação dos outros serviços para testar ficamos sem garantia de que esses serviços não mudaram suas APIs e que a resposta esperada ainda é a mesma. Para solucionar esses problemas existem os testes de contrato.

\n\n

\nA definição de um contrato

\n\n

Sempre que consumimos um serviço externo dependemos de alguma parte dele ou de todos os dados que ele provém e o serviço se compromete a entregar esses dados. O exemplo abaixo mostra um teste de contrato entre a aplicação e um serviço externo, nele é verificado se o contrato entre os dois ainda se mantém o mesmo.

\n\n\n

\n\n\n

É importante notar que o contrato varia de acordo com a necessidade, nesse exemplo a nossa aplicação depende apenas dos campos email e birthday então o contrato formado entre eles verifica apenas isso. Se o name mudar ele não quebrará nossa aplicação nem o contrato que foi firmado.\n Em testes de contrato o importante é o tipo e não o valor. No exemplo verificamos se o email ainda é String e se o campo birthday ainda é do tipo Date, dessa maneira garantimos que a nossa aplicação não vai quebrar. O exemplo a seguir mostra um contrato quebrado onde o campo birthday virou born, ou seja, o serviço externo mudou o nome do campo, nesse momento o contrato deve quebrar.

\n\n\n

\n\n\n

Testes de contrato possuem diversas extensões, o caso acima é chamado de consumer contract onde o consumidor verifica o contrato e, caso o teste falhe, notifica o provider (provedor) ou altera sua aplicação para o novo contrato. Também existe o provider contracts onde o próprio provedor testa se as alterações feitas irão quebrar os consumidores.

\n\n

\nTest Doubles

\n\n

Testar código com ajax, network, timeouts, banco de dados e outras dependências que produzem efeitos colaterais é sempre complicado. Por exemplo, quando se usa ajax, ou qualquer outro tipo de networking, é necessário comunicar com um servidor que irá responder para a requisição; já com o banco de dados será necessário inicializar um serviço para tornar possível o teste da aplicação: limpar e criar tabelas para executar os testes e etc.

\n\n

Quando as unidades que estão sendo testadas possuem dependências que produzem efeitos colaterais, como os exemplos acima, não temos garantia de que a unidade está sendo testada isoladamente. Isso abre espaço para que o teste quebre por motivos não vinculados a unidade em sí, como por exemplo o serviço de banco não estar disponível ou uma API externa retornar uma resposta diferente da esperada no teste.

\n\n

Há alguns anos atrás Gerard Meszaros publicou o livro XUnit Test Patterns: Refactoring Test Code e introduziu o termo Test Double (traduzido como “dublê de testes”) que nomeia as diferentes maneiras de substituir dependências. A seguir vamos conhecer os mais comuns test doubles e quais são suas características, prós e contras.

\n\n

Para facilitar a explicação será utilizado o mesmo exemplo para os diferentes tipos de test doubles, também será usada uma biblioteca de suporte chamada Sinon.js que possibilita a utilização de stubs, mocks e spies.

\n\n

A controller abaixo é uma classe que recebe um banco de dados como dependência no construtor. O método que iremos testar unitariamente dessa classe é o método getAll, ele retorna uma consulta do banco de dados com uma lista de usuários.

\n\n

 1 const Database = {\n 2   findAll() {}\n 3 }\n 4 \n 5 class UsersController {\n 6   constructor(Database) {\n 7     this.Database = Database;\n 8   }\n 9 \n10   getAll() {\n11     return this.Database.findAll('users');\n12   }\n13 }\n

\n\n\n\n

\nFake

\n\n

Durante o teste, é frequente a necessidade de substituir uma dependência para que ela retorne algo específico, independente de como for chamada, com quais parâmetros, quantas vezes, a resposta sempre deve ser a mesma. Nesse momento a melhor escolha são os Fakes. Fakes podem ser classes, objetos ou funções que possuem uma resposta fixa independente da maneira que forem chamadas. O exemplo abaixo mostra como testar a classe UsersController usando um fake:

\n\n

 1 describe('UsersController getAll()', () => {\n 2   it('should return a list of users', () => {\n 3     const expectedDatabaseResponse = [{\n 4       id: 1,\n 5       name: 'John Doe',\n 6       email: 'john@mail.com'\n 7     }];\n 8 \n 9     const fakeDatabase = {\n10       findAll() {\n11         return expectedDatabaseResponse;\n12       }\n13     }\n14     const usersController = new UsersController(fakeDatabase);\n15     const response = usersController.getAll();\n16 \n17     expect(response).to.be.eql(expectedDatabaseResponse);\n18   });\n19 });\n

\n\n\n

Nesse caso de teste não é necessária nenhuma biblioteca de suporte, tudo é feito apenas criando um objeto fake para substituir a dependência do banco de dados. O método findAll passa a ter uma resposta fixa, que é uma lista com um usuário.\nPara validar o teste é necessário verificar se a resposta do método getAll do controller responde com uma lista igual a declarada no expectedDatabaseResponse.

\n\n

Vantagens:

\n\n

Simples de escrever
Não necessita de bibliotecas de suporte
Desacoplado da dependencia original

\n\n

Desvantagens:

\n\n

Não possibilita testar múltiplos casos
Só é possível testar se a saída está como esperado, não é possível validar o comportamento interno da unidade

\n\n

Quando usar fakes:

\n\n

Fakes devem ser usados para testar dependências que não possuem muitos comportamentos.

\n\n

\nSpy

\n\n

Como vimos anteriormente os fakes permitem substituir uma dependência por algo customizado mas não possibilitam saber, por exemplo, quantas vezes uma função foi chamada, quais parâmetros ela recebeu e etc. Para isso existem os spies, como o próprio nome já diz, eles gravam informações sobre o comportamento do que está sendo “espionado”.\nNo exemplo abaixo é adicionado um spy no método findAll do Database para verificar se ele está sendo chamado com os parâmetros corretos:

\n\n

 1 describe('UsersController getAll()', () => {\n 2   it('should database findAll with correct parameters', () => {\n 3     const findAll = sinon.spy(Database, 'findAll');\n 4 \n 5     const usersController = new UsersController(Database);\n 6     usersController.getAll();\n 7 \n 8     sinon.assert.calledWith(findAll, 'users');\n 9     findAll.restore();\n10   });\n11 });\n

\n\n\n\n

Note que é adicionado um spy na função findAll do Database, dessa maneira o Sinon devolve uma referência a essa função e também adiciona alguns comportamentos a ela que possibilitam realizar checagens como sinon.assert.calledWith(findAll, 'users') onde é verificado se a função foi chamada com o parâmetro esperado.

\n\n

Vantagens:

\n\n

Permite melhor assertividade no teste
Permite verificar comportamentos internos
Permite integração com dependências reais

\n\n

Desvantagens:

\n\n

Não permitem alterar o comportamento de uma dependência
Não é possível verificar múltiplos comportamentos ao mesmo tempo

\n\n

Quando usar spies:

\n\n

Spies podem ser usados sempre que for necessário ter assertividade de uma dependência real ou, como em nosso caso, em um fake. Para casos onde é necessário ter muitos comportamos é provável que stubs e mocks venham melhor a calhar.

\n\n

\nStub

\n\n

Fakes e spies são simples e substituem uma dependência real com facilidade, como visto anteriormente, porém, quando é necessário representar mais de um cenário para a mesma dependência eles podem não dar conta. Para esse cenário entram na jogada os Stubs. Stubs são spies que conseguem mudar o comportamento dependendo da maneira em que forem chamados, veja o exemplo abaixo:

\n\n

 1 describe('UsersController getAll()', () => {\n 2   it('should return a list of users', () => {\n 3     const expectedDatabaseResponse = [{\n 4       id: 1,\n 5       name: 'John Doe',\n 6       email: 'john@mail.com'\n 7     }];\n 8 \n 9     const findAll = sinon.stub(Database, 'findAll');\n10     findAll.withArgs('users').returns(expectedDatabaseResponse);\n11 \n12     const usersController = new UsersController(Database);\n13     const response = usersController.getAll();\n14 \n15     sinon.assert.calledWith(findAll, 'users');\n16     expect(response).to.be.eql(expectedDatabaseResponse);\n17     findAll.restore();\n18   });\n19 });\n

\n\n\n\n

Quando usamos stubs podemos descrever o comportamento esperado, como nessa parte do código:

\n\n

1 findAll.withArgs('users').returns(expectedDatabaseResponse);\n

\n\n\n

Quando a função findAll for chamada com o parâmetro users, retorna a resposta padrão.

\n\n

Com stubs é possível ter vários comportamentos para a mesma função com base nos parâmetros que são passados, essa é uma das maiores diferenças entre stubs e spies.

\n\n

Como dito anteriormente, stubs são spies que conseguem alterar o comportamento. É possível notar isso na asserção sinon.assert.calledWith(findAll, 'users') ela é a mesma asserção do spy anterior. Nesse teste são feitas duas asserções, isso é feito apenas para mostrar a semelhança com spies, múltiplas asserções em um mesmo caso de teste é considerado uma má prática.

\n\n

Vantagens:

\n\n

Comportamento isolado
Diversos comportamentos para uma mesma função
Bom para testar código assíncrono

\n\n

Desvantagens:

\n\n

Assim como spies não é possível fazer múltiplas verificações de comportamento

\n\n

Quando usar stubs:

\n\n

Stubs são perfeitos para utilizar quando a unidade tem uma dependência complexa, que possui múltiplos comportamentos. Além de serem totalmente isolados os stubs também tem o comportamento de spies o que permite verificar os mais diferentes tipos de comportamento.

\n\n

\nMock

\n\n

Mocks e stubs são comumente confundidos pois ambos conseguem alterar comportamento e também armazenar informações. Mocks também podem ofuscar a necessidade de usar stubs pois eles podem fazer tudo que stubs fazem. O ponto de grande diferença entre mocks e stubs é sua responsabilidade: stubs tem a responsabilidade de se comportar de uma maneira que possibilite testar diversos caminhos do código, como por exemplo uma resposta de uma requisição http ou uma exceção; Já os mocks substituem uma dependência permitindo a verificação de múltiplos comportamentos ao mesmo tempo.\nO exemplo a seguir mostra a classe UsersController sendo testada utilizando Mock:

\n\n

 1 describe('UsersController getAll()', () => {\n 2   it('should call database with correct arguments', () => {\n 3     const databaseMock = sinon.mock(Database);\n 4     databaseMock.expects('findAll').once().withArgs('users');\n 5 \n 6     const usersController = new UsersController(Database);\n 7     usersController.getAll();\n 8 \n 9     databaseMock.verify();\n10     databaseMock.restore();\n11   });\n12 });\n

\n\n\n

A primeira coisa a se notar no código é a maneira de fazer asserções com Mocks, elas são descritas nessa parte:

\n\n

1 databaseMock.expects('findAll').once().withArgs('users');\n

\n\n\n\n

Nela são feitas duas asserções, a primeira para verificar se o método findAll foi chamado uma vez e na segunda se ele foi chamado com o argumento users, em seguida o código é executado e é chamada a função verify() do Mock que irá verificar se as expectativas foram atingidas.

\n\n

Vantagens:

\n\n

Verificação interna de comportamento
Diversas asserções ao mesmo tempo

\n\n

Desvantagens:

\n\n

Diversas asserções ao mesmo tempo podem tornar o teste difícil de entender.

\n\n

Quando usar mocks:

\n\n

Mocks são úteis quando é necessário verificar múltiplos comportamentos de uma dependência. Isso também pode ser sinal de um design de código mal pensado, onde a unidade tem muita responsabilidade. É necessário ter muito cuidado ao usar Mocks já que eles podem tornar os testes pouco legíveis.

\n\n

\nO ambiente de testes em javascript

\n\n

Diferente de muitas linguagens que contam com ferramentas de teste de forma nativa ou possuem algum xUnit (JUnit, PHPUnit, etc) no javascript temos todos os componentes das suites de testes separados, o que nos permite escolher a melhor combinação para a nossa necessidade (mas também pode criar confusão).\nEm primeiro lugar precisamos conhecer os componentes que fazem parte de uma suíte de testes em javascript:

\n\n

\nTest runners

\n\n

Test runners são responsáveis por importar os arquivos de testes e executar os casos de teste. Eles esperam que cada caso de teste devolva true ou false. Alguns dos test runners mais conhecidos de javascript são o Mocha e o Karma.

\n\n

\nBibliotecas de Assert

\n\n

Alguns test runners possuem bibliotecas de assert por padrão, mas é bem comum usar uma externa. Bibliotecas de assert verificam se o teste está cumprindo com o determinado fazendo a afirmação e respondendo com true ou false para o runner. Algumas das bibliotecas mais conhecidas são o chai e o assert.

\n\n

\nBibliotecas de suporte

\n\n

Somente executar os arquivos de teste e fazer o assert nem sempre é o suficiente. Pode ser necessário substituir dependências, subir servidores fake, alterar o DOM e etc. Para isso existem as bibliotecas de suporte. As bibliotecas de suporte se separam em diversas responsabilidades, como por exemplo: para fazer mocks e spys temos o SinonJS e o TestDoubleJS já para emular servidores existe o supertest.

\n\n\n

\nConfigurando testes de integração

\n\n

Iremos testar de fora para dentro, ou seja, começaremos pelos testes de integração e seguiremos para os testes de unidade.

\n\n

\nInstalando Mocha, Chai e Supertest

\n\n

Para começar vamos instalar as ferramentas de testes com o comando abaixo:

\n\n

1 $ npm install --save-dev mocha@^6.2.2 chai@^4.2.0 supertest@^4.0.2\n

\n\n\n\n

Vamos instalar três módulos:

\n\n

\nMocha: módulo que ira executar as suites de teste.
\nChai: módulo usado para fazer asserções.
\nSupertest: módulo usado para emular e abstrair requisições http.

\n\n

\nSeparando execução de configuração

\n\n

Na sequência, será necessário alterar a estrutura de diretórios da nossa aplicação atual, criando um diretório chamado src, onde ficará o código fonte. Dentro dele iremos criar um arquivo chamado app.js que terá a responsabilidade de iniciar o express e carregar os middlewares. Ele ficará assim:

\n\n

1 import express from 'express';\n2 import bodyParser from 'body-parser';\n3 \n4 const app = express();\n5 app.use(bodyParser.json());\n6 \n7 app.get('/', (req, res) => res.send('Hello World!'));\n8 \n9 export default app;\n

\n\n\n\n

Aqui copiamos o código do server.js e removemos a parte do app.listen, a qual iniciava a aplicação, e adicionamos o export default app para exportar o app como um módulo.
\nAgora precisamos alterar o server.js no diretório raiz para que ele utilize o app.js:

\n\n

1 import app from './app';\n2 const port = 3000;\n3 \n4 app.listen(port, () => {\n5   console.log(`app running on port ${port}`);\n6 });\n

\n\n\n\n

Note que agora separamos a responsabilidade de inicializar o express e carregar os middlewares da parte de iniciar a aplicação em sí. Como nos testes a aplicação será inicializada pelo supertest e não pelo express como é feito no server.js, esse separação torna isso fácil.

\n\n

\nConfigurando os testes

\n\n

Agora que a aplicação está pronta para ser testada, vamos configurar os testes. O primeiro passo é criar o diretório test na raiz do projeto, e dentro dele o diretório onde ficarão os testes de integração, vamos chamar esse diretório de integration.
\nA estrutura de diretórios ficará assim:

\n\n

1 ├── package.json\n2 ├── src\n3 │   └── app.js\n4 │   └── server.js\n5 └── test\n6 │   └── integration\n

\n\n\n\n

Dentro de integration vamos criar os arquivos de configuração para os testes de integração. O primeiro será referente as configurações do Mocha, vamos criar um arquivo chamado mocha.opts dentro do diretório integration com o seguinte código:

\n\n

1 --require @babel/register\n2 --require test/integration/helpers.js\n3 --reporter spec\n4 --slow 5000\n

\n\n\n\n

No primeiro require configuramos o Mocha com Babel, ja o segundo será o arquivo referente as configurações de suporte para os testes, o qual criaremos a seguir. Na linha seguinte definimos qual será o reporter, nesse caso, o spec. Reporters definem o estilo da saída do teste no terminal.
\nE na última linha o slow referente a demora máxima que um caso de teste pode levar, como testes de integração tendem a depender de agentes externos como banco de dados e etc, é necessário ter um tempo maior de slow para eles.

\n\n

O próximo arquivo que iremos criar nesse mesmo diretório é o helpers.js. Ele terá o seguinte código:

\n\n

1 import supertest from 'supertest';\n2 import chai from 'chai';\n3 import app from '../../src/app.js';\n4 \n5 global.app = app;\n6 global.request = supertest(app);\n7 global.expect = chai.expect;\n

\n\n\n\n

O arquivo helpers.js é responsável por inicializar as configurações de testes que serão usadas em todos os testes de integração, removendo a necessidade de ter de realizar configurações em cada cenário de teste.

\n\n

Primeiro importamos os módulos necessários para executar os testes de integração que são o supertest e o chai e também a nossa aplicação express que chamamos de app.
\nDepois definimos as globais usando global. Globais fazem parte do Mocha, tudo que for definido como global poderá ser acessado em qualquer teste sem a necessidade de ser importado.
\nNo nosso arquivo helpers configuramos o app para ser global, ou seja, caso seja necessário usá-lo em um caso de teste basta chamá-lo diretamente. Também é definido um global chamado request, que é o supertest recebendo o express por parâmetro.
\nLembram que falei da vantagem de separar a execução da aplicação da configuração do express? Agora o express pode ser executado por um emulador como o supertest.
\nE por último o expect do Chai que será utilizado para fazer as asserções nos casos de teste.

\n\n

\nCriando o primeiro caso de teste

\n\n

Com as configurações finalizadas agora nos resta criar nosso primeiro caso de teste. Vamos criar um diretório chamado routes dentro do diretório integration e nele vamos criar o arquivo products_spec.js que vai receber o teste referente as rotas do recurso products da nossa API.
\nA estrutura de diretórios deve estar assim:

\n\n

 1 ├── package.json\n 2 ├── src\n 3 │   └── app.js\n 4 │   └── server.js\n 5 └── test\n 6 │  └── integration\n 7 │    ├── helpers.js\n 8 │    ├── mocha.opts\n 9 │    └── routes\n10 │      └── products_spec.js\n

\n\n\n\n

Agora precisamos escrever nosso caso de teste, vamos começar com o seguinte código no arquivo products_spec.js:

\n\n

1 describe('Routes: Products', () => {\n2 \n3 });\n

\n\n\n\n

O describe é uma global do Mocha usada para descrever suítes de testes que contém um ou mais casos de testes e/ou contém outras suítes de testes. Como esse é o describe que irá englobar todos os testes desse arquivo seu texto descreve a responsabilidade geral da suíte de testes que é testar a rota products.
\nAgora vamos adicionar um produto padrão para os nossos testes:

\n\n

1 describe('Routes: Products', () => {\n2   const defaultProduct = {\n3     name: 'Default product',\n4     description: 'product description',\n5     price: 100\n6   };\n7 });\n

\n\n\n\n

Como a maioria dos testes precisará de um produto, tanto para inserir quanto para verificar nas buscas, criamos uma constante chamada defaultProduct para ser reusada pelos casos de teste.
\nO próximo passo é descrever a nossa primeira suíte de testes:

\n\n

 1 describe('Routes: Products', () => {\n 2   const defaultProduct = {\n 3     name: 'Default product',\n 4     description: 'product description',\n 5     price: 100\n 6   };\n 7 \n 8   describe('GET /products', () => {\n 9     it('should return a list of products', done => {\n10 \n11     });\n12   });\n13 });\n

\n\n\n\n

Adicionamos mais um describe para deixar claro que todas as suítes de teste dentro dele fazem parte do método http GET na rota /products. Isso facilita a legibilidade do teste e deixa a saída do terminal mais clara.

\n\n

A função it também é uma global do Mocha e é responsável por descrever um caso de teste.
\nDescrições de casos de teste seguem um padrão declarativo, como no exemplo acima: “Isso deve retornar uma lista de produtos”.
\nNote que também é passado um parâmetro chamado done para o caso de teste, isso ocorre porque testes que executam funções assíncronas, como requisições http, precisam informar ao Mocha quando o teste finalizou e fazem isso chamando a função done.
\nVejamos na implementação a seguir:

\n\n

 1 describe('Routes: Products', () => {\n 2   const defaultProduct = {\n 3     name: 'Default product',\n 4     description: 'product description',\n 5     price: 100\n 6   };\n 7 \n 8   describe('GET /products', () => {\n 9     it('should return a list of products', done => {\n10 \n11       request\n12       .get('/products')\n13       .end((err, res) => {\n14         expect(res.body[0]).to.eql(defaultProduct);\n15         done(err);\n16       });\n17     });\n18   });\n19 });\n

\n\n\n\n

Na implementação do teste usamos o supertest que exportamos globalmente como request no helpers.js. O supertest nos permite fazer uma requisição http para uma determinada rota e verificar a sua resposta.
\nQuando a requisição terminar a função end será chamada pelo supertest e vai receber a resposta ou um erro, caso ocorra. No exemplo acima é verificado se o primeiro elemento da lista de produtos retornada é igual ao nosso defaultProduct.
\nO expect usado para fazer a asserção faz parte do Chai e foi exposto globalmente no helpers.js.
\nPara finalizar, notificamos o Mocha que o teste finalizou chamando a função done que recebe err como parâmetro, caso algum erro ocorra ele irá mostrar a mensagem de erro no terminal.

\n\n

\nExecutando os testes

\n\n

Escrito nosso teste, vamos executá-lo. Para automatizar a execução vamos adicionar a seguinte linha no package.json dentro de scripts:

\n\n

1 \"test:integration\": \"NODE_ENV=test mocha --opts test/integration/mocha.opts test/int\\\n2 egration/**/*_spec.js\"\n

\n\n\n\n

Estamos adicionando uma variável de ambiente como test, que além de boa prática também nos será útil em seguida, e na sequência as configurações do Mocha.

\n\n

Para executar os testes agora basta executar o seguinte comando no terminal, dentro do diretório root da aplicação:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saída deve ser a seguinte:

\n\n

 1 Routes: Products\n 2 GET /products\n 3 1) should return a list of products\n 4 \n 5 0 passing (172ms)\n 6   1 failing\n 7 \n 8 \n 9   1) Routes: Products GET /products should return a list of products:\n10   Uncaught AssertionError: expected undefined to deeply equal { Object (name, descri\\\n11 ption, ...) }\n

\n\n\n\n

Isso quer dizer que o teste está implementado corretamente, sem erros de sintaxe por exemplo, mas está falhando pois ainda não temos esse comportamento na aplicação. Essa é a etapa RED do TDD, conforme vimos anteriormente.

\n\n

\nFazendo os testes passarem

\n\n

Escrevemos nossos testes e eles estão no estado RED, ou seja, implementados mas não estão passando. O próximo passo, seguindo o TDD, é o GREEN onde vamos implementar o mínimo para fazer o teste passar.
\n Para isso, precisamos implementar uma rota na nossa aplicação que suporte o método http GET e retorne uma lista com, no mínimo, um produto igual ao nosso defaultProduct do teste. \n Vamos alterar o arquivo app.js e adicionar a seguinte rota:

\n\n

1 app.get('/products', (req, res) => res.send([{\n2   name: 'Default product',\n3   description: 'product description',\n4   price: 100\n5 }]));\n

\n\n\n\n

Como vimos no capítulo sobre os middlewares do express, os objetos de requisição (req) e resposta (res) são injetados automaticamente pelo express nas rotas. No caso acima usamos o método send do objeto de resposta para enviar uma lista com um produto como resposta da requisição, o que deve ser suficiente para que nosso teste passe.
\nCom as alterações o app.js deve estar assim:

\n\n

 1 import express from 'express';\n 2 import bodyParser from 'body-parser';\n 3 \n 4 const app = express();\n 5 app.use(bodyParser.json());\n 6 \n 7 app.get('/', (req, res) => res.send('Hello World!'));\n 8 app.get('/products', (req, res) => res.send([{\n 9   name: 'Default product',\n10   description: 'product description',\n11   price: 100\n12 }]));\n13 \n14 export default app;\n

\n\n\n\n

Agora que já temos a implementação, podemos executar nosso teste novamente:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saída deve ser de sucesso, como essa:

\n\n

1 Routes: Products\n2 GET /products\n3 ✓ should return a list of products\n4 \n5 \n6 1 passing (164ms)\n

\n\n\n\n

Nosso teste está passando, e estamos no estado GREEN do TDD, ou seja, temos o teste e a implementação suficiente para ele passar. O próximo passo será o REFACTOR onde iremos configurar as rotas.

\n\n

O código dessa etapa está disponível neste link.

\n\n\n

\nEstrutura de diretórios e arquivos

\n\n

Um dos primeiros desafios quando começamos uma aplicação em Node.js é estruturar o projeto. Uma grande conveniência do Node, por ser javascript, é a liberdade para estrutura, design de código, patterns e etc. Porém, isso também pode gerar confusão para os novos desenvolvedores.

\n\n

A maioria dos projetos no github, por exemplo, possuem estruturas que diferem entre si, essa variação acontece pois cada desenvolvedor cria a estrutura da forma que se enquadrar melhor a sua necessidade.

\n\n

Mesmo assim podemos aproveitar os padrões comuns entre esses projetos para estruturar nossa aplicação de maneira que atenda as nossas necessidades e também fique extensível, legível e facilmente integrável com ferramentas externas, como Travis, CodeClimate e etc.

\n\n

\nO diretório raiz

\n\n

O diretório raiz do projeto é o ponto de entrada e fornece a primeira impressão. No exemplo a seguir, temos uma estrutura comum em aplicações usando o framework Express.js:

\n\n

1 ├── app.js\n2 ├── controllers\n3 ├── middlewares\n4 ├── models\n5 ├── package.json\n6 └── tests\n

\n\n\n\n

Essa estrutura é legível e organizada, mas com o crescimento da aplicação pode misturar diretórios de código com diretórios de teste, build e etc. Um padrão comum em diversas linguagens é armazenar o código da aplicação em um diretório source normalmente chamado src.

\n\n

1 ├── package.json\n2 ├── src\n3 │   ├── controllers\n4 │   ├── middlewares\n5 │   └── models\n6 │   └── app.js\n7 │   └── server.js\n8 └── tests\n

\n\n\n\n

Dessa maneira o código da aplicação é isolado em um diretório deixando a raiz do projeto mais limpa e acabando com a mistura de diretórios de código com diretórios de testes e arquivos de configuração.

\n\n

\nO que fica no diretório raiz?

\n\n

No exemplo acima movemos o código da aplicação para o diretório src mas mantivemos o diretório tests, isso acontece porque testes são executados por linha de comando ou por outras ferramentas. Inclusive os test runners como mocha e karma esperam que o diretório tests esteja no diretório principal. \nOutros diretórios comumente localizados na raiz são scripts de suporte ou build, exemplos, documentação e arquivos estáticos. No exemplo abaixo vamos incrementar nossa aplicação com mais alguns diretórios:

\n\n

 1 ├── env\n 2 │   ├── dev.env\n 3 │   └── prod.env\n 4 ├── package.json\n 5 ├── public\n 6 │   ├── assets\n 7 │   ├── css\n 8 │   ├── images\n 9 │   └── js\n10 ├── scripts\n11 │   └── deploy.sh\n12 ├── src\n13 │   ├── server.js\n14 │   ├── app.js\n15 │   ├── controllers\n16 │   ├── middlewares\n17 │   ├── models\n18 │   └── routes\n19 └── tests\n

\n\n\n\n

O diretório public é responsável por guardar tudo aquilo que vai ser entregue para o usuário. Mantê-lo na raiz facilita a criação de rotas de acesso e a movimentação dos assets, caso necessário. Os diretórios scripts e env são relacionados a execução da aplicação e serão chamados por alguma linha de comando ou ferramenta externa, colocá-los em um diretório acessível promove a usabilidade.

\n\n

\nDentro do diretório source

\n\n

Agora que já entendemos o que fica fora do diretório src vamos ver como organizá-lo baseado nas nossas necessidades.

\n\n

1 ├── src\n2 │   ├── app.js\n3 │   ├── server.js\n4 │   ├── controllers\n5 │   ├── middlewares\n6 │   ├── models\n7 │   └── routes\n

\n\n\n\n

Essa estrutura é bastante utilizada, ela é clara e separa as responsabilidades de cada componente, além de permitir o carregamento dinâmico.

\n\n

\nResponsabilidades diferentes dentro de um mesmo source

Ás vezes, quando começamos uma aplicação, já sabemos o que será desacoplado e queremos dirigir nosso design para que no futuro seja possível separar e tornar parte do código um novo módulo. Outra necessidade comum é ter APIs específicas para diferentes tipos de clientes, como no exemplo a seguir:

\n\n

 1 └── src\n 2     ├── app.js\n 3     ├── server.js\n 4     ├── mobile\n 5     │   ├── controllers\n 6     │   ├── index.js\n 7     │   ├── middlewares\n 8     │   ├── models\n 9     │   └── routes\n10     └── web\n11         ├── controllers\n12         ├── index.js\n13         ├── middlewares\n14         ├── models\n15         └── routes\n

\n\n\n\n

Esse cenário funciona bem mas pode dificultar o reúso de código entre os componentes. Então, antes de implementar, tenha certeza que seu caso de uso permite a separação dos clientes sem que um dependa do outro.

\n\n

\nServer e Client no mesmo repositório

Muitas vezes temos o backend e o front-end separados mas versionados juntos, no mesmo repositório, seja ele git, mercurial, ou qualquer outro controlador de versão. A estrutura mais comum que pude observar na comunidade para esse tipo de situação é separar o server e o client como no exemplo abaixo:

\n\n

 1 ├── client\n 2 │   ├── controllers\n 3 │   ├── models\n 4 │   └── views\n 5 ├── client.js\n 6 ├── config\n 7 ├── package.json\n 8 ├── server\n 9 │   ├── controllers\n10 │   ├── models\n11 │   └── routes\n12 └── tests\n

\n\n\n\n

Essa estrutura é totalmente adaptável ás necessidades. No exemplo acima, os testes de ambas as aplicações estão no diretório tests no diretório raiz. Assim, se o projeto for adicionado em uma integração contínua ele vai executar a bateria de testes de ambas as aplicações. O server.js e o client.js são responsáveis por iniciar as respectivas aplicações. Podemos ter um npm start no package.json que inicie os dois arquivos juntos.

\n\n

\nSeparação por funcionalidade

Um padrão bem frequente é o que promove a separação por funcionalidade. Nele abstraímos os diretórios baseado nas funcionalidades e não nas responsabilidades, como no exemplo abaixo:

\n\n

 1 └── src\n 2     ├── app.js\n 3     ├── server.js\n 4     ├── orders\n 5     │   ├── orders.controller.js\n 6     │   └── orders.routes.js\n 7     └── products\n 8         ├── products.controller.js\n 9         ├── products.model.js\n10         └── products.routes.js\n

\n\n\n\n

Essa estrutura possui uma boa legibilidade e escalabilidade, por outro lado, pode crescer muito tornando o reúso de componentes limitado e dificultando o carregamento dinâmico de arquivos.

\n\n

\nConversão de nomes

\n\n

Quando separamos os diretórios por suas responsabilidades pode não ser necessário deixar explícito a responsabilidade no nome do arquivo.

\n\n

Veja o exemplo abaixo:

\n\n

1 └── src\n2     ├── controllers\n3     │   └── products.js\n4     └── routes\n5         └── products.js\n

\n\n\n\n

Como o nosso diretório é responsável por informar qual a responsabilidade dos arquivos que estão dentro dele, podemos nomear os arquivos sem adicionar o sufixo _ + nome do diretório (por exemplo: “_controller”). Além disso, o javascript permite nomear um módulo quando o importamos, permitindo que mesmo arquivos com o mesmo nome sejam facilmente distinguidos por quem está lendo o código, veja o exemplo:

\n\n

1 Import ProductsController from './src/controllers/products'; \n2 Import ProductsRoute from './src/routes/products'; \n

\n\n\n\n

Dessa maneira não adicionamos nenhuma informação desnecessária ao nomes dos arquivos e ainda mantemos a legibilidade do código.

\n\n

No decorrer do livro utilizaremos o exemplo seguindo o padrão MVC com a diretório source e os demais diretórios dentro, como controllers, models e etc.

\n\n\n

\nRotas com o express router

\n\n

O express possui um middleware nativo para lidar com rotas, o Router. O Router é responsável por administrar as rotas da aplicação e pode ser passado como parâmetro para o app.use(). Utilizando o Router é possível desacoplar as rotas e remover a necessidade de usar o app (instância do express) em outros lugares da aplicação.

\n\n

\nSeparando as rotas

\n\n

Vamos alterar nossa aplicação para separar as rotas do app. Para isso devemos criar um diretório chamado routes dentro de src. Os diretórios devem ficar assim:

\n\n

1 ├── package.json\n2 ├── src\n3 │   ├── app.js\n4 │   ├── server.js\n5 │   └── routes\n

\n\n\n\n

Dentro de routes criaremos um arquivo chamado index.js que será responsável por carregar todas as rotas da aplicação:

\n\n

1 import express from 'express';\n2 \n3 const router = express.Router();\n4 \n5 export default router;\n

\n\n\n\n

No código acima importamos o express, acessamos o Router dentro dele e depois o exportamos.\nAgora que temos um arquivo para administrar as rotas podemos mover a lógica de administração das rotas que estão no app.js para o nosso index.js. Primeiro movemos a rota padrão. O arquivo de rotas deverá ficar assim:

\n\n

1 import express from 'express';\n2 \n3 const router = express.Router();\n4 \n5 router.get('/', (req, res) => res.send('Hello World!'));\n6 \n7 export default router;\n

\n\n\n\n

\nRotas por recurso

\n\n

No código anterior não movemos a rota products porque ela não ficará no index.js. Cada recurso da api terá seu próprio arquivo de rotas e o index.js será responsável por carregar todos eles.

\n\n

Agora, vamos criar um arquivo para as rotas do recurso products da nossa api.

\n\n

Para isso será necessário criar um arquivo chamado products.js dentro do diretório routes, ele terá o seguinte código:

\n\n

1 import express from 'express';\n2 \n3 const router = express.Router();\n4 \n5 export default router;\n

\n\n\n\n

Agora podemos mover a rota products do app.js para o products.js. Ele deve ficar assim:

\n\n

 1 import express from 'express';\n 2 \n 3 const router = express.router();\n 4 \n 5 router.get('/', (req, res) => res.send([{\n 6   name: 'default product',\n 7   description: 'product description',\n 8   price: 100\n 9 }]));\n10 \n11 export default router;\n

\n\n\n\n

Note que agora o padrão da rota não é mais /products e somente / , isso é uma boa prática para separar recursos da api. Como nosso arquivo é products.js as rotas dentro dele serão referentes ao recurso products da api, assim internamente não precisamos repetir esse prefixo, deixaremos para o index carregar essa rota e dar o prefixo pra ela.\nVamos alterar o index.js para carregar a nossa nova rota, ele deve ficar assim:

\n\n

1 import express from 'express';\n2 import productsRoute from './products';\n3 \n4 const router = express.Router();\n5 \n6 router.use('/products', productsRoute);\n7 router.get('/', (req, res) => res.send('Hello World!'));\n8 \n9 export default router;\n

\n\n\n

Primeiro importamos a rota que foi criada anteriormente e damos o nome de productsRoute. Depois, para carregar a rota, chamamos a função use do router passando o prefixo da rota que será /products e o productsRoute que importamos.

\n\n

Com as rotas configuradas, o último passo é alterar o app.js para carregar nosso arquivo de rotas, ele deve ficar assim:

\n\n

1 import express from 'express';\n2 import bodyParser from 'body-parser';\n3 import routes from './routes';\n4 \n5 const app = express();\n6 app.use(bodyParser.json());\n7 app.use('/', routes);\n8 \n9 export default app;\n

\n\n\n\n

As rotas que estavam no app.js foram movidas para seus respectivos arquivos e agora importamos apenas o routes. Como foi criado um index.js dentro de routes não é necessário especificar o nome do arquivo, apenas importar o diretório /routes e automaticamente o módulo do Node.js procurará primeiro por um arquivo index.js e o importará. Em seguida o routes é passado como parâmetro para a função use junto com o /, significa que toda requisição vai ser administrada pelo routes.

\n\n

\nRouter paths

\n\n

Nos passos anteriores foram criadas algumas rotas que simbolizam caminhos na aplicação combinando um padrão e um método HTTP, por exemplo, uma requisição do tipo get na rota / irá retornar “Hello World”, já em /products irá retornar um produto fake. Essa é a maneira de definir endpoints em APIs com o express router.

\n\n

O caminho passado por parâmetro para o método HTTP é chamado de path, por exemplo router.get(\"/products\"). Paths podem ser strings, patterns ou expressões regulares. Caso precise testar rotas complexas o express possui um testador de rotas online onde é possível adicionar o caminho e verificar como ele será interpretado pelo express router.

\n\n

\nExecutando os testes

\n\n

Nesse momento nossos testes devem estar passando novamente, o que irá nos garantir que nossa refatoração foi concluída com sucesso.

\n\n

O código dessa etapa está disponivel aqui

\n\n\n

\nControllers

\n\n

Os controllers serão responsáveis por receber as requisições das rotas, interagir com o Model quando necessário e retornar a resposta para o usuário.\nNo nosso código atual, as rotas estão com muita responsabilidade e difíceis de testar isoladamente, pois dependemos do express. Para corrigir esse comportamento precisamos adicionar os controllers. Vamos criar os controllers guiados por testes de unidade, assim será possível validar o comportamento de forma separada do nosso sistema em si.

\n\n

\nConfigurando os testes de unidade

\n\n

Como vimos no capítulo de testes de unidade, testes de unidade servem para testar pequenas partes do software isoladamente.

\n\n

Para começar, crie um diretório chamado unit dentro do diretório test, na raiz do projeto. Assim como fizemos nos testes de integração, criaremos os arquivos de configuração para os testes.\nVamos criar um arquivo chamado helpers.js dentro de unit, com o seguinte código:

\n\n

1 import chai from 'chai';\n2 \n3 global.expect = chai.expect;\n

\n\n\n\n

Em seguida, vamos criar o arquivo mocha.opts para as configurações do Mocha. Ele deve possuir o seguinte código:

\n\n

1 --require @babel/register\n2 --require test/unit/helpers.js\n3 --reporter spec\n4 --slow 5000\n

\n\n\n\n

A última etapa de configuração dos testes de unidade será a criação de um comando para executar os testes. Vamos adicionar o seguinte script no package.json:

\n\n

1 \"test:unit\": \"NODE_ENV=test mocha --opts test/unit/mocha.opts test/unit/**/*_spec.js\"\n

\n\n\n\n

Para testar se o comando esta funcionando basta executar:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A saída do terminal deve informar que não conseguiu encontrar os arquivos de teste:

\n\n

1 Warning: Could not find any test files matching pattern: test/unit/**/*_spec.js\n2 No test files found\n

\n\n\n\n

Vamos criar nosso primeiro teste de unidade para o nosso futuro controller de produtos. A separação de diretórios será semelhante a da aplicação com controllers, models e etc.

\n\n

Criaremos um diretório chamado controllers dentro de unit e dentro dele um arquivo com o cenário de teste que vamos chamar de products_spec.js. Em seguida vamos executar os testes unitários novamente, a saída deve ser a seguinte:

\n\n

1 0 passing (2ms)\n

\n\n\n\n

Ok, nenhum teste está passando pois ainda não criamos nenhum.

\n\n

\nTestando o controller unitariamente

\n\n

Vamos começar a escrever o teste. O primeiro passo será adicionar a descrição desse cenário de testes, como no código a seguir:

\n\n

1 describe('Controllers: Products', () => {\n2 \n3 });\n

\n\n\n\n

Esse cenário irá englobar todos os testes do controller de products. Vamos criar cenários para cada um dos métodos, o próximo cenário terá o seguinte código:

\n\n

1 describe('Controllers: Products', () => {\n2 \n3     describe('get() products', () => {\n4 \n5     });\n6 \n7 });\n

\n\n\n\n

Precisamos agora criar nosso primeiro caso de teste para o método get. Começaremos nosso caso de teste descrevendo o seu comportamento:

\n\n

1 describe('Controllers: Products', () => {\n2 \n3   describe('get() products', () => {\n4     it('should return a list of products', () => {\n5 \n6     });\n7   });\n8 \n9 });\n

\n\n\n

Segundo a descrição do nosso teste, o método get deve retornar uma lista de produtos. Esse é o comportamento que iremos garantir que está sendo contemplado. Começaremos iniciando um novo controller como no código a seguir:

\n\n

 1 import ProductsController from '../../../src/controllers/products';\n 2 \n 3 describe('Controllers: Products', () => {\n 4 \n 5   describe('get() products', () => {\n 6     it('should return a list of products', () => {\n 7 \n 8       const productsController = new ProductsController();\n 9 \n10     });\n11   });\n12 });\n

\n\n\n

Importamos o ProductsController do diretório onde ele deve ser criado e dentro do caso de teste inicializamos uma nova instância. Nesse momento se executarmos nossos testes de unidade devemos receber o seguinte erro:

\n\n

1 Error: Cannot find module '../../../src/controllers/products'\n2     at Function.Module._resolveFilename (module.js:455:15)\n3     at Function.Module._load (module.js:403:25)\n4 …\n

\n\n\n

A mensagem de erro explica que o módulo products não foi encontrado, como esperado. Vamos criar o nosso controller para que o teste passe.\nVamos adicionar um diretório chamado controllers em src e dentro dele vamos criar o arquivo products.js, que será o controller para o recurso de products da API:

\n\n

1 class ProductsController {\n2 \n3 }\n4 \n5 export default ProductsController;\n

\n\n\n\n

Com o controller criado no diretório correto o nosso teste deve estar passando, vamos tentar novamente os testes unitários:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A saída do terminal deve ser a seguinte:

\n\n

1   Controllers: Products\n2     get() products\n3       ✓ should return a list of products\n4 \n5 \n6   1 passing (176ms)\n

\n\n\n\n

Até o momento ainda não validamos o nosso comportamento esperado, apenas foi validado que o nosso controller existe. \nAgora precisamos garantir que o comportamento esperado no teste está sendo coberto, para isso precisamos testar se o método get chama a função de resposta do express.\nAntes de começar esse passo precisamos instalar o Sinon, uma biblioteca que irá nos ajudar a trabalhar com spies, stubs e mocks, os quais serão necessários para garantir o isolamento dos testes unitários.

\n\n

\nMocks, Stubs e Spies com Sinon.js

\n\n

Para instalar o Sinon basta executar o seguinte comando:

\n\n

1 $ npm install --save-dev sinon@^7.5.0\n

\n\n\n\n

Após a instalação ele já estará disponível para ser utilizado em nossos testes.\nVoltando ao teste, vamos importar o Sinon e também usar um spy para verificar se o método get do controller está realizando o comportamento esperado. O código do teste deve ficar assim:

\n\n

 1 import ProductsController from '../../../src/controllers/products';\n 2 import sinon from 'sinon';\n 3 \n 4 describe('Controllers: Products', () => {\n 5   const defaultProduct = [{\n 6     name: 'Default product',\n 7     description: 'product description',\n 8     price: 100\n 9   }];\n10 \n11   describe('get() products', () => {\n12     it('should return a list of products', () => {\n13       const request = {};\n14       const response = {\n15         send: sinon.spy()\n16       };\n17 \n18       const productsController = new ProductsController();\n19       productsController.get(request, response);\n20 \n21       expect(response.send.called).to.be.true;\n22       expect(response.send.calledWith(defaultProduct)).to.be.true;\n23     });\n24   });\n25 });\n

\n\n\n

Muita coisa aconteceu nesse bloco de código, mas não se preocupe, vamos passar por cada uma das alterações.

\n\n

A primeira adição foi o import do Sinon, módulo que instalamos anteriormente.

\n\n

Logo após a descrição do nosso cenário de teste principal adicionamos uma constant chamada defaultProduct que armazena um array com um objeto referente a um produto com informações estáticas. Ele será útil para reaproveitarmos código nos casos de teste.

\n\n

Dentro do caso de teste foram adicionadas duas constants: request, que é um objeto fake da requisição enviada pela rota do express, que vamos chamar de req na aplicação, e response, que é um objeto fake da resposta enviada pela rota do express, a qual vamos chamar de res na aplicação.

\n\n

Note que a propriedade send do objeto response recebe um spy do Sinon, como vimos anteriormente, no capítulo de test doubles, os spies permitem gravar informações como quantas vezes uma função foi chamada, quais parâmetros ela recebeu e etc. O que será perfeito em nosso caso de uso pois precisamos validar que a função send do objeto response está sendo chamada com os devidos parâmetros.

\n\n

Até aqui já temos a configuração necessária para reproduzir o comportamento que esperamos. O próximo passo é chamar o método get do controller passando os objetos request e response que criamos. E o último passo é verificar se o método get está chamando a função send com o defaultProduct como parâmetro.\nPara isso foram feitas duas asserções, a primeira verifica se a função send foi chamada, e a segunda verifica se ela foi chamada com o defaultProduct como parâmetro.

\n\n

Nosso teste está pronto, se executarmos os testes unitários devemos receber o seguinte erro:

\n\n

 1   Controllers: Products\n 2     get() products\n 3       1) should return a list of products\n 4 \n 5 \n 6   0 passing (156ms)\n 7   1 failing\n 8 \n 9   1) Controllers: Products get() products should return a list of products:\n10      TypeError: productsController.get is not a function\n11       at Context.it (test/unit/controllers/products_spec.js:19:26)\n

\n\n\n\n

O erro explica que productsController.get não é uma função, então vamos adicionar essa função ao controller. \nA função get deverá possuir a lógica que agora está na rota de produtos. Vamos adicionar o método get no ProductsController, o código deve ficar assim:

\n\n

 1 class ProductsController {\n 2 \n 3   get(req, res) {\n 4     return res.send([{\n 5       name: 'Default product',\n 6       description: 'product description',\n 7       price: 100\n 8     }])\n 9   }\n10 }\n11 \n12 export default ProductsController;\n

\n\n\n\n

O método get deve receber os objetos de requisição e resposta e enviar um array com um produto estático como resposta.

\n\n

Vamos executar os testes novamente, a saída do terminal deve ser a seguinte:

\n\n

1   Controllers: Products\n2     get() products\n3       ✓ should return a list of products\n4 \n5 \n6   1 passing (189ms)\n

\n\n\n\n

\nIntegrando controllers e rotas

\n\n

Nosso controller está feito e estamos obtendo o comportamento esperado, mas até então não integramos com a aplicação. Para realizar essa integração basta alterar a rota de produtos para usar o controller. Edite o arquivo products.js em src/routes, removendo o bloco de código que foi movido para o controller, e adicione a chamada para o método get. A rota de produtos deve ficar assim:

\n\n

1 import express from 'express';\n2 import ProductsController from '../controllers/products';\n3 \n4 const router = express.Router();\n5 const productsController = new ProductsController();\n6 router.get('/', (req, res) => productsController.get(req, res));\n7 \n8 export default router;\n

\n\n\n\n

Vamos executar os testes de integração para garantir que o controller foi integrado corretamente com o resto da nossa aplicação.

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saída do terminal deve ser a seguinte:

\n\n

1   Routes: Products\n2     GET /products\n3       ✓ should return a list of products\n4 \n5 \n6   1 passing (251ms)\n

\n\n\n\n

Os código desta etapa esta disponível aqui

\n\n\n

\nConfigurando o MongoDB como banco de dados

\n\n

Nesse livro o banco de dados escolhido foi o MongdoDB, principalmente pela simplicidade de ingração e vasto suporte opensource.

\n\n

\nIntrodução ao MongoDB

\n\n

Até o ano de 2009 o mundo dos banco de dados era dominado por bancos RDMS (Relational Database Management System) baseados em SQL (Structured Query Language). Esse tipo de banco de dados baseado em um modelo relacional foi introduzido em 1970 e é utilizado até hoje.\nCom o surgimento da Cloud e Big Data os bancos relacionais começaram a enfrentar os desafios de escalar devido ao design relacional. Há 50 anos, quando os bancos de dados relacionais foram criados, o desafio que era armazenar dados, armazenamento era caro e lento.

\n\n

Nos dias de hoje o armazenamento de dados é extremamente barato e não é mais visto como um problema, o desafio agora é está no processamento de dados. Empresas como a NASA com o projeto de monitoramento climático e de aquecimento global precisam processar e armazenar petabytes de dados. Pela natureza relacional, bancos RDMS não suportam bem esses casos, é difícil escalá-los horizontalmente já que os dados ficam em tabelas diferentes e são ligados por chaves.

\n\n

Em 2009 o MongoDB surgiu, trazendo um design não relacional focado em prover escala e performance. O MongoDB armazena os dados de forma isolada possibilitando escalar horizontalmente de forma simples e com alta performance.

\n\n

O MongoDB segue um padrão chamado NoSQL. NoSQL não utilizada linguagem SQL e é livre de dados relacionais.\nNão existe um padrão fixo de NoSQL mas a maioria dos bancos de dados possui características similares como:

\n\n

Não possuem um schema fixo
Tendem a serem escaláveis e distribuídos por padrão
Utilizam diferentes estratégias para armazenar os dados de forma otimizada para escala e performance diferente da conhecida tabela, colunas e linhas dos bancos de dados RDMS.

\n\n

Alguns paradigmas NoSQL são:

\n\n

Bancos em gráfico (Graph Databases)
Armazenamento chave/valor (Key/Value store)
Armazenamento por documentos (Document store)

\n\n

O MongoDB segue o paradigma de armazenamento de documentos e conta com três itens chave: Document, Field e Collection

\n\n

Document: Similar a linha (row) de um banco de dados relacional
Field: Similar a coluna (column) de um banco de dados relacional
Collection: Similar a tabela (table) de um banco de dados relacional

\n\n

\nConfigurando o banco de dados com Mongoose

\n\n

Para integrar nossa aplicação com o MongoDB vamos utilizar o Mongoose que é um ODM (Object Document Mapper). O Mongoose irá abstrair o acesso ao banco de dados e ainda irá se responsabilizar por transformar os dados do banco em Models, facilitando a estruturação de nossa aplicação com o padrão MVC.

\n\n

Para instalar o Mongoose basta executar o seguinte comando npm:

\n\n

1 $ npm install mongoose@^5.7.13\n

\n\n\n\n

Após a instalação o Mongoose estará disponível para ser utilizado. O próximo passo será configurar a aplicação para conectar com o banco de dados. Para isso vamos criar um diretório chamado config dentro de src e dentro dele um arquivo chamado database.js que será responsável por toda configuração do banco de dados.

\n\n

A estrutura de diretórios deve estar assim:

\n\n

 1 ├── src\n 2 │   ├── app.js\n 3 │   ├── server.js\n 4 │   ├── config\n 5 │   │   └── database.js\n 6 │   ├── controllers\n 7 │   │   └── products.js\n 8 │   └── routes\n 9 │       ├── index.js\n10 │       └── products.js\n

\n\n\n\n

A primeira coisa que deve ser feita no database.js é importar o módulo do Mongoose, como no código abaixo:

\n\n

1 import mongoose from 'mongoose';\n

\n\n\n\n

Seguindo a configuração do banco de dados é necessário informar a url onde está o MongoDB. No meu caso está no meu computador então a url será “localhost” seguido do nome que daremos ao banco de dados:

\n\n

1 const mongodbUrl = process.env.MONGODB_URL || 'mongodb://localhost/test';\n

\n\n\n\n

Note que primeiro verificamos se não existe uma variável de ambiente, caso não exista é usado o valor padrão que irá se referir ao localhost e ao banco de dados test. Dessa maneira, poderemos utilizar o MongoDB tanto para testes quanto para rodar o banco da aplicação, sem precisar alterar o código.

\n\n

No próximo passo vamos criar uma função para conectar com o banco de dados:

\n\n

1 const connect = () => mongoose.connect(mongodbUrl);\n

\n\n\n\n

Acima, criamos uma função que retorna uma conexão com o MongoDB, esse retorno é uma Promise, ou seja, somente quando a conexão for estabelecida a Promise será resolvida. Isso é importante pois precisamos garantir que nossa aplicação só vai estar disponível depois que o banco de dados estiver conectado e acessível.

\n\n

Logo abaixo vamos adicionar um método para fechar a conexão com o banco de dados, essa é uma boa prática que facilita muito nos casos de teste, depois de executar os testes fechamos o banco de dados e garantimos que nada esta executando em nossa aplicação.

\n\n

1 const close = () => mongoose.connection.close();\n

\n\n\n\n

O último passo é exportar o módulo de configuração do banco de dados:

\n\n

1 export default {\n2   connect,\n3   connection: mongoose.connection\n4 }\n

\n\n\n\n

O código do database.js deve estar similar ao que segue:

\n\n

 1 import mongoose from \"mongoose\";\n 2 \n 3 const mongodbUrl = process.env.MONGODB_URL || \"mongodb://localhost/test\";\n 4 \n 5 const connect = () =>\n 6   mongoose.connect(mongodbUrl, {\n 7     useNewUrlParser: true,\n 8     useUnifiedTopology: true\n 9   });\n10 \n11 export default {\n12   connect,\n13   close\n14 };\n

\n\n\n\n

Pronto, o banco de dados está configurado. Nosso próximo passo será integrar o banco de dados com a aplicação, para que ela inicialize o banco sempre que for iniciada.

\n\n

\nIntegrando o Mongoose com a aplicação

\n\n

O módulo responsável por inicializar a aplicação é o app.js, então, ele que vai garantir que o banco estará disponível para que a aplicação possa consumi-lo.\nVamos alterar o app.js para que ele integre com o banco de dados, atualmente ele está assim:

\n\n

1 import express from 'express';\n2 import bodyParser from 'body-parser';\n3 import routes from './routes';\n4 \n5 const app = express();\n6 app.use(bodyParser.json());\n7 app.use('/', routes);\n8 \n9 export default app;\n

\n\n\n\n

O primeiro passo é importar o módulo responsável pelo banco de dados, o database.js, que fica dentro do diretório config. Os imports devem ficar assim:

\n\n

1  import express from 'express';\n2  import bodyParser from 'body-parser';\n3  import routes from './routes';\n4 + import database from './config/database';\n

\n\n\n\n

A seguir vamos alterar um pouco o código anterior que utiliza o express e as rotas movendo o seguinte trecho:

\n\n

1 - app.use(bodyParser.json());\n2 - app.use('/', routes);\n3  \n4 - export default app;\n

\n\n\n\n

Os trechos em vermelho serão movidos para dentro de uma nova função, como no código abaixo:

\n\n

1 + const configureExpress = () => {\n2 +  app.use(bodyParser.json());\n3 +  app.use('/', routes);\n4 +  app.database = database;\n5 +\n6 +  return app;\n7 +};\n

\n\n\n\n

Acima criamos uma função nomeada configureExpress que terá a tarefa de configurar o express e retornar uma nova instância de aplicação configurada. Também adicionamos a instância do banco de dados, database, para ser parte da aplicação express dessa maneira e possivel abrir e fechar o banco de dados utilizando a app do express.

\n\n

A última etapa da nossa alteração é inicializar o banco antes da aplicação. Como o moongose retorna uma Promise, vamos esperar ela ser resolvida para então retornar a aplicação configurada para ser utilizada.

\n\n

1 + export default async() => {\n2 +  const app = configureExpress();\n3 +  await app.database.connect();\n4 +\n5 +  return app;\n6 +};\n

\n\n\n\n

No bloco acima exportamos uma função que retorna uma Promise esse passo é necesario pois a função connect do database, que criamos na etapa anterior, assim que essa Promise for resolvida, significa que o banco de dados estará disponível, então retornamos a instância da aplicação.

\n\n

O app.js depois de alterado deve estar assim:

\n\n

 1 import express from \"express\";\n 2 import bodyParser from \"body-parser\";\n 3 import routes from \"./routes\";\n 4 import database from \"./config/database\";\n 5 \n 6 const app = express();\n 7 \n 8 const configureExpress = () => {\n 9   app.use(bodyParser.json());\n10   app.use(\"/\", routes);\n11   app.database = database;\n12 \n13   return app;\n14 };\n15 \n16 export default async () => {\n17   const app = configureExpress();\n18   await app.database.connect();\n19 \n20   return app;\n21 };\n

\n\n\n\n

Como alteramos o app para retornar uma função, que por sua vez retorna uma Promise, será necessário alterar o server.js para fazer a inicialização de maneira correta.

\n\n

\nAlterando a inicilização

\n\n

O server.js é o arquivo responsável por inicializar a aplicação, chamando o app. Como alteramos algumas coisas na etapa anterior precisamos atualizá-lo.\nVamos começar alterando o nome do módulo na importação:

\n\n

1 - import app from './app';\n2 + import setupApp from './app';\n

\n\n\n\n

O módulo foi alterado de app para setupApp, por quê? Porque agora ele é uma função e esse nome reflete mais a sua responsabilidade.

\n\n

O próximo passo é alterar a maneira como o app é chamado:

\n\n

 1 -app.listen(port, () => {\n 2 -  console.log(`app running on port ${port}`);\n 3 -});\n 4 +(async () => {\n 5 +  try {\n 6 +    const app = await setupApp();\n 7 +    const server = app.listen(port, () =>\n 8 +      console.info(`app running on port ${port}`)\n 9 +    );\n10 +\n11 +    const exitSignals = [\"SIGINT\", \"SIGTERM\", \"SIGQUIT\"];\n12 +    exitSignals.map(sig =>\n13 +      process.on(sig, () =>\n14 +        server.close(err => {\n15 +          if (err) {\n16 +            console.error(err);\n17 +            process.exit(1);\n18 +          }\n19 +          app.database.connection.close(function() {\n20 +            console.info(\"Database connection closed!\");\n21 +            process.exit(0);\n22 +          });\n23 +        })\n24 +      )\n25 +    );\n26 +  } catch (error) {\n27 +    console.error(error);\n28 +    process.exit(1);\n29 +  }\n30 +})();\n

\n\n\n\n

Como o código anterior devolvia uma instância da aplicação diretamente, era apenas necessário chamar o método listen do express para inicializar a aplicação. Agora temos uma função que retorna uma promise devemos chamá-la e ela vai inicializar o app, inicializando o banco, configurando o express e retornando uma nova instância da aplicação, só então será possível inicializar a aplicação chamando o listen.

\n\n

Até esse momento espero que vocês já tenham lido a especificação de Promises mais de 10 vezes e já sejam mestres na implementação. Quando um problema ocorre a Promise é rejeitada. Esse erro pode ser tratado usando um catch como no código acima.\nAcima, recebemos o erro e o mostramos no console.error, em seguida encerramos o processo do Node.js com o código 1.\nDessa maneira o processo é finalizado informando que houve um erro em sua inicialização. Informar o código de saída, é uma boa prática finalizar o processo com código de erro e conhecido como “graceful shutdowns” e faz parte da lista do 12 factor app de boas práticas para desenvolvimento de software moderno.

\n\n

\nGraceful shutdown

\n\n

O graceful shutdown é muito importante principalmente no momento em que a aplicação precisa escalar e rodar na nuvem onde normalmente ela sera executada dentro de um container. Orquestradores de containers como Kubernetes mandam comandos para a aplicação. A aplicação é responsavel por receber esse comando e administrar sua finalização antes de desligar, isso siginifica que a aplicação deve finalizar as conexões abertas, fechar a conexão com o banco de dados e então desligar.\nNo código acima isso é feito utilizando adicionando event listeners a os sinais SIGINT, SIGTERM, SIGQUIT utilizando o process.on(sig). Dessa maneira se a aplicação receber um dos sinais listados ela vai primeiro fechar o servidor express chamando o método close, server.close(), nesse momento o express vai fechar as conexões abertas e logo após fechar a conxão com o banco de dados, connection.close() e finalizar a aplicação com sucesso.\nCaso um erro ocorra para fechar a conexão do express o processo vai finalizar com 1, ou seja, falha.\nDesta maneira quem está finalizando o processo vai poder checar a saida (0) para sucesso ou (1) para falha para saber se a aplicação foi desligada com sucesso sem impactar nenhum cliente ou o banco de dados.

\n\n

As alterações necessárias para integrar com o banco de dados estão finalizadas, vamos executar os testes de integração para garantir:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saida será:

\n\n

 1  Routes: Products\n 2     GET /products\n 3       1) should return a list of products\n 4 \n 5 \n 6   0 passing (152ms)\n 7   1 failing\n 8 \n 9   1) Routes: Products GET /products should return a list of products:\n10      TypeError: Cannot read property 'get' of undefined\n11       at Context.done (test/integration/routes/products_spec.js:21:7)\n

\n\n\n\n

O teste quebrou! Calma, isso era esperado.\nAssim como o server.js o teste de integração inicia a aplicação usando o módulo app, então ele também deve ser alterado para lidar com a Promise.

\n\n

Vamos começar alterando o helpers.js dos testes de integração, como no código abaixo:

\n\n

1 -import app from '../../src/app.js';\n2 +import setupApp from '../../src/app.js';\n3   \n4 -global.app = app;\n5 -global.request = supertest(app);\n6 +global.setupApp = setupApp;\n7 +global.supertest = supertest;\n

\n\n\n\n

Assim como no server.js, alteramos o nome do módulo de app para setupApp e o exportamos globalmente. Também removemos o request do conceito global que era uma instância do supertest com o app configurado, deixaremos para fazer isso no próximo passo.

\n\n

Agora é necessário alterar o products_spec.js para inicializar a aplicação antes de começar a executar os casos de teste usando o callback before do Mocha:

\n\n

1 describe('Routes: Products', () => {\n2 +  let request;\n3 +  let app;\n4 +\n5 +  before(async () => {\n6 +    app = await setupApp();\n7 +    request = supertest(app);\n8 +  });\n

\n\n\n\n

No bloco acima, criamos um let para o request do supertest e no before a aplicação é inicializada. Assim que o setupApp retornar uma instância da aplicação é possível inicializar o supertest e atribuir a let request que definimos anteriormente. E também definimos o let app para armazenar a instancia da app do express, isso sera necessario apos executar todos os testes para fechar o banco de dados.

\n\n\n\n

Executando os testes novamente, a saída deve ser a seguinte:

\n\n

1   Routes: Products\n2     GET /products\n3       ✓ should return a list of products\n4 \n5 \n6   1 passing (336ms)\n

\n\n\n\n

Caso ocorra um erro como: “MongoError: failed to connect to server [localhost:27017] on first connect”:

\n\n

 1   Routes: Products\n 2     1) \"before all\" hook\n 3 \n 4 \n 5   0 passing (168ms)\n 6   1 failing\n 7 \n 8   1) Routes: Products \"before all\" hook:\n 9      MongoError: failed to connect to server [localhost:27017] on first connect\n10       at Pool.<anonymous> (node_modules/mongodb-core/lib/topologies/server.js:326:35)\n11       at Connection.<anonymous> (node_modules/mongodb-core/lib/connection/pool.js:27\\\n12 0:12)\n13       at Socket.<anonymous> (node_modules/mongodb-core/lib/connection/connection.js:\\\n14 175:49)\n15       at emitErrorNT (net.js:1272:8)\n16       at _combinedTickCallback (internal/process/next_tick.js:74:11)\n17       at process._tickCallback (internal/process/next_tick.js:98:9)\n

\n\n\n\n

A mensagem de erro explica que o MongoDB não está executando em localhost na porta 7000, verifique e tente novamente.

\n\n

O ultimo passo é adicionar o metódo after do Mocha que é chamado após todos os testes:

\n\n

1   after(async () => await app.database.connection.close());\n

\n\n\n

Aqui garantimos que estamos fechando a conexão com o banco de dados após todos os testes, dessa maneira o Mocha vai executar os testes e logo após a execução vai fechar o banco e fechar o processo no terminal.

\n\n

O código desta etapa esta disponível aqui.

\n\n\n

\nO padrão MVC

\n\n

MVC é um design pattern de arquitetura que foca na separação de responsabilidades. O MVC separa os dados de negócio (Models) da interface do usuário (Views) e usa um componente para ligá-los (Controllers), normalmente os controllers são responsáveis por receber a entrada do usuário e coordenar Models e Views.

\n\n

\nVoltando ao tempo do Smalltalk

\n\n

Para entender o padrão MVC é necessário voltar alguns anos no tempo, aos anos 70 para ser mais preciso, fase da emergência das interfaces gráficas de usuário. Na década de 70, Trygve Reenskaug trabalhava em uma linguagem de programação chamada Smalltalk, com a qual ele desenvolveu e aplicou o padrão MVC com objetivo de separar a interface do usuário da lógica da aplicação, conceito conhecido como Separated Presentation.\nEssa arquitetura consistia em:

\n\n

Um elemento de domínio denominado Model que não deveria ter conhecimento da interface e interação do usuário (Views e Controllers).

\n\n

A camada de apresentação e interação seria feita pelas views e controllers, com um controller e uma view para cada elemento que seria mostrado na tela.

\n\n

A responsabilidade do controller era receber entradas das views, como por exemplo: teclas pressionadas, formularios ou eventos de click.

\n\n

Para atualizar a view era utilizado um padrão conhecido como Observer. Cada vez que o model mudava, essa mudança era refletida na view.

\n\n

É impressionante ver que um padrão utilizando até hoje como o Observer (também implementado como pub/sub hoje em dia) era parte crucial do MVC. No Smalltak MVC ambos views e controllers observavam o model, para que qualquer mudança conseguisse ser refletida na view. Para quem deseja se aprofundar mais nas origens do padrão MVC indico o artigo GUI Architectures, do Martin Fowler, que conta a história do MVC ao longo dos anos.

\n\n

\nMVC no javascript

\n\n

Nos anos de hoje o MVC é base para a maioria dos frameworks e arquiteturas de projetos em diversas linguagens. Frameworks como SpringMVC do Java, Symfony do PHP e Ruby on Rails do Ruby utilizam esse padrão para o desenvolvimento.

\n\n

No javascript o MVC começou no contexto dos browsers, quando as aplicações começaram a ter mais responsabilidades no front-end com as single page apps o javascript passou pela mesma necessidade do Smalltalk nos anos 70: separar a interface da lógica de negócio.\nUma gama de frameworks para o front-end apareceram aplicando MVC com diversas variações, como por exemplo o Backbone e o Ember.js.\nA chegada do javascript no server side com o Node.js trouxe a mesma necessidade, frameworks como Express.js e Sails.js utilizam MVC como base de arquitetura para criação de aplicações.

\n\n

Conforme mencionado, o MVC é composto por três componentes:

\n\n

\nModels

\n\n

Os Models são responsáveis por administrar os dados da aplicação. Os models variam muito de aplicações e frameworks mas normalmente eles são responsáveis por validar os dados e também persistir sincronizando com um localStorage ou banco de dados.\nModels podem ser observados por mais de uma view; Views podem precisar de partes diferentes dos dados de um model. Por exemplo, um model de usuário pode ser utilizado em uma view para mostrar nome e email, e em outra para mudar a senha.

\n\n

\nViews

\n\n

Views são uma forma visual de representar os models e apresentar a informaçao para o usuario. Views normalmente observam os models para refletirem suas mudanças na tela. A maioria dos livros de design patterns se referem à views como “burras”, pois sua única responsabilidade é mostrar o estado do model.

\n\n

\nControllers

\n\n

Controllers agem como mediadores entre views e models. Resumidamente, sua responsabilidade é atualizar o model quando a view muda e atualizar a view quando o model muda.

\n\n

Para os desenvolvedores vindos do javascript no front-end há uma variação enorme em como o MVC é implementado, muitas vezes omitindo o C, ou seja, não utilizando controllers, isso pois as necessidades no front-end são diferentes.\nUm exemplo de implementação de controller no front-end que sempre deu muita discussão é a do Angular.js versão 1.x, que é totalmente acoplado a view utilizando um padrão chamado de 2 way data binding que faz com que as alterações na tela sejam enviadas para o controller e as alterações no controller enviadas para a view.\nAlém de ser responsável por escutar e emitir eventos, o que atribui muita responsabilidade para os controllers, assim quebrando o princípio de responsabilidade única.

\n\n

Em 2015 com o surgimento do React e frameworks como Flux, o MVC no front-end perdeu força pois a componentização, programação reativa e as arquiteturas unidirecionais começaram a fazer mais sentido no contexto dos browsers.

\n\n

Já no server side com Node.js esse padrão ainda é muito utilizado e útil. No Sails.js a implementação de um controller para administrar as requisições e conversar com o model é obrigatório. Já no Express.js essa conversão não é obrigatória, mas é sugerida. O próprio gerador de código do Express já cria o diretório para controllers separadamente.

\n\n

\nAs vantagens de utilizar MVC

\n\n

A separação de responsabilidades facilita a modularização das funcionalidades da aplicação e possibilita:

\n\n

Manutenibilidade: Quando uma modificação precisa ser feita é mais fácil de descobrir onde é e também onde vai causar impacto.
Desacoplar models e views facilita os testes em ambos isoladamente. Testando a lógica de negócio em models e a usabilidade em views.
Reutilização de código

\n\n

\nMVC em API

\n\n

Para APIs, a parte da view não é aplicada. No decorrer do livro será aplicado o padrão MVC, adaptado para o contexto da API que será desenvolvida, com Controllers e Models.\nEm APIs o controller recebe a requisição da rota, faz a chamada para o model realizar a lógica de negócio e retorna a resposta para o usuário.

\n\n\n

\nModels

\n\n

Como visto no capítulo sobre MVC, os models são responsáveis pelos dados, persistência e validação na aplicação. Aqui estamos utilizando o Mongoose, que já provê uma API para a utilização de models.

\n\n

\nCriando o model com Mongoose

\n\n

O primeiro passo será a criação de um diretório chamando models e um arquivo chamado products.js dentro de src, como no exemplo abaixo:

\n\n

1 ├── src\n2 │   ├── models\n3 │   │   └── product.js\n

\n\n\n\n

No products.js devemos começar importando o módulo do mongoose:

\n\n

1 import mongoose from 'mongoose';\n

\n\n\n\n

Após isso será necessário descrever o schema do model de products. O schema é utilizado pelo mongoose para válidar e mapear os dados do model. Cada schema representa uma collection do MongoDB.

\n\n

Adicione um schema como o seguinte:

\n\n

1 const schema = new mongoose.Schema({\n2   name: String,\n3   description: String,\n4   price: Number\n5 });\n

\n\n\n\n

No bloco acima uma nova instância de schema é definida e atribuída a constant schema, o model está definido, agora basta exportá-lo para que ele possa ser utilizado na aplicação:

\n\n

1 const Product = mongoose.model('Product', schema);\n2 \n3 export default Product;\n

\n\n\n\n

Chamando mongoose.model com um nome, no nosso caso Product definimos um model no módulo global do mongoose. O que significa que qualquer lugar que importar o módulo do mongoose a partir de agora na aplicação poderá acessar o model de products que foi definido pois o módulo do mongoose é um Singleton.

\n\n

A versão final do model Product deve ficar similar a esta:

\n\n

 1 import mongoose from 'mongoose';\n 2 \n 3 const schema = new mongoose.Schema({\n 4   name: String,\n 5   description: String,\n 6   price: Number\n 7 });\n 8 const Product = mongoose.model('Product', schema);\n 9 \n10 export default Product;\n

\n\n\n\n

\nSingleton Design Pattern

\n\n

No Node.js, e no Javascript em geral, existem inúmeras maneiras de aplicar o Singleton, vamos revisar as formas mais utilizadas.\nTradicionalmente o Singleton restringe a inicialização de uma nova classe a um único objeto ou referência.\nSegundo Addy Osmani, no livro Javascript Design Patterns:

\n\n

\n
With JavaScript, singletons serve as a namespace provider which isolate implementation code from the global namespace so-as to provide a single point of access for functions.
\n

\n\n

Traduzindo livremente:

\n\n

Singletons em javascript servem como um provedor de namespaces isolando a implementação do código do namespace global possibilitando assim acesso a somente um ponto, que podem ser funções ou classes por exemplo.

\n\n

No código a seguir definimos um Model no Mongoose:

\n\n

 1 import mongoose from 'mongoose';\n 2 \n 3 const schema = new mongoose.Schema({\n 4   name: String,\n 5   description: String,\n 6   price: Number\n 7 });\n 8 const Product = mongoose.model('Product', schema);\n 9 \n10 export default Product;\n

\n\n\n\n

Note que importamos o módulo do Mongoose e não iniciamos uma nova instância com new, apenas acessamos o módulo diretamente. Em seguida, definimos um novo schema para o Model e então, utilizando a função mongoose.model, definimos um model chamado Product na instância do mongoose que importamos.

\n\n

Agora se importarmos o módulo do Mongoose em qualquer outro lugar da aplicação e acessarmos os models teremos uma resposta como a seguinte:

\n\n

1 //src/routes/products.js\n2 \n3 import mongoose from 'mongoose';\n4 \n5 console.log(mongoose.models);\n

\n\n\n

O console.log mostrará:

\n\n

1 { Product:\n2    { [Function: model]\n3 ...\n

\n\n\n\n

Essa é a implementação e a responsabilidade de um Singleton: prover acesso a mesma instância independente de quantas vezes ou da maneira que for chamada.

\n\n

Vamos ver como é implementado o Singleton no código do Mongoose. No arquivo /lib/index.js do módulo temos a seguinte função:

\n\n

 1 function Mongoose() {\n 2   this.connections = [];\n 3   this.plugins = [];\n 4   this.models = {};\n 5   this.modelSchemas = {};\n 6   // default global options\n 7   this.options = {\n 8     pluralization: true\n 9   };\n10   var conn = this.createConnection(); // default connection\n11   conn.models = this.models;\n12 }\n

\n\n\n\n

Para quem não é familiarizado com es2015, a função Mongoose() representará uma classe.\nNo final do arquivo podemos ver como o módulo é exportado:

\n\n

1 var mongoose = module.exports = exports = new Mongoose;\n

\n\n\n\n

Essa atribuições: var mongoose = module.exports = exports não são o nosso foco. A parte importante dessa linha é o new Mongoose que garante que o módulo exportado será uma nova instância da classe Mongoose.

\n\n

Você pode estar se perguntando se uma nova instância será criada sempre que importamos o módulo, a resposta é não.\nMódulos no Node.js são cacheados uma vez que carregados, o que significa que o que acontece no module.exports só acontecerá uma vez a cada inicialização da a aplicação ou quando o cache for limpo (o que só pode ser feito manualmente).\nDessa maneira o código acima exporta uma referência a uma nova classe e quando a importamos temos acesso diretamente a seus atributos e funções internas.

\n\n

Singletons são extremamente úteis para manter estado em memória possibilitando segurança entre o compartilhamento de uma mesma instância a todos que a importarem.

\n\n

Veremos mais sobre módulos no capítulo sobre modularização.

\n\n

\nIntegrando models e controllers

\n\n

Até agora nosso controller responde com dados fakes e nosso teste de integração ainda está no estado GREEN. \nAdicionamos o model e agora precisamos integrar ele com o controller e depois com a rota para que seja possível finalizar a integração e completar o passo de REFACTOR do nosso teste de integração.

\n\n

Para começar vamos atualizar o teste de unidade do controller para refletir o comportamento que esperamos. Para isso devemos começar atualizando o arquivo test/unit/controllers/products_spec.js importando os módulos necessários para descrever o comportamento esperado no teste:

\n\n

1 import ProductsController from '../../../src/controllers/products';\n2 import sinon from 'sinon';\n3 +import Product from '../../../src/models/product';\n

\n\n\n\n

Aqui importamos o módulo referente ao model de Product que criamos anteriormente e será usado pelo controller.

\n\n

Agora vamos mudar o caso de teste incluindo o comportamento que esperamos quando integrarmos com o model.

\n\n

1   describe('get() products', () => {\n2 -   it('should return a list of products', () => {\n3 +   it('should return a list of products', async() => {\n4       const request = {};\n5       const response = {\n6         send: sinon.spy()\n7       };\n8 +     Product.find = sinon.stub();\n

\n\n\n\n

No código acima começamos atualizando a descrição, não iremos checar o retorno pois a saída da função get é uma chamada para a função send do express, então nossa descrição deve refletir isso, dizemos que: “Isso deve chamar a função send com uma lista de produtos”.

\n\n

Logo após atribuimos um stub para a função find do model Product. Desta maneira será possível adicionar qualquer comportamento para essa função simulando uma chamada de banco de dados por exemplo.\nO próximo passo será mudar o seguinte código para utilizar o stub:

\n\n

1 -      const productsController = new ProductsController();\n2 -      productsController.get(request, response);\n3 +      Product.find.withArgs({}).resolves(defaultProduct);\n

\n\n\n\n

No withArgs({}) dizemos para o stub que quando ele for chamado com um objeto vazio ele deve resolver uma Promise retornando o defaultProduct. Esse comportamento será o mesmo que o moongose fará quando buscar os dados do banco de dados. Mas como queremos testar isoladamente vamos remover essa integração com o banco de dados utilizando esse stub.

\n\n

Agora precisamos mudar o comportamento esperado:

\n\n

1 -      expect(response.send.called).to.be.true;\n2 -      expect(response.send.calledWith(defaultProduct)).to.be.true;\n3 +      const productsController = new ProductsController(Product);\n4 +\n5 +      await productsController.get(request, response);\n6 +\n7 +      sinon.assert.calledWith(response.send, defaultProduct)\n8 +    });\n

\n\n\n\n

No código acima, o primeiro passo foi iniciar uma nova instância de ProductsController passando por parâmetro o model. Dessa maneira esperamos que cada instância de controller possua um model.\nNa linha seguinte retornamos a função get do productsController. Isso por que ela será uma Promise, e precisamos retornar para que nosso test runner, o Mocha, a chame e a resolva. Quando a Promise é resolvida é checado se a função send do objeto response, que é um spy, foi chamada com o defaultProduct:

\n\n

1 sinon.assert.calledWith(response.send, defaultProduct);\n

\n\n\n\n

Isso valida que a função get foi chamada, chamou a função find do model Product passando um objeto vazio e ele retornou uma Promise contendo o defaultProduct. O código final deve estar similar a este:

\n\n

 1 import ProductsController from '../../../src/controllers/products';\n 2 import sinon from 'sinon';\n 3 import Product from '../../../src/models/product';\n 4 \n 5 describe('Controllers: Products', () => {\n 6   const defaultProduct = [\n 7     {\n 8       name: 'Default product',\n 9       description: 'product description',\n10       price: 100\n11     }\n12   ];\n13 \n14   describe('get() products', () => {\n15     it('should return a list of products', async () => {\n16       const request = {};\n17       const response = {\n18         send: sinon.spy()\n19       };\n20 \n21       Product.find = sinon.stub();\n22       Product.find.withArgs({}).resolves(defaultProduct);\n23 \n24       const productsController = new ProductsController(Product);\n25 \n26       await productsController.get(request, response);\n27 \n28       sinon.assert.calledWith(response.send, defaultProduct);\n29     });\n30 });\n

\n\n\n\n

Se executarem os testes de unidade agora, eles estão falhando, então vamos a implementação!

\n\n

\nAtualizando o controller para utilizar o model

\n\n

Agora precisamos atualizar o controller products que fica em: src/controllers/products.js. Vamos começar adicionando um construtor para poder receber o model Product, como no código a seguir:

\n\n

1 class ProductsController {\n2 +  constructor(Product) {\n3 +    this.Product = Product;\n4 +  };\n

\n\n\n\n

O construtor irá garantir que toda a vez que alguém tentar criar uma instância do controller ele deve passar o model Product por parâmetro. Mas ai vocês me perguntam, mas por que não importar ele diretamente no productsController.js? Pois assim não seria possível usar stub no model e tornaria o código acoplado. Veremos mais sobre como gerenciar dependencias nos capítulos seguintes.

\n\n

Seguindo a atualização do controller agora devemos atualizar o método que estamos testando, o get. Como no código a seguir:

\n\n

 1    get(req, res) {\n 2 -    return res.send([{\n 3 -      name: 'Default product',\n 4 -      description: 'product description',\n 5 -      price: 100\n 6 -    }])\n 7 +     const products = await this.Product.find({});\n 8 +     res.send(products);\n 9     }\n10   }\n

\n\n\n\n

Aqui removemos o produto fake que era retornado, para aplicar a lógica real de integração com o banco. Note que this.Product.find({}) segundo a documentação do mongoose irá retornar uma lista de objetos, então o que estásendo feito quando a Promise resolver é passar essa lista para a função send do objeto res do express para que ele retorne para o usuário que fez a requisição.

\n\n

Essa é a implementação necessária para que o teste passe, vamos rodá-lo:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A resposta deve ser:

\n\n

1   Controllers: Products\n2     get() products\n3       ✓ should return a list of products\n4 \n5 \n6   1 passing (217ms)\n

\n\n\n\n

\nTestando casos de erro

\n\n

Até agora apenas testamos o happy path (termo usado para descrever o caminho feliz esperado em um teste), mas o que acontecerá se der algum erro na consulta ao banco? Que código de erro e mensagem devemos enviar para o usuário?

\n\n

Vamos escrever um caso de teste unitário para esse comportamento, o caso de teste deve ser como o seguinte:

\n\n

 1     it('should return 400 when an error occurs', async () => {\n 2       const request = {};\n 3       const response = {\n 4         send: sinon.spy(),\n 5         status: sinon.stub()\n 6       };\n 7 \n 8       response.status.withArgs(400).returns(response);\n 9       Product.find = sinon.stub();\n10       Product.find.withArgs({}).rejects({ message: 'Error' });\n11 \n12       const productsController = new ProductsController(Product);\n13 \n14       await productsController.get(request, response);\n15 \n16       sinon.assert.calledWith(response.send, 'Error');\n17     });\n

\n\n\n\n

Devemos dar atenção a dois pontos nesse teste, primeiro é:

\n\n

1 response.status.withArgs(400).returns(response);\n

\n\n\n\n

Onde dizemos que: Quando a função status for chamada com o argumento 400 ela deve retornar o objeto response, isso por que a API do express concatena as chamadas de funções. O próximo ponto é:

\n\n

1 Product.find.withArgs({}).rejects({message: 'Error'});\n

\n\n\n\n

Aqui utilizamos o stub para rejeitar a Promise e simular uma consulta ao banco que retornou uma falha.\nSe executarmos os testes agora receberemos um erro, pois não implementamos ainda, então vamos implementar.\nAtualize a função get do controller de products adicionando um catch na busca, ele deve ficar assim:

\n\n

1   async get(req, res) {\n2     try {\n3       const products = await this.Product.find({});\n4       res.send(products);\n5     } catch (err) {\n6       res.status(400).send(err.message);\n7     }\n8   }\n

\n\n\n\n

Aqui é dito que, quando ocorrer algum erro, o status da requisição será 400, usamos res.status que é uma função do express que adiciona o statusCode da resposta HTTP. Após isso enviamos a resposta adicionando a mensagem do erro como corpo utilizando a função send do objeto de resposta do express.

\n\n

Agora basta executar os testes de unidade novamente e eles devem estar passando:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A resposta deve ser:

\n\n

1   Controllers: Products\n2     get() products\n3       ✓ should return a list of products\n4       ✓ should return 400 when an error occurs\n5 \n6 \n7   2 passing (13ms)\n

\n\n\n\n

Nossa unidade está pronta para ser integrada com o resto da aplicação, faremos isso no próximo passo.

\n\n

\nO passo Refactor do TDD

\n\n

Lembram que nosso teste de integração está no passo GREEN do TDD? Ou seja, está com lógica suficiente para passar mas não está com a implementação real. Agora que o controller já está completo, integrando com o model, é o melhor momento para refatorar o resto dos componentes fazendo a integração com o model e controller.

\n\n

\nIntegração entre rota, controller e model

\n\n

Nesse passo vamos refatorar nossa rota de products para que ela consiga criar o controller corretamente, passando o model como dependência. Altere o arquivo src/routes/products.js para que ele fique como o código a seguir:

\n\n

 1 import express from 'express';\n 2   import ProductsController from '../controllers/products';\n 3 + import Product from '../models/product';\n 4   \n 5   const router = express.Router();\n 6 - const productsController = new ProductsController();\n 7 + const productsController = new ProductsController(Product);\n 8   router.get('/', (req, res) => productsController.get(req, res));\n 9   \n10   export default router;\n

\n\n\n\n

A única mudança é que a nova instância do controller recebe o model Product por parâmetro. A integração parece estar pronta, vamos executar os testes de integração:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saida sera como a seguinte:

\n\n

 1 Routes: Products\n 2     GET /products\n 3       1) should return a list of products\n 4 \n 5 \n 6   0 passing (286ms)\n 7   1 failing\n 8 \n 9   1) Routes: Products GET /products should return a list of products:\n10      Uncaught AssertionError: expected undefined to deeply equal { Object (name, des\\\n11 cription, ...) }\n12       at Test.request.get.end (test/integration/routes/products_spec.js:41:34)\n13       at Test.assert (node_modules/supertest/lib/test.js:179:6)\n14       at Server.assert (node_modules/supertest/lib/test.js:131:12)\n15       at emitCloseNT (net.js:1549:8)\n16       at _combinedTickCallback (internal/process/next_tick.js:71:11)\n17       at process._tickCallback (internal/process/next_tick.js:98:9)\n

\n\n\n\n

O teste falhou, e isso é esperado, pois agora utilizamos o MongoDB e vamos precisar criar um produto antes de executar o teste para que seja possível reproduzir o cenário que queremos.

\n\n

Vamos adicionar o que precisamos no teste de integração da rota de productos, abra o arquivo test/integration/routes/products_spec.js.\nA primeira coisa é a resposta que esperamos do MongoDB. O MongoDB adiciona alguns campos aos documentos salvos que são _v, corresponde a versão do documento e _id que é o identificador único do documento, normalmente um uuid.v4.

\n\n

 1 const defaultProduct = {\n 2       name: 'Default product',\n 3       description: 'product description',\n 4       price: 100\n 5     };\n 6 +  const expectedProduct = {\n 7 +    __v: 0,\n 8 +    _id: '56cb91bdc3464f14678934ca',\n 9 +    name: 'Default product',\n10 +    description: 'product description',\n11 +    price: 100\n12 +  };\n13 +\n

\n\n\n\n

Logo abaixo do defaultProduct adicionamos uma constant chamada expectedProduct correspondente ao produto que esperamos ser criado pelo MongoDB.\nAgora já possuímos o produto que queremos salvar que é defaultProduct e também o que esperamos de resposta do MongoDB.

\n\n

Como estamos testando a rota products que retorna todos os produtos, precisamos ter produtos no banco de dados para poder validar o comportamento. Para isso iremos utilizar o callback do Mocha chamado beforeEach, que significa: antes de cada. Esse callback é executado pelo Mocha antes de cada caso de teste, então ele é perfeito para nosso cenário onde precisamos ter um produto disponível no banco antes de executar o teste.

\n\n

Logo abaixo do código anterior adicione o seguinte código:

\n\n

1 +  beforeEach(async() => {\n2 +    await Product.deleteMany();\n3 +\n4 +    const product = new Product(defaultProduct);\n5 +    product._id = '56cb91bdc3464f14678934ca';\n6 +    return await product.save();\n7 +  });\n8 +\n

\n\n\n\n

O que o código acima faz, é criar um novo produto utilizando os dados da constant defaultProduct e atribuir a nova instância do produto a constant product. Na linha seguinte a propriedade product._id do objeto criado pelo mongoose é sobrescrita por um id estático que geramos.\nPor padrão o mongoose gera um uuid para cada novo documento, mas no caso do teste precisamos saber qual é o id do documento que estamos salvando para poder comparar dentro do caso de teste, se utilizarmos o uuid gerado pelo mongoose o teste nunca conseguirá comparar o mesmo id. Dessa maneira sobrescrevemos por um id gerado por nós mesmos.\nExistem vários sites na internet para gerar uuid, aqui no livro por exemplo foi utilizado este: uuid generator.

\n\n

Após a atribuição do id retornamos uma Promise que remove todos os produtos do banco de dados e depois salva o produto que criamos.

\n\n

O próximo passo é garantir que iremos deixar o terreno limpo após executar o teste. Quando criamos testes que criam dados em banco de dados, escrevem arquivos em disco, ou seja, testes que podem deixar rastros para outros testes devemos limpar todo o estado e garantir que após a execução do teste não terá nenhum vestígio para os próximos.\nPara isso vamos adicionar também o callback afterEach que significa: Depois de cada, para garantir que o MongoDB ficará limpo, ou seja, sem dados. Para isso adicione o seguinte código logo abaixo do anterior:

\n\n

1 +  afterEach(async() => await Product.deleteMany());\n

\n\n\n\n

O último passo é atualizar o caso de teste para que ele verifique o expectedProduct no lugar do defaultProduct:

\n\n

 1    describe('GET /products', () => {\n 2       it('should return a list of products', done => {\n 3   \n 4         request\n 5         .get('/products')\n 6         .end((err, res) => {\n 7 -         expect(res.body[0]).to.eql(defaultProduct);\n 8 +         expect(res.body).to.eql([expectedProduct]);\n 9           done(err);\n10         });\n11       });\n

\n\n\n\n

O código final do products_spec.js deve estar similar a este:

\n\n

 1 import Product from '../../../src/models/product';\n 2 \n 3 describe('Routes: Products', () => {\n 4   let request;\n 5   let app;\n 6 \n 7   before(async () => {\n 8     app = await setupApp();\n 9     request = supertest(app);\n10   });\n11 \n12   after(async () => await app.database.connection.close());\n13 \n14   const defaultProduct = {\n15     name: 'Default product',\n16     description: 'product description',\n17     price: 100\n18   };\n19   const expectedProduct = {\n20     __v: 0,\n21     _id: '56cb91bdc3464f14678934ca',\n22     name: 'Default product',\n23     description: 'product description',\n24     price: 100\n25   };\n26 \n27   beforeEach(async() => {\n28     await Product.deleteMany();\n29 \n30     const product = new Product(defaultProduct);\n31     product._id = '56cb91bdc3464f14678934ca';\n32     return await product.save();\n33   });\n34 \n35   afterEach(async() => await Product.deleteMany());\n36 \n37   describe('GET /products', () => {\n38     it('should return a list of products', done => {\n39       request.get('/products').end((err, res) => {\n40         expect(res.body).to.eql([expectedProduct]);\n41         done(err);\n42       });\n43     });\n44   });\n45 });\n

\n\n\n\n

Executando os testes de integração novamente:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

Devemos ter a seguinte resposta:

\n\n

1   Routes: Products\n2     GET /products\n3 \n4       ✓ should return a list of products\n5 \n6 \n7   1 passing (307ms)\n

\n\n\n\n

Nosso ciclo de TDD nos testes de integração está completo, refatoramos e adicionamos o comportamento esperado. Esse padrão onde começamos por testes de integração, depois criamos componentes internos como fizemos com controllers e models e utilizamos o teste de integração para válidar todo o comportamento, é conhecido como outside-in, termo esse que falaremos a seguir.

\n\n

O código deste capitulo está disponível aqui.

\n\n\n

\nBehaviour Driven Development - BDD

\n\n

Como vimos até agora, o ponto forte do TDD é garantir que o código possuirá testes automatizados e também guiar o desenvolvimento para um código desacoplado e legível.

\n\n

Quando desenvolvemos guiados por testes utilizando TDD praticamos o chamado inside-out (em português, de dentro para fora) ou seja, começamos a testar pelas unidades e módulos internos e deixamos para fazer a integração dessas partes depois.\nComeçar de dentro para fora leva a dúvidas, como: Como saber quando acabou? Será que está testado o suficiente? Será que isso deve ser testado? Ok, Está testado! mas será que quando integrar vai funcionar?\nAssim é muito fácil perder de vista o objetivo do que está sendo desenvolvido.

\n\n

A fraqueza do TDD é induzir os desenvolvedores a testarem o código da maneira que eles entendem ao invés de testar se o código cumpre o que foi requerido pelo negócio.

\n\n

Para contornar esse problema nasceu o BDD, Behaviour Driven Development (desenvolvimento guiado por comportamento). O lançamento do livro “The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends” escrito por David Chelimsky com o apoio do Dan North, que também ajudou na escrita de ferramentas como Rspec, framework de testes para Ruby, e o Cucumber, uma ferramenta de automatização de testes, foi um dos responsáveis pela disseminação do BDD.

\n\n

\nComo o BDD funciona

\n\n

Quando um analista de negócio (também conhecido como BA que vem de Business Analyst) escreve um caso de uso ele detalha como o sistema deve se comportar. Quando ele escreve estórias de usuário ele descreve critérios de aceitação que definem os comportamentos esperados do sistema.

\n\n

O exemplo abaixo demonstra uma estória escrita por um BA para a criação de produtos em uma pagina de admin:

\n\n

1 Feature: Product management\n2 Scenario: User adds a new product\n3   Given I go to the new products page\n4   When I fill the form\n5   And I press submit\n6   Then I should be redirected to a page showing the created product\n

\n\n\n

A principal ideia no exemplo acima é quebrar o cenário em três partes:

\n\n

GIVEN (dado): Descreve o estado inicial, antes de começar o comportamento que está sendo especificado.

\n\n

WHEN (quando): Descreve o comportamento esperado.

\n\n

THEN (então): Descreve as mudanças esperadas baseadas no comportamento.

\n\n

O exemplo anterior utiliza o Cucumber que é uma das ferramentas mais utilizadas para implementação de BDD. A grande vantagem do Cucumber é transformar especificações como a que vimos acima em casos de teste executáveis, permitindo que desenvolvimento, negócio e marketing trabalhem juntos validando se uma determinada funcionalidade está sendo implementada como esperado.\nEsse tipo de ferramenta é utilizada para business facing tests, testes que não serão validados por programadores. Com uma ferramenta que disponibiliza a validação dos comportamentos é possível que clientes, usuários, BA ou qualquer pessoa envolvida verifique se o comportamento esperado está sendo contemplado, quebrando a barreira de comunicação entre desenvolvedores e não desenvolvedores.

\n\n

O GivenWhenThen e o BDD não se prendem a uma ferramenta ou padrão de uso, pode-se utilizar os ensinamentos adotando o que for possível para melhorar a qualidade do que estamos desenvolvendo.\nMesmo não trabalhando em um projeto ágil, onde não existam estórias de usuário nem Cucumber, é possível aplicar técnicas do BDD.

\n\n

\nO outside-in

\n\n

O principal foco do BDD é garantir que o comportamento descrito está sendo contemplado no desenvolvimento e para isso ele trabalha de fora para dentro.

\n\n

Dan North no artigo What’s in a Story diz que:

\n\n

O behaviour-driven development (BDD), é uma metodologia outside-in. Ela começa por fora, identificando as necessidades do negócio e depois parte para a definição das funcionalidades para alcançar essas necessidades. Cada funcionalidade é capturada como uma estória, na qual é definido o escopo da funcionalidade com o seu critério de aceitação.

\n\n

No artigo é possível entender que o BDD funciona de fora para dentro em nível gerencial, mas isso também se aplica ao desenvolvimento da funcionalidade.\nQuando desenvolvemos uma funcionalidade seguindo a metodologia clássica do TDD tendemos a começar desenvolvendo as unidades do sistema, e depois fazer a integração entre elas, essa forma de desenvolver isola camadas e ofusca a visão do objetivo principal, o que realmente é importante para o usuário. É difícil saber se algo está sendo testado o suficiente e se vai funcionar quando integrado com as outras partes do sistema.

\n\n

Aplicando BDD e TDD é possível unir os benefícios do desenvolvimento guiado por testes com o valor do desenvolvimento guiado por comportamento, vamos falar sobre isso no próximo capítulo.

\n\n

\nBDD com Mocha e Chai

\n\n

Mocha e Chai são os módulos que utilizamos no decorrer do livro, ambos baseados no Rspec do Ruby.\nNo exemplo a seguir veremos como utilizar as técnicas do BDD para guiar o desenvolvimento.

\n\n

Exemplo com Mocha:

\n\n

1 describe('Products Management', () => {\n2   describe('when adding products', () => {\n3     it('should save a product into the database', () => {\n4     });\n5   });\n6 });\n

\n\n\n\n

Como vimos no capítulo onde configuramos os testes, utilizamos o describe do Mocha para criar uma suíte de testes. No exemplo acima adicionamos uma suíte principal, que descreve o cenário como um todo, a Products Management, essa suíte de testes vai tratar do gerenciamento de produtos da aplicação.

\n\n

Seguindo o GivenWhenThen adicionamos uma nova suíte que descreve o comportamento esperado: when adding products, ou seja, quando adicionar produtos então devem acontecer as mudanças esperadas.\nPara o Then utilizamos o it do Mocha. O it se refere a um caso de teste, no exemplo acima estabelecemos que: “should save a product into the database” (deve salvar um produto no banco de dados). Tanto o Mocha quanto o Chai são híbridos e permitem aplicar técnicas de TDD e BDD o it por exemplo é inspirado no BDD.

\n\n

Quando executarmos o teste a saída no terminal será:

\n\n

1   Products Management\n2     when adding products\n3       ✓ should save a product into the database\n4 \n5 \n6   1 passing\n

\n\n\n\n

Note que não é necessário nenhum código para entender a intenção desse teste, a maneira como ele foi construído descreve a intenção.

\n\n

O Mocha é um test runner, sua responsabilidade é executar os testes. Para fazer as verificações conhecidas no TDD como asserts (asserções), e no BDD como expectations(expectativas), o Mocha possibilita utilizar módulos externos, como o Chai.

\n\n

O Chai é uma biblioteca que tem a responsabilidade de fazer asserts/expectations, ele foi criado seguindo os princípios de descrição do BDD mas também suporta o TDD.

\n\n

O combo Mocha/Chai ficou conhecido pela forma como os dois se complementam e possibilitam a criação de testes legíveis.\nNo exemplo abaixo adicionamos uma expectation utilizando o Chai:

\n\n

1 describe('Products Management', () => {\n2   describe('when adding products', () => {\n3     it('should save a product into the database', () => {\n4 \n5       expect(Product.save()).to.be.equal(true);\n6     });\n7   });\n8 });\n

\n\n\n\n

O expect faz parte da API do Chai, com ele é possível encadear expectativas. O exemplo acima dispensa explicações, basta traduzir livremente para o português e temos a descrição exata do que está sendo verificado: Espera que Product.save() seja igual a true (verdadeiro).

\n\n\n

\nOperações de CRUD

\n\n

Neste capítulo serão adicionadas as operações de CRUD (Create, Read, Update, Delete) possibilitando a alteração do recurso product.\nSerão aplicadas as técnicas de BDD que foram vistas anteriormente, aqui chamaremos os testes de alto nível de teste de integração end 2 end (de ponta a ponta) ou teste de aceitação. Estes testes irão validar se a funcionalidade foi implementada como esperado.

\n\n

\nBusca por id

\n\n

Um padrão bastante comum em APIs REST é a busca de um recurso pelo identificador (id), por exemplo http://minha_api/products/56cb91bdc3464f14678934ca deve retornar o produto correspondente ao id informado na rota.\nNossa API ainda não suporta essa funcionalidade, então vamos implementá-la.\nComo esse será um novo endpoint precisamos começar pelo teste de integração end 2 end que fica no arquivo: test/integration/routes/products_spec.js

\n\n

Iniciaremos permitindo o reuso de código, tornando-o mais genérico, permitindo assim a reutilização:

\n\n

 1 +  const defaultId = '56cb91bdc3464f14678934ca';\n 2     const defaultProduct = {\n 3       name: 'Default product',\n 4       description: 'product description',\n 5       price: 100\n 6     };\n 7     const expectedProduct = {\n 8      __v: 0,\n 9 -    _id: '56cb91bdc3464f14678934ca',\n10 +    _id: defaultId,\n11      name: 'Default product',\n12      description: '\n

\n\n\n\n

O _id foi extraido do expectedProduct para uma constant isso será útil para testar a rota a seguir.

\n\n

Dentro do cenário de testes: GET /products adicionaremos o seguinte teste:

\n\n

 1  context('when an id is specified', done => {\n 2       it('should return 200 with one product', done => {\n 3 \n 4         request\n 5           .get(`/products/${defaultId}`)\n 6           .end((err, res) => {\n 7             expect(res.statusCode).to.eql(200);\n 8             expect(res.body).to.eql([expectedProduct]);\n 9             done(err);\n10           });\n11       });\n12     });\n

\n\n\n\n

Note que esse caso de teste é similar ao “should return a list of products”, que está dentro do mesmo cenário. Adicionamos um context, pois mesmo sendo no /products agora o foco será o contexto de busca por id onde é feito um GET para “products/56cb91bdc3464f14678934ca”, ou seja filtrando somente um produto.

\n\n

Adicionado o teste, vamos executá-lo:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saida deve ser a seguinte:

\n\n

 1     GET /products\n 2       ✓ should return a list of products\n 3       when an id is specified\n 4         1) should return 200 with one product\n 5 \n 6 \n 7   1 passing (141ms)\n 8   1 failing\n 9 \n10   1) Routes: Products GET /products when an id is specified should return 200 with o\\\n11 ne product:\n12 \n13       Uncaught AssertionError: expected 404 to deeply equal 200\n14       + expected - actual\n15 \n16       -404\n17       +200\n

\n\n\n\n

Quebrou! Agora já temos por onde começar. Era esperado 200, código http de sucesso, e recebemos 404, código http de não encontrado (NOT_FOUND), o que significa que ainda não existe a rota que está sendo requisitada, esse deve ser o primeiro passo a ser implementado.

\n\n

Vamos alterar o arquivo de rotas de produtos: src/routes/products.js, adicionando a seguinte rota:

\n\n

1 router.get('/', (req, res) => productsController.get(req, res));\n2 + router.get('/:id', (req, res) => productsController.getById(req, res));\n

\n\n\n\n

Executando os testes novamente o erro deve ser outro, como o seguinte:

\n\n

1 1) Routes: Products GET /products when an id is specified should return 200 with one\\\n2  product:\n3 \n4       Uncaught AssertionError: expected 500 to deeply equal 200\n5       + expected - actual\n6 \n7       -500\n8       +200\n

\n\n\n\n

500, Internal Server Error: Isso significa que a rota foi encontrada mas houve outro erro ao seguir a requisição, pois não temos mais nada implementado. O próximo passo é adicionar lógica para termos uma resposta.

\n\n

O erro 500 aconteceu pois o método para buscar por id não existe no productsController, agora é o momento de criá-lo. Note que o teste end 2 end serve como um guia para garantir que estamos no caminho certo. Quando a rota foi criada não havia necessidade de testes pois a lógica era simples, já no controller o teste será necessário pois ele vai conter certa lógica. Nesse momento seguimos o ciclo do TDD. Algo como a imagem abaixo:

\n\n\n

\n\n\n

O teste de ponta a ponta é o teste de aceitação, além de guiar o desenvolvimento ele também é responsável por validar se a funcionalidade que estamos desenvolvendo está ou não completa. Esse teste não segue o fluxo do TDD, pois ele será executado inúmeras vezes até que passe, quando ele passar significa que tudo que é necessário para a funcionalidade estar completa foi desenvolvido.

\n\n

Dentro desse grande teste de aceitação serão incluídos inúmeros outros testes, que podem ser de integração, de unidade e etc; esses testes sim seguirão o ciclo do TDD.

\n\n

Os métodos que serão criados no controller seguirão o TDD como já vimos no livro.\nVamos começar melhorando o reaproveitamento de código alterando o teste de unidade test/unit/controllers/products_spec.js:

\n\n

 1 +  const defaultRequest = {\n 2 +    params: {}\n 3 +  };\n 4   \n 5    describe('get() products', () => {\n 6      it('should return a list of products', async () => {\n 7 -      const request = {};\n 8        const response = {\n 9          send: sinon.spy()\n10       };\n

\n\n\n\n

O objeto request foi movido para fora do teste e foi renomeado para defaultRequest para permitir sua reutilização por todos os casos de teste. Também adicionamos um objeto params dentro do defaultRequest para que fique similar ao objeto enviado pelo express.

\n\n

A próxima alteração a ser feita é a requisição para o controller, como alteramos o nome de request para defaultRequest será necessário alterar a seguinte linha:

\n\n

1 -      await productsController.get(request, response);\n2 +      await productsController.get(defaultRequest, response);\n

\n\n\n\n

Pronto, o teste deve estar assim:

\n\n

 1   const defaultRequest = {\n 2     params: {}\n 3   };\n 4 \n 5   describe('get() products', () => {\n 6     it('should return a list of products', async () => {\n 7       const response = {\n 8         send: sinon.spy()\n 9       };\n10 \n11       Product.find = sinon.stub();\n12       Product.find.withArgs({}).resolves(defaultProduct);\n13 \n14       const productsController = new ProductsController(Product);\n15 \n16       await productsController.get(defaultRequest, response);\n17 \n18       sinon.assert.calledWith(response.send, defaultProduct);\n19     }););\n20     });\n

\n\n\n\n

Execute os testes de unidade, eles devem estar passando.

\n\n

 1 $ npm run test:unit\n 2 \n 3 \n 4   Controllers: Products\n 5     get() products\n 6       ✓ should return a list of products\n 7       ✓ should return 400 when an error occurs\n 8 \n 9 \n10   2 passing\n

\n\n\n\n

Testes verdes! Vamos criar o caso de teste para a busca por id, o teste ficará assim:

\n\n

 1   describe('getById()', () => {\n 2     it('should return one product', async () => {\n 3       const fakeId = 'a-fake-id';\n 4       const request = {\n 5         params: {\n 6           id: fakeId\n 7         }\n 8       };\n 9       const response = {\n10         send: sinon.spy()\n11       };\n12 \n13       Product.find = sinon.stub();\n14       Product.find.withArgs({ _id: fakeId }).resolves(defaultProduct);\n15 \n16       const productsController = new ProductsController(Product);\n17       await productsController.getById(request, response);\n18 \n19       sinon.assert.calledWith(response.send, defaultProduct);\n20     });\n21   });\n

\n\n\n\n

O nome “should call send with one product” reflete o cenário que esperamos, ou seja, é esperado que o método send seja chamado com apenas um produto. Dentro do teste é criado uma constant chamada fakeId referente ao id do produto que será buscado.\nLogo após é criado um objeto request igual ao enviado pelo express nas requisições, quando um parâmetro é enviado o express adiciona ele dentro do objeto params, como no código acima onde adicionamos o id como parâmetro.\nA Próxima parte do código do teste que devemos dar atenção é esta:

\n\n

1 Product.find.withArgs({ _id: fakeId }).resolves(defaultProduct);\n

\n\n\n\n

Aqui é utilizado o stub do método find para adicionar um comportamento sempre que ele for chamado recebendo o parâmetro _id com o valor do fakeId. O _id é a chave primária do MongoDB então para fazer o filtro por id precisamos fazer uma busca pela chave _id.\nO método withArgs do stub do Sinon serve para adicionar um comportamento baseado em uma condição, no nosso caso quando o método find for chamado com o parâmetro _id com o valor do fakeId ele deve resolver uma Promise retornando o defaultProduct, simulando assim uma chamada ao banco de dados.

\n\n

O método que será chamado é o getById, como no trecho abaixo:

\n\n

1 await productsController.getById(request, response);\n

\n\n\n\n

Vamos executar os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

Devemos receber o seguinte erro:

\n\n

 1 Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       1) should call send with one product\n 7 \n 8 \n 9   2 passing (22ms)\n10   1 failing\n11 \n12   1) Controller: Products getById() should call send with one product:\n13      TypeError: productsController.getById is not a function\n

\n\n\n\n

O erro diz que o método getById não é uma , isso porque ainda não foi implementada a lógica, o stub que criamos não foi chamado e não retornou uma Promise. \nVamos mudar o teste de unidade para o passo GREEN implementando o necessário para que o mesmo passe.

\n\n

Devemos criar o método getById no controller de products que fica em: src/controllers/products.js.\nO código suficiente para o teste passar contém:

\n\n

 1   async getById(req, res) {\n 2     const response = await Promise.resolve([\n 3       {\n 4         __v: 0,\n 5         _id: '56cb91bdc3464f14678934ca',\n 6         name: 'Default product',\n 7         description: 'product description',\n 8         price: 100\n 9       }\n10     ]);\n11 \n12     res.send(response);\n13   }\n

\n\n\n\n

O trecho acima retorna uma Promise resolvida com um array contendo um produto fake, igual o que esperamos no caso de teste, e após o método send é chamado com esse produto.

\n\n

Executando os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A resposta deve ser:

\n\n

1   Controller: Products\n2     get() products\n3       ✓ should return a list of products\n4       ✓ should return 400 when an error occurs\n5     getById()\n6       ✓ should call send with one product\n7 \n8 \n9   3 passing (20ms)\n

\n\n\n\n

Teste unitário passando! Agora ele está no passo GREEN do TDD. Podemos partir para o REFACTOR.

\n\n

Vamos alterar o método getById em src/controllers/products.js para ficar similar a este:

\n\n

 1   async getById(req, res) {\n 2     const {\n 3       params: { id }\n 4     } = req;\n 5 \n 6     try {\n 7       const product = await this.Product.find({ _id: id });\n 8       res.send(product);\n 9     } catch (err) {\n10       res.status(400).send(err.message);\n11     }\n12   }\n

\n\n\n\n

Na primeira linha extraímos o id do objeto params dentro de req e no método find do mongoose adicionamos um filtro por id.

\n\n

Realizada a alteração basta executar os testes novamente, começando pelo teste de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n

A saida deve ser:

\n\n

1   Controller: Products\n2     get() products\n3       ✓ should return a list of products\n4       ✓ should return 400 when an error occurs\n5     getById()\n6       ✓ should call send with one product\n7 \n8 \n9   3 passing (17ms)\n

\n\n\n\n

Após os testes de unidade, devemos executar nosso teste end 2 end para validar:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saida deve ser:

\n\n

1   Routes: Products\n2     GET /products\n3       ✓ should return a list of products\n4       when an id is specified\n5         ✓ should return 200 with one product\n6 \n7 \n8   2 passing (152ms)\n

\n\n\n\n

O teste passou! Ou seja, nossa funcionalidade está implementada. Não se preocupe se ainda está meio confuso. Vamos aplicar esse conceito no decorrer do livro para a criação dos outros endpoints da API, aqui o objetivo é mostrar como o BDD e o TDD trabalham juntos e como a combinação dos dois ajuda no desenvolvimento criando um visão do que deve ser desenvolvido.

\n\n\n

\nCriando um recurso

\n\n

Nos passos anteriores trabalhamos nas buscas para listar todos os produtos e também filtrar por apenas um produto.\nNesta etapa vamos trabalhar na criação de produtos na API.

\n\n

Começaremos adicionando um teste de integração end 2 end no arquivo test/integration/routes/products_spec.js com o seguinte código:

\n\n

 1    describe('POST /products', () => {\n 2     context('when posting a product', () => {\n 3 \n 4       it('should return a new product with status code 201', done => {\n 5         const customId = '56cb91bdc3464f14678934ba';\n 6         const newProduct = Object.assign({},{ _id: customId, __v:0 }, defaultProduct\\\n 7 );\n 8         const expectedSavedProduct = {\n 9           __v: 0,\n10           _id: customId,\n11           name: 'Default product',\n12           description: 'product description',\n13           price: 100\n14         };\n15 \n16         request\n17           .post('/products')\n18           .send(newProduct)\n19           .end((err, res) => {\n20             expect(res.statusCode).to.eql(201);\n21             expect(res.body).to.eql(expectedSavedProduct);\n22             done(err);\n23           });\n24       });\n25     });\n26   });\n

\n\n\n\n

Usamos um novo describe pois separamos os cenários de testes por recursos da API, isso facilita a legibilidade e entendimento dos testes.\nO nosso teste deve criar um produto e retornar 201, com o produto criado.\nNote que é criado um customId e logo após sobrescrevemos o id do defaultProduct pelo customId usando Object.assign, para copiar o objeto e atribuir um novo valor ao id. Isso é necessário porque um novo produto será criado e ele precisa ter um id diferente do defaultProduct que já foi criado no beforeEach.

\n\n

Em seguida criamos o expectedSavedProduct. Este é o objeto referente ao que esperamos que a rota de criação de produtos devolva no teste.

\n\n

Na sequência, utilizamos o supertest para realizar um HTTP POST para a rota /products da API, enviando o objeto newProduct, anteriormente criado.

\n\n

Quando a requisição terminar a resposta será validada:

\n\n

1 expect(res.statusCode).to.eql(201);\n2 expect(res.body).to.eql(expectedSavedProduct);\n

\n\n\n\n

O teste vai verificar se a resposta da requisição é igual ao expectedSavedProduct, e o código http é igual a 201. Se sim, nosso produto foi criado com sucesso.

\n\n

Executando os testes de integração, conforme:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

Teremos a seguinte resposta:

\n\n

 1  Routes: Products\n 2     GET /products\n 3       ✓ should return a list of products\n 4       when an id is specified\n 5         ✓ should return 200 with one product\n 6     POST /products\n 7       when posting a product\n 8         1) should return a new product with status code 201\n 9 \n10 \n11   2 passing (179ms)\n12   1 failing\n13 \n14   1) Routes: Products POST /products when posting a product should return a new prod\\\n15 uct with status code 201:\n16 \n17       Uncaught AssertionError: expected 404 to deeply equal 201\n18       + expected - actual\n19 \n20       -404\n21       +201\n

\n\n\n\n

Já vimos esse cenário antes: esperávamos 200 e recebemos 404, ou seja, a rota não foi encontrada.\nVamos adicioná-la no arquivo src/routes/products.js

\n\n

1 router.get('/', (req, res) => productsController.get(req, res));\n2 router.get('/:id', (req, res) => productsController.getById(req, res));\n3 + router.post('/', (req, res) => productsController.create(req, res));\n

\n\n\n\n

Executando os testes novamente a saída deve ser:

\n\n

1       Uncaught AssertionError: expected 500 to deeply equal 201\n2       + expected - actual\n3 \n4       -500\n5       +201\n

\n\n\n\n

Erro interno! É hora de implementar o controller.

\n\n

Abra o teste de unidade em test/unit/controllers/products_spec.js e adicione o seguinte teste:

\n\n

 1   describe('create() product', () => {\n 2     it('should save a new product successfully', async () => {\n 3       const requestWithBody = Object.assign(\n 4         {},\n 5         { body: defaultProduct[0] },\n 6         defaultRequest\n 7       );\n 8       const response = {\n 9         send: sinon.spy(),\n10         status: sinon.stub()\n11       };\n12       class fakeProduct {\n13         save() {}\n14       }\n15 \n16       response.status.withArgs(201).returns(response);\n17       sinon\n18         .stub(fakeProduct.prototype, 'save')\n19         .withArgs()\n20         .resolves();\n21 \n22       const productsController = new ProductsController(fakeProduct);\n23 \n24       await productsController.create(requestWithBody, response);\n25       sinon.assert.calledWith(response.send);\n26     });\n27   });\n

\n\n\n\n

Para simular um objeto de request do express precisamos de um objeto que possua além das propriedades do defaultRequest também um body que contenha os dados enviados por post. Para isso é criado o requestWithBody, um novo objeto criado a partir dos dados padrão de request que usamos nos testes anteriores e adicionado um body com o defaultProduct.\nDessa maneira possuímos uma requisição de post idêntica a enviada pelo express.

\n\n

Os objetos response e fakeProduct seguem o mesmo padrão dos outros casos de teste. A única mudança é:

\n\n

1 response.status.withArgs(201).returns(response);\n

\n\n\n\n

Aqui definimos que response.status deve ser chamado com 201, ou seja, que o recurso foi criado com sucesso;\nPara simular a ação de save no banco pelo model do mongoose adicionamos o seguinte stub:

\n\n

1 sinon.stub(fakeProduct.prototype, 'save').withArgs().resolves();\n

\n\n\n\n

Quando o método save do fakeProduct for chamado com qualquer argumento, ele vai retornar uma Promise resolvida.

\n\n

Já temos os testes necessários e podemos rodar os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A saída será:

\n\n

 1     Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       1) should save a new product successfully\n 9 \n10 \n11   3 passing (22ms)\n12   1 failing\n13 \n14   1) Controller: Products create() product should save a new product successfully:\n15      TypeError: productsController.create is not a function\n

\n\n\n\n

Ainda não criamos o método create no controller, esse será o nosso próximo passo.\nVamos criar um método create no productsController:

\n\n

1   async create(req, res) {\n2 \n3     return await Promise.resolve(res.send(req.body));\n4   }\n

\n\n\n\n

No teste verificamos se o response.send está sendo chamado com um produto criado, e esperamos por uma Promise. Essa é a menor implementação possível para atender ao teste. Ao executar os testes de unidade novamente devemos ter a seguinte resposta:

\n\n

 1   Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9 \n10 \n11   4 passing (26ms)\n

\n\n\n\n

Estamos no estado GREEN dos testes de unidade. Vamos partir para o REFACTOR alterando o productsController, adicionando o seguinte:

\n\n

1   async create(req, res) {\n2     const product = new this.Product(req.body);\n3 \n4     await product.save();\n5     res.status(201).send(product);\n6   }\n

\n\n\n\n

Após a alteração o teste deve estar passando com sucesso. Agora é necessário testar o caso de erro que é muito importante na hora de criar algum recurso.

\n\n

Para testar um caso de erro precisamos que o método de criação de produto do ProductsController retorne um erro. Podemos criar este cenário tanto no teste de integração end 2 end quanto no teste de unidade. Como o teste de integração cobre a rota que recebe a resposta do controller e envia para o usuário, é indiferente a resposta que ele vai receber, independente de ser sucesso ou erro ela apenas será repassada.\nPara testarmos esse cenário com mais assertividade e mais controle dos componentes envolvidos vamos testar somente de forma unitária.\nNos próximos capítulos vamos ver algumas maneiras de trabalhar com erros em testes de integração, mas neste momento vamos focar no nível unitário.

\n\n

Adicione o seguinte teste no arquivo test/unit/controllers/products_spec.js:

\n\n

 1     context('when an error occurs', () => {\n 2       it('should return 422', async () => {\n 3         const response = {\n 4           send: sinon.spy(),\n 5           status: sinon.stub()\n 6         };\n 7 \n 8         class fakeProduct {\n 9           save() {}\n10         }\n11 \n12         response.status.withArgs(422).returns(response);\n13         sinon\n14           .stub(fakeProduct.prototype, 'save')\n15           .withArgs()\n16           .rejects({ message: 'Error' });\n17 \n18         const productsController = new ProductsController(fakeProduct);\n19 \n20         await productsController.create(defaultRequest, response);\n21         sinon.assert.calledWith(response.status, 422);\n22       });\n23     });\n

\n\n\n\n

Imagino que vocês já estejam treinados em escrever testes usando o Sinon. O caso de teste acima informa que esse teste deve retornar o código 422 quando acontecer um erro na criação de um novo produto.

\n\n

Segundo a especificação do HTTP 1.1 o código 422 faz parte dos grupos de erro 4xx e significa “Unprocessable Entity” ou seja, a entidade não pode ser processada. Esse código de erro é utilizado para cenários onde a requisição foi recebida pelo servidor mas os dados não puderam ser validados.\nUm exemplo clássico é o caso do email, o usuário pode ter enviado os dados corretamente, mas o email é inválido. O servidor deve responder com 422, informando que recebeu os dados mas não conseguiu validar.

\n\n

Para simular um caso de erro precisamos fazer com que o método de save do Mongoose retorne um erro. Como ele é uma Promise basta rejeitarmos o stub, como é feito aqui:

\n\n

1 sinon.stub(fakeProduct.prototype, 'save').withArgs().rejects({ message: 'Error' });\n

\n\n\n\n

Executando os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A saida será:

\n\n

 1   Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         1) should return 422\n11 \n12 \n13   4 passing (26ms)\n14   1 failing\n15 \n16   1) Controller: Products create() product when an error occurs should return 422:\n17      Error\n

\n\n\n\n

Como já era esperado recebemos um erro, pois ainda não implementamos essa lógica.\nVamos atualizar o método create no ProductsController e adicionar um catch para pegar o erro quando caso ele ocorra:

\n\n

1   async create(req, res) {\n2     const product = new this.Product(req.body);\n3 +    try {\n4       await product.save();\n5       res.status(201).send(product);\n6 +    } catch (err) {\n7 +      res.status(422).send(err.message);\n8 +    }\n9   }\n

\n\n\n\n

Executando os testes novamente, a saída deve ser:

\n\n

 1   Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11 \n12 \n13   5 passing (28ms)\n

\n\n\n\n

Perfeito! Nossa rota de criação de produtos está pronta.\nVamos nos certificar de que a implementação da funcionalidade está correta executando o teste end 2 end:

\n\n

 1 $ npm run test:integration\n 2 \n 3 Routes: Products\n 4     GET /products\n 5       ✓ should return a list of products\n 6       when an id is specified\n 7         ✓ should return 200 with one product\n 8     POST /products\n 9       when posting a product\n10         ✓ should return a new product with status code 201\n11 \n12 \n13   3 passing (169ms)\n

\n\n\n\n\n

\nAtualizando um recurso

\n\n

Já é possível criar e listar produtos na nossa API, o próximo passo é a edição. Como de costume, vamos começar pelo teste end 2 end descrevendo o comportamento esperado dessa funcionalidade.

\n\n

Adicione o seguinte cenário contendo um caso de teste no arquivo test/integration/routes/products_spec.js

\n\n

 1   describe('PUT /products/:id', () => {\n 2     context('when editing a product', () => {\n 3       it('should update the product and return 200 as status code', done => {\n 4         const customProduct = {\n 5           name: 'Custom name'\n 6         };\n 7         const updatedProduct = Object.assign({}, customProduct, defaultProduct)\n 8 \n 9         request\n10           .put(`/products/${defaultId}`)\n11           .send(updatedProduct)\n12           .end((err, res) => {\n13             expect(res.status).to.eql(200);\n14             done(err);\n15           });\n16       });\n17     });\n18   });\n

\n\n\n\n

Esse teste é muito similar ao teste de criação de produto, a única alteração é o verbo e a rota para a qual a requisição é feita, conforme o seguinte trecho de código:

\n\n

1       .put(`/products/${defaultId}`)\n

\n\n\n\n

Segundo o Rest, para a criação de um novo recurso utilizamos o verbo POST e para a atualização de um recurso devemos utilizar PUT.

\n\n

O produto que será atualizado é o defaultProduct, este produto é criado antes de cada teste pelo beforeEach. Para não atualizar o defaultProduct diretamente vamos criar um objeto a partir dele usando Object.assign:

\n\n

1  const updatedProduct = Object.assign({}, customProduct, defaultProduct)\n

\n\n\n\n

Executando os testes de integração:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saída deve ser:

\n\n

 1    Routes: Products\n 2     GET /products\n 3       ✓ should return a list of products\n 4       when an id is specified\n 5         ✓ should return 200 with one product\n 6     POST /products\n 7       when posting a product\n 8         ✓ should return a new product with status code 201\n 9     PUT /products/:id\n10       when editing a product\n11         1) should update the product and return 200 as status code\n12 \n13 \n14   3 passing (403ms)\n15   1 failing\n16 \n17   1) Routes: Products PUT /products/:id when editing a product should update the pro\\\n18 duct and return 200 as status code:\n19 \n20       Uncaught AssertionError: expected 404 to deeply equal 200\n21       + expected - actual\n22 \n23       -404\n24       +200\n

\n\n\n\n

O teste retornar que esperava 200 (sucesso) mas recebeu 404 (não encontrado), como já esperávamos. \nVamos alterar o arquivo src/routes/products.js e adicionar a seguinte rota:

\n\n

1 + router.put('/:id', (req, res) => productsController.update(req, res)); \n

\n\n\n\n

Executando os testes novamente a saída deve ser:

\n\n

1   1) Routes: Products PUT /products/:id when editing a product should update the pro\\\n2 duct and return 200 as status code:\n3 \n4       Uncaught AssertionError: expected 500 to deeply equal 200\n5       + expected - actual\n6 \n7       -500\n8       +200\n

\n\n\n\n

É hora de descer para o nível de unidade para fazer a implementação no controller.\nVamos adicionar o seguinte cenário de teste unitário em test/unit/controllers/products_spec.js

\n\n

 1   describe('update() product', () => {\n 2     it('should respond with 200 when the product has been updated', async () => {\n 3       const fakeId = 'a-fake-id';\n 4       const updatedProduct = {\n 5         _id: fakeId,\n 6         name: 'Updated product',\n 7         description: 'Updated description',\n 8         price: 150\n 9       };\n10       const request = {\n11         params: {\n12           id: fakeId\n13         },\n14         body: updatedProduct\n15       };\n16       const response = {\n17         sendStatus: sinon.spy()\n18       };\n19 \n20       class fakeProduct {\n21         static updateOne() {}\n22       }\n23 \n24       const updateOneStub = sinon.stub(fakeProduct, 'updateOne');\n25       updateOneStub\n26         .withArgs({ _id: fakeId }, updatedProduct)\n27         .resolves(updatedProduct);\n28 \n29       const productsController = new ProductsController(fakeProduct);\n30 \n31       await productsController.update(request, response);\n32       sinon.assert.calledWith(response.sendStatus, 200);\n33     });\n34   });\n

\n\n\n\n

Este teste é maior, mas não há nada que já não tenhamos feito em outros testes. A chave para o update de um recurso é o id dele. Criamos uma constant chamada fakeId para poder reutilizá-lo em outras partes do teste, em seguida criamos um objeto chamado updatedProduct que representa o produto que será atualizado pelo Mongoose.

\n\n

Para simular a requisição que será feita pelo express criamos um objeto com as mesmas chaves que o express envia na requisição, como podemos ver aqui:

\n\n

1       const request = {\n2         params: {\n3           id: fakeId\n4         },\n5         body: updatedProduct\n6       };\n

\n\n\n\n

O método do Mongoose que utilizaremos para atualizar o recurso é o updateOne, segundo a documentação é necessário passar o _id e o objeto que queremos atualizar.\nPara testar isoladamente criamos um model fake, o fakeProduct, que possui o método a seguir:

\n\n

1       class fakeProduct {\n2         static updateOne() {}\n3       }\n

\n\n\n\n

Para adicionar o comportamento esperado no método updateOne vamos transformá-lo em um stub:

\n\n

1       const updateOneStub = sinon.stub(fakeProduct, 'updateOne');\n

\n\n\n\n

Depois, definimos que quando o stub for chamado com um objeto que contenha uma chave _id e um objeto igual ao updatedProduct, ele deve resolver uma Promise:

\n\n

1 updateOneStub.withArgs({ _id: fakeId }, updatedProduct).resolves(updatedProduct);\n

\n\n\n\n

Segundo a documentação do Mongoose, o método updateOne não retorna valor, por isso a Promise não irá retornar nada, somente será resolvida para dar sucesso.

\n\n

Executando os testes de unidade:

\n\n

1 $ npm run test:unit \n

\n\n\n\n

Vamos ter a seguinte saída:

\n\n

 1   Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       1) should respond with 200 when the product is updated\n13 \n14 \n15   5 passing (38ms)\n16   1 failing\n17 \n18   1) Controller: Products update() product should respond with 200 when the product \\\n19 is updated:\n20      TypeError: productsController.update is not a function\n21       at Context.it (test/unit/controllers/products_spec.js:154:\n

\n\n\n\n

O teste retorna que o método update não existe, então vamos adicioná-lo com lógica suficiente apenas para que ele passe:

\n\n

1 \tasync update(req, res) {\n2 \t\tres.sendStatus(200);\n3 \t\treturn await Promise.resolve();\n4 \t}\n

\n\n\n\n

No teste acima esperamos que o objeto response do express seja chamado com 200, o que garante que o produto foi atualizado. Essa é a implementação mínima para fazer o teste passar.

\n\n

Executando os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

Devemos ter a seguinte saída:

\n\n

 1  Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13 \n14 \n15   6 passing (37ms)\n

\n\n\n\n

Vamos à refatoração, o código do método update deve ficar assim:

\n\n

1   async update(req, res) {\n2     await this.Product.updateOne({ _id: req.params.id}, req.body);\n3     res.sendStatus(200);\n4   }\n

\n\n\n\n

Vamos executar os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

A saida deve ser:

\n\n

 1    Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13 \n14 \n15   6 passing (27ms)\n

\n\n\n\n

Também vamos executar os testes de integração end 2 end:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saída deve ser:

\n\n

 1   Routes: Products\n 2     GET /products\n 3       ✓ should return a list of products\n 4       when an id is specified\n 5         ✓ should return 200 with one product\n 6     POST /products\n 7       when posting a product\n 8         ✓ should return a new product with status code 201\n 9     PUT /products/:id\n10       when editing a product\n11         ✓ should update the product and return 200 as status code\n12 \n13 \n14   4 passing (184ms)\n

\n\n\n\n

Todos os testes estão passando e a atualização de produtos está funcionando. O próximo passo é adicionar um teste para o caso de algum erro acontecer, similar ao que já foi feito na criação de produtos.

\n\n

Vamos atualizar o teste test/unit/controllers/products_spec.js adicionando o seguinte caso de teste dentro do cenário update:

\n\n

 1     context('when an error occurs', () => {\n 2       it('should return 422', async() => {\n 3         const fakeId = 'a-fake-id';\n 4         const updatedProduct = {\n 5           _id: fakeId,\n 6           name: 'Updated product',\n 7           description: 'Updated description',\n 8           price: 150\n 9         };\n10         const request = {\n11           params: {\n12             id: fakeId\n13           },\n14           body: updatedProduct\n15         };\n16         const response = {\n17           send: sinon.spy(),\n18           status: sinon.stub()\n19         };\n20 \n21         class fakeProduct {\n22           static updateOne() {}\n23         }\n24 \n25         const updateOneStub = sinon.stub(\n26           fakeProduct,\n27           'updateOne'\n28         );\n29         updateOneStub\n30           .withArgs({ _id: fakeId }, updatedProduct)\n31           .rejects({ message: 'Error' });\n32         response.status.withArgs(422).returns(response);\n33 \n34         const productsController = new ProductsController(fakeProduct);\n35 \n36         await productsController.update(request, response);\n37         sinon.assert.calledWith(response.send, 'Error');\n38 \n39         });\n40       });\n

\n\n\n\n

Não há nada de novo comparado a o que foi feito no create, foi utilizada a mesma técnica de stub como podemos ver aqui:

\n\n

1 updateOneStub.withArgs({ _id: fakeId }, updatedProduct).rejects({ message: 'Error' }\\\n2 );\n

\n\n\n\n

Ao executar os testes de unidade:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

Devemos ter a seguinte saída:

\n\n

 1   Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13       when an error occurs\n14         1) should return 422\n15 \n16 \n17   6 passing (26ms)\n18   1 failing\n19 \n20   1) Controller: Products update() product when an error occurs should return 422:\n21      Error\n

\n\n\n\n

Como já esperávamos, o teste está falhando. Vamos atualizar método update do productsController adicionando o método método catch:

\n\n

1   async update(req, res) {\n2 +    try {\n3       await this.Product.updateOne({ _id: req.params.id }, req.body);\n4       res.sendStatus(200);\n5 +    } catch (err) {\n6 +      res.status(422).send(err.message);\n7 +    }\n8   }\n

\n\n\n\n

Executando os testes novamente, a saída deve ser:

\n\n

 1    Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13       when an error occurs\n14         ✓ should return 422\n15 \n16 \n17   7 passing (46ms)\n

\n\n\n\n

Note que não fizemos o processo GREEN, isso porque a implementação era clara e simples. Não é necessário escrever código por obrigação, o estágio de Green serve para ajudar e validar o teste.

\n\n\n

\nDeletando um recurso

\n\n

Já temos o C.R.U do CRUD, o último passo é o DELETE que vai permitir a remoção de recursos da API.

\n\n

Como sempre, começamos pelo teste de integração end 2 end em test/integration/routes/products_spec.js

\n\n

 1   describe('DELETE /products/:id', () => {\n 2     context('when deleting a product', () => {\n 3       it('should delete a product and return 204 as status code', done => {\n 4 \n 5         request\n 6           .delete(`/products/${defaultId}`)\n 7           .end((err, res) => {\n 8             expect(res.status).to.eql(204);\n 9             done(err);\n10           });\n11       });\n12     });\n13   });\n

\n\n\n\n

Dessa vez enviamos uma requisição do tipo DELETE:

\n\n

1       .delete(`/products/${defaultId}`)\n

\n\n\n\n

Passando um id de produto. Segundo a especificação do HTTP/1.1 o método delete serve para deletar um recurso do servidor com base na url enviada. A documentação também diz que as respostas podem ser: 200 - a resposta contém um corpo, 202 se a ação não vai ser realizada agora (vai ocorrer em background) ou 204 quando não há retorno, somente a notificação de sucesso.\nNa maioria das APIs Rest é comum o uso do código 204. Ele é um código de sucesso utilizado para momentos onde é necessário notificar o sucesso, mas a resposta não vai ter dados.

\n\n

Após adicionar o teste, vamos executar os testes:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saída deve ser a seguinte:

\n\n

 1     Routes: Products\n 2     GET /products\n 3       ✓ should return a list of products\n 4       when an id is specified\n 5         ✓ should return 200 with one product\n 6     POST /products\n 7       when posting a product\n 8         ✓ should return a new product with status code 201\n 9     PUT /products/:id\n10       when editing a product\n11         ✓ should update the product and return 200 as status code\n12     DELETE /products/:id\n13       when deleting a product\n14         1) should delete a product and return 204 as status code\n15 \n16 \n17   4 passing (221ms)\n18   1 failing\n19 \n20   1) Routes: Products DELETE /products/:id when deleting a product should delete a p\\\n21 roduct and return 204 as status code:\n22 \n23       Uncaught AssertionError: expected 404 to deeply equal 204\n24       + expected - actual\n25 \n26       -404\n27       +204\n

\n\n\n\n

Como esperado, temos como retorno o código 404 (Not Found). Vamos adicionar a rota no arquivo src/routes/products.js.

\n\n

1 + router.delete('/:id', (req, res) => productsController.remove(req, res));\n

\n\n\n

Executando os testes novamente o retorno deve ser:

\n\n

1  1) Routes: Products DELETE /products/:id when deleting a product should delete a pr\\\n2 oduct and return 204 as status code:\n3 \n4       Uncaught AssertionError: expected 500 to deeply equal 204\n5       + expected - actual\n6 \n7       -500\n8       +204\n

\n\n\n\n

Agora é hora de adicionar os testes de unidade para o controller. No arquivo test/unit/controllers/products_spec.js adicione o seguinte cenário de teste com o caso de teste a seguir:

\n\n

 1   describe('delete() product', async() => {\n 2     it('should respond with 204 when the product has been deleted', () => {\n 3       const fakeId = 'a-fake-id';\n 4       const request = {\n 5         params: {\n 6           id: fakeId\n 7         }\n 8       };\n 9       const response = {\n10         sendStatus: sinon.spy()\n11       };\n12 \n13       class fakeProduct {\n14         static deleteOne() {}\n15       }\n16 \n17       const deleteOneStub = sinon.stub(fakeProduct, 'deleteOne');\n18 \n19       deleteOneStub.withArgs({ _id: fakeId }).resolves();\n20 \n21       const productsController = new ProductsController(fakeProduct);\n22 \n23       await productsController.remove(request, response);\n24       sinon.assert.calledWith(response.sendStatus, 204);\n25       });\n26   });\n

\n\n\n\n

O método utilizado para remover um produto é o deleteOne, segundo a documentação do Mongoose ele recebe por parametro as condições para deletar o item, no nosso caso o id.\nPara simular esse cenário vamos criar o seguinte stub no código acima:

\n\n

1       deleteOneStub.withArgs({ _id: fakeId }).resolves([1]);\n

\n\n\n\n

Aqui informamos que quando o método deleteOne for chamado com um _id igual ao fakeId deve resolver uma Promise devolvendo um array com 1 elemento.

\n\n

Executando os testes de unidade devemos ter a seguinte saída:

\n\n

 1    Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13       when an error occurs\n14         ✓ should return 422\n15     delete() product\n16       1) should respond with 204 when the product is deleted\n17 \n18 \n19   7 passing (46ms)\n20   1 failing\n21 \n22   1) Controller: Products delete() product should respond with 204 when the product \\\n23 is deleted:\n24      TypeError: productsController.remove is not a function\n25       at Context.it (test/unit/controllers/products_spec.js:220:33)\n

\n\n\n\n

O método remove não foi encontrado, então vamos criá-lo no ProductsController, o código deve ficar assim:

\n\n

1 \tasync remove(req, res) {\n2 \t\tres.sendStatus(204);\n3 \t\treturn await Promise.resolve();\n4 \t}\n

\n\n\n\n

Executando os testes de unidade, devemos ter a seguinte saída:

\n\n

 1     Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13       when an error occurs\n14         ✓ should return 422\n15     delete() product\n16       ✓ should respond with 204 when the product is deleted\n17 \n18 \n19   8 passing (32ms)\n

\n\n\n\n

Agora no passo de refatoração adicionaremos a lógica real do método:

\n\n

1   async remove(req, res) {\n2     await this.Product.deleteOne({ _id: req.params.id });\n3     res.sendStatus(204);\n4   }\n

\n\n\n\n

Ambos os testes devem seguir passando com sucesso.

\n\n

O último passo é o tratamento dos possíveis erros.\nNos testes de unidade vamos adicionar o seguinte teste dentro do cenário do método remove:

\n\n

 1     context('when an error occurs', () => {\n 2       it('should return 400', async() => {\n 3         const fakeId = 'a-fake-id';\n 4         const request = {\n 5           params: {\n 6             id: fakeId\n 7           }\n 8         };\n 9         const response = {\n10           send: sinon.spy(),\n11           status: sinon.stub()\n12         };\n13 \n14         class fakeProduct {\n15           static deleteOne() {}\n16         }\n17 \n18         const deleteOneStub = sinon.stub(fakeProduct, 'deleteOne');\n19 \n20         deleteOneStub.withArgs({ _id: fakeId }).rejects({ message: 'Error' });\n21         response.status.withArgs(400).returns(response);\n22 \n23         const productsController = new ProductsController(fakeProduct);\n24 \n25         await productsController.remove(request, response);\n26         sinon.assert.calledWith(response.send, 'Error');\n27       });\n28     });\n

\n\n\n\n

Executando os testes de unidade devemos ter a seguinte saída:

\n\n

 1   Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13       when an error occurs\n14         ✓ should return 422\n15     delete() product\n16       ✓ should respond with 204 when the product is deleted\n17       when an error occurs\n18         1) should return 400\n19 \n20 \n21   8 passing (35ms)\n22   1 failing\n23 \n24   1) Controller: Products delete() product when an error occurs should return 400:\n25      Error\n

\n\n\n\n

A implementação ficará da seguinte maneira:

\n\n

1   async remove(req, res) {\n2     try {\n3       await this.Product.deleteOne({ _id: req.params.id });\n4       res.sendStatus(204);\n5     } catch (err) {\n6       res.status(422).send(err.message);\n7     }\n8   }\n

\n\n\n\n

Note que agora retornamos 400 e não mais 422, 400 significa Bad Request e é um erro genérico, como o delete não recebe e nem valida dados não caberia utilizar o código 422.

\n\n

Executando os testes de unidade agora a saída deve ser:

\n\n

 1    Controller: Products\n 2     get() products\n 3       ✓ should return a list of products\n 4       ✓ should return 400 when an error occurs\n 5     getById()\n 6       ✓ should return one product\n 7     create() product\n 8       ✓ should save a new product successfully\n 9       when an error occurs\n10         ✓ should return 422\n11     update() product\n12       ✓ should respond with 200 when the product is updated\n13       when an error occurs\n14         ✓ should return 422\n15     delete() product\n16       ✓ should respond with 204 when the product is deleted\n17       when an error occurs\n18         ✓ should return 400\n19 \n20 \n21   9 passing (50ms)\n

\n\n\n\n

Pronto! As operações de CRUD para o recurso de produtos estão prontas. O código dessa parte pode ser encontrado neste link.

\n\n\n

\nConfiguração por ambiente

\n\n

Antes de seguir adicionando funcionalidades a nossa API vamos fazer algumas melhorias. Como temos testes que nos garantem confiança no código, podemos melhorar o design do nosso código sempre que preciso, buscando sempre evoluir a arquitetura.\nVamos começar pelo simples (sempre!), evitando complexidades antes que elas sejam realmente necessárias, e vamos evoluindo a arquitetura conforme a demanda.\nNos próximos capítulos vamos adicionar autenticação e migrações de banco de dados, também teremos algumas configurações que precisarão ser feitas.

\n\n

Essas modificações tornam necessário mover o nosso diretório de config para fora de src, assim será possível o reuso das configurações do ambiente; essa parte ficará mais clara durante a implementação.

\n\n

\nAlterando a arquitetura

\n\n

Vamos começar movendo o arquivo database.js para o raiz do diretório src e a pasta src/config para fora do diretório src, a estrutura deve ficar como a seguir:

\n\n

1 ├── config\n2 ├── src\n3 │   ├── app.js\n4 │   ├── controllers\n5 │   ├── database.js\n6 │   ├── models\n7 │   ├── routes\n8 │   └── server.js\n9 └── test\n

\n\n\n\n

Feito isso vamos executar os testes:

\n\n

1 $ npm run test:unit\n

\n\n\n\n

Os testes de unidade devem estar passando, agora executaremos os testes de integração:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

Os testes de integração vão quebrar pois o arquivo de configuração não foi encontrado. Vamos fazer as atualizações necessárias para que o código passe a utilizar a configuração a partir do diretório correto.

\n\n

Vamos alterar o arquivo src/app.js da seguinte maneira:

\n\n

1 -import database from './config/database'\n2 +import database from './database';\n

\n\n\n\n

Ao executar os testes de integração novamente eles devem passar.

\n\n

\nConfigurações por ambiente

\n\n

Provavelmente nossa aplicação irá rodar em vários ambientes, como desenvolvimento, homologação, produção e também teste. Muitas configurações são específicas por ambiente, como por exemplo o nome/url do banco de dados que vai ser diferente entre os ambientes, e isso deve ser fácil de ser configurado e versionado.\nPara nos ajudar nessa missão utilizaremos o módulo node-config.

\n\n

\nUtilizando o módulo node-config

\n\n

O módulo config suporta múltiplos ambientes, variáveis de ambiente e muitas outras formas de configuração, o que é muito útil na hora de criar aplicações que irão rodar na nuvem ou até mesmo em diferentes servidores.\nPara começar, vamos instalar o módulo config com o seguinte comando:

\n\n

1 $ npm install config@1.29.4\n

\n\n\n\n

Após a instalação precisamos fazer a configuração. No próprio repositorio no github https://github.com/lorenwest/node-config temos uma vasta documentação de como configurar. Resumindo: será necessário criar um arquivo json para cada ambiente e neste arquivo adicionar as propriedades que queremos. Por padrão ele espera que os arquivos de configuração estejam dentro do diretório config, na raiz do projeto, por isso a mudança na arquitetura foi necessária.

\n\n

Vamos começar criando uma configuração padrão para a nossa API, caso não tenha um arquivo específico para o ambiente o diretório config será utilizado.\nVamos criar o arquivo default.json no diretório config/.\nNeste arquivo teremos a seguinte instrução:

\n\n

1 {\n2   \"database\": {\n3     \"mongoUrl\": \"mongodb://localhost:27017/shop\"\n4   }\n5 }\n

\n\n\n\n

Essa é nossa configuração padrão, agora vamos criar uma configuração para teste, crie um arquivo test.json no diretório config com a seguinte instrução:

\n\n

1 {\n2   \"database\": {\n3     \"mongoUrl\": \"mongodb://localhost:27017/test\"\n4   }\n5 }\n

\n\n\n

Nesse caso o mongo vai utilizar um banco de teste. O próximo passo é alterar a aplicação para fazer uso dessas configurações.\nComeçamos importando o módulo config no config/database.js, como no trecho de código abaixo:

\n\n

1  import mongoose from 'mongoose';\n2 +import config from 'config';\n

\n\n\n\n

Em seguida, vamos alterar a linha onde definimos a constante mongodbUrl para que ela utilize o valor que vem do config:

\n\n

1 -const mongodbUrl = process.env.MONGODB_URL || 'mongodb://localhost:27017/test';\n2 +const mongodbUrl = config.get('database.mongoUrl');\n

\n\n\n\n

Dessa maneira quem irá cuidar da configuração é o config, ele que vai ter a responsabilidade de entregar o mongoUrl baseado no ambiente em que a aplicação está sendo executada.

\n\n

O módulo config utiliza a variável de ambiente NODE_ENV para saber qual arquivo carregar, como definimos no package.json o NODE_ENV=test para nossos testes, ele vai carregar o arquivo test.json.

\n\n

1  \"test:integration\": \"NODE_ENV=test mocha --opts test/integration/mocha.opts test/in\\\n2 tegration/**/*_spec.js\",\n3  \"test:unit\": \"NODE_ENV=test mocha --opts test/unit/mocha.opts test/unit/**/*_spec.j\\\n4 s\"\n

\n\n\n\n

O módulo config trabalha de forma hierárquica sobrescrevendo os arquivos de ambiente, não é necessário colocar todas as variáveis em um novo json, somente as que serão alteradas para determinado ambiente, dessa forma ele usará o valor default para as que não foram alteradas.

\n\n

Para finalizar vamos alterar o package.json adicionando o comando de test, para que seja possível executarmos ambos os testes de unidade e integração com apenas um comando:

\n\n

1 -    \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\",\n2 +    \"test\": \"npm run test:unit && npm run test:integration\",\n

\n\n\n\n

Para testar basta executar o seguinte comando:

\n\n

1 $ npm test\n

\n\n\n\n

Os testes de unidade e em seguida os testes de integração serão executados.

\n\n

O código deste capitulo esta disponível em:\npasso 9

\n\n\n

\nUsuários e autenticação

\n\n

Antes de entrarmos na autenticação precisamos implementar a parte de usuários da nossa aplicação. Vamos começar criando tests, controller, model e a configuração das rotas para os usuários.

\n\n

Neste capítulo não vou mostrar o ciclo de TDD passo-a-passo, pois já focamos nisso anteriormente, se surgir alguma dúvida lembre-se que é o mesmo processo que seguimos ao criar a parte de products.

\n\n

Começaremos pelo controller, pelos testes unitários, crie um arquivo em test/unit/controllers/users_spec.js com o seguinte código:

\n\n

  1 import UsersController from '../../../src/controllers/users';\n  2 import sinon from 'sinon';\n  3 import User from '../../../src/models/user';\n  4 \n  5 describe('Controller: Users', () => {\n  6   const defaultUser = [\n  7     {\n  8       __v: 0,\n  9       _id: '56cb91bdc3464f14678934ca',\n 10       name: 'Default User',\n 11       email: 'user@mail.com',\n 12       password: 'password',\n 13       role: 'user'\n 14     }\n 15   ];\n 16 \n 17   const defaultRequest = {\n 18     params: {}\n 19   };\n 20 \n 21   describe('get() users', () => {\n 22     it('should return a list of users', async () => {\n 23       const response = {\n 24         send: sinon.spy()\n 25       };\n 26       User.find = sinon.stub();\n 27 \n 28       User.find.withArgs({}).resolves(defaultUser);\n 29 \n 30       const usersController = new UsersController(User);\n 31 \n 32       await usersController.get(defaultRequest, response);\n 33       sinon.assert.calledWith(response.send, defaultUser);\n 34     });\n 35 \n 36     it('should return 400 when an error occurs', async () => {\n 37       const request = {};\n 38       const response = {\n 39         send: sinon.spy(),\n 40         status: sinon.stub()\n 41       };\n 42 \n 43       response.status.withArgs(400).returns(response);\n 44       User.find = sinon.stub();\n 45       User.find.withArgs({}).rejects({ message: 'Error' });\n 46 \n 47       const usersController = new UsersController(User);\n 48 \n 49       await usersController.get(request, response);\n 50       sinon.assert.calledWith(response.send, 'Error');\n 51     });\n 52   });\n 53 \n 54   describe('getById()', () => {\n 55     it('should call send with one user', async () => {\n 56       const fakeId = 'a-fake-id';\n 57       const request = {\n 58         params: {\n 59           id: fakeId\n 60         }\n 61       };\n 62       const response = {\n 63         send: sinon.spy()\n 64       };\n 65 \n 66       User.find = sinon.stub();\n 67       User.find.withArgs({ _id: fakeId }).resolves(defaultUser);\n 68 \n 69       const usersController = new UsersController(User);\n 70 \n 71       await usersController.getById(request, response);\n 72       sinon.assert.calledWith(response.send, defaultUser);\n 73     });\n 74   });\n 75 \n 76   describe('create() user', () => {\n 77     it('should call send with a new user', async () => {\n 78       const requestWithBody = Object.assign(\n 79         {},\n 80         { body: defaultUser[0] },\n 81         defaultRequest\n 82       );\n 83       const response = {\n 84         send: sinon.spy(),\n 85         status: sinon.stub()\n 86       };\n 87       class fakeUser {\n 88         save() {}\n 89       }\n 90 \n 91       response.status.withArgs(201).returns(response);\n 92       sinon\n 93         .stub(fakeUser.prototype, 'save')\n 94         .withArgs()\n 95         .resolves();\n 96 \n 97       const usersController = new UsersController(fakeUser);\n 98 \n 99       await usersController.create(requestWithBody, response);\n100       sinon.assert.calledWith(response.send);\n101     });\n102 \n103     context('when an error occurs', () => {\n104       it('should return 422', async () => {\n105         const response = {\n106           send: sinon.spy(),\n107           status: sinon.stub()\n108         };\n109 \n110         class fakeUser {\n111           save() {}\n112         }\n113 \n114         response.status.withArgs(422).returns(response);\n115         sinon\n116           .stub(fakeUser.prototype, 'save')\n117           .withArgs()\n118           .rejects({ message: 'Error' });\n119 \n120         const usersController = new UsersController(fakeUser);\n121 \n122         await usersController.create(defaultRequest, response);\n123         sinon.assert.calledWith(response.status, 422);\n124       });\n125     });\n126   });\n127 \n128   describe('update() user', () => {\n129     it('should respond with 200 when the user has been updated', async () => {\n130       const fakeId = 'a-fake-id';\n131       const updatedUser = {\n132         _id: fakeId,\n133         name: 'Updated User',\n134         email: 'user@mail.com',\n135         password: 'password',\n136         role: 'user'\n137       };\n138       const request = {\n139         params: {\n140           id: fakeId\n141         },\n142         body: updatedUser\n143       };\n144       const response = {\n145         sendStatus: sinon.spy()\n146       };\n147       class fakeUser {\n148         static findById() {}\n149         save() {}\n150       }\n151       const fakeUserInstance = new fakeUser();\n152 \n153       const saveSpy = sinon.spy(fakeUser.prototype, 'save');\n154       const findByIdStub = sinon.stub(fakeUser, 'findById');\n155       findByIdStub.withArgs(fakeId).resolves(fakeUserInstance);\n156 \n157       const usersController = new UsersController(fakeUser);\n158 \n159       await usersController.update(request, response);\n160       sinon.assert.calledWith(response.sendStatus, 200);\n161       sinon.assert.calledOnce(saveSpy);\n162     });\n163 \n164     context('when an error occurs', () => {\n165       it('should return 422', async () => {\n166         const fakeId = 'a-fake-id';\n167         const updatedUser = {\n168           _id: fakeId,\n169           name: 'Updated User',\n170           email: 'user@mail.com',\n171           password: 'password',\n172           role: 'user'\n173         };\n174         const request = {\n175           params: {\n176             id: fakeId\n177           },\n178           body: updatedUser\n179         };\n180         const response = {\n181           send: sinon.spy(),\n182           status: sinon.stub()\n183         };\n184 \n185         class fakeUser {\n186           static findById() {}\n187         }\n188 \n189         const findByIdStub = sinon.stub(fakeUser, 'findById');\n190         findByIdStub.withArgs(fakeId).rejects({ message: 'Error' });\n191         response.status.withArgs(422).returns(response);\n192 \n193         const usersController = new UsersController(fakeUser);\n194 \n195         await usersController.update(request, response);\n196         sinon.assert.calledWith(response.send, 'Error');\n197       });\n198     });\n199   });\n200 \n201   describe('delete() user', () => {\n202     it('should respond with 204 when the user has been deleted', async () => {\n203       const fakeId = 'a-fake-id';\n204       const request = {\n205         params: {\n206           id: fakeId\n207         }\n208       };\n209       const response = {\n210         sendStatus: sinon.spy()\n211       };\n212 \n213       class fakeUser {\n214         static remove() {}\n215       }\n216 \n217       const removeStub = sinon.stub(fakeUser, 'remove');\n218 \n219       removeStub.withArgs({ _id: fakeId }).resolves([1]);\n220 \n221       const usersController = new UsersController(fakeUser);\n222 \n223       await usersController.remove(request, response);\n224       sinon.assert.calledWith(response.sendStatus, 204);\n225     });\n226 \n227     context('when an error occurs', () => {\n228       it('should return 400', async () => {\n229         const fakeId = 'a-fake-id';\n230         const request = {\n231           params: {\n232             id: fakeId\n233           }\n234         };\n235         const response = {\n236           send: sinon.spy(),\n237           status: sinon.stub()\n238         };\n239 \n240         class fakeUser {\n241           static remove() {}\n242         }\n243 \n244         const removeStub = sinon.stub(fakeUser, 'remove');\n245 \n246         removeStub.withArgs({ _id: fakeId }).rejects({ message: 'Error' });\n247         response.status.withArgs(400).returns(response);\n248 \n249         const usersController = new UsersController(fakeUser);\n250 \n251         await usersController.remove(request, response);\n252         sinon.assert.calledWith(response.send, 'Error');\n253       });\n254     });\n255   });\n256 });\n

\n\n\n\n

O próximo passo é criar o controller para usuários em src/controllers/users.js, o arquivo deve ter o seguinte conteúdo:

\n\n

 1 class UsersController {\n 2   constructor(User) {\n 3     this.User = User;\n 4   }\n 5 \n 6   async get(req, res) {\n 7     try {\n 8       const users = await this.User.find({});\n 9       res.send(users);\n10     } catch (err) {\n11       res.status(400).send(err.message);\n12     }\n13   }\n14 \n15   async getById(req, res) {\n16     const {\n17       params: { id }\n18     } = req;\n19 \n20     try {\n21       const user = await this.User.find({ _id: id });\n22       res.send(user);\n23     } catch (err) {\n24       res.status(400).send(err.message);\n25     }\n26   }\n27 \n28   async create(req, res) {\n29     const user = new this.User(req.body);\n30 \n31     try {\n32       await user.save();\n33       res.status(201).send(user);\n34     } catch (err) {\n35       res.status(422).send(err.message);\n36     }\n37   }\n38 \n39   async update(req, res) {\n40     const body = req.body;\n41     try {\n42       const user = await this.User.findById(req.params.id);\n43 \n44       user.name = body.name;\n45       user.email = body.email;\n46       user.role = body.role;\n47       if (body.password) {\n48         user.password = body.password;\n49       }\n50       await user.save();\n51 \n52       res.sendStatus(200);\n53     } catch (err) {\n54       res.status(422).send(err.message);\n55     }\n56   }\n57 \n58   async remove(req, res) {\n59     try {\n60       await this.User.deleteOne({ _id: req.params.id });\n61       res.sendStatus(204);\n62     } catch (err) {\n63       res.status(400).send(err.message);\n64     }\n65   }\n66 }\n67 \n68 export default UsersController;\n

\n\n\n

No método update do UsersController temos um cenário diferente do controller de products, vamos entender melhor o porquê em seguida. No momento, basta entender que vamos buscar o usuário do banco de dados e atualizar as propriedades. Caso o campo password esteja setado, ele também será atualizado.\nEste método update é referente ao método PUT do http. No PUT é esperado que seja enviado todos os campos que aparecem na requisição quando se faz um GET, por exemplo, se fizermos um get users/id a resposta vai conter name, email, role mas não deve conter o password por motivos de segurança. Sendo assim, o password só será recebido no update quando a intenção for alterar a senha, pois o campo não é obrigatório.

\n\n

Depois de criar o controller é a hora de criarmos o Model em src/models/user.js com o seguinte trecho de código:

\n\n

 1 import mongoose from 'mongoose';\n 2 \n 3 const schema = new mongoose.Schema({\n 4   name: String,\n 5   email: String,\n 6   password: String,\n 7   role: String\n 8 });\n 9 \n10 schema.set('toJSON', {\n11   transform: (doc, ret, options) => ({\n12     _id: ret._id,\n13     email: ret.email,\n14     name: ret.name,\n15     role: ret.role\n16   })\n17 });\n18 \n19 const User = mongoose.model('User', schema);\n20 \n21 export default User;\n

\n\n\n\n

No Model, além de criar o schema também sobrescrevemos o método toJSON que é responsável por transformar os dados que vem do MongoDB para o formato json; vamos utilizar a função transform, que é nativa do Mongoose, para remover o campo password do objeto final, pois não devemos expor a senha do usuário mesmo como hash. \nSempre que o Mongoose faz uma busca no Mongo os dados vem em BSON o formato nativo do MongoDB, similar ao JSON só que binário. Depois de receber os dados o Mongoose faz o processo de serialização onde transforma o BSON que veio do banco em JSON para ser utilizado na aplicação, nesse momento é possível intervir nessa serialização e customizar o resultado final, exatamente o que implementamos no toJSON.

\n\n

Com o Model pronto, vamos agora criar a rota em src/routes/users.js:

\n\n

 1 import express from 'express';\n 2 import UsersController from '../controllers/users';\n 3 import User from '../models/user';\n 4 \n 5 const router = express.Router();\n 6 const usersController = new UsersController(User);\n 7 router.get('/', (req, res) => usersController.get(req, res));\n 8 router.get('/:id', (req, res) => usersController.getById(req, res));\n 9 router.post('/', (req, res) => usersController.create(req, res));\n10 router.put('/:id', (req, res) => usersController.update(req, res));\n11 router.delete('/:id', (req, res) => usersController.remove(req, res));\n12 \n13 export default router;\n

\n\n\n\n

Agora precisamos atualizar o index das rotas em src/routes/index.js, para carregar a rota de usuários:

\n\n

 1 import express from 'express';\n 2 import productsRoute from './products';\n 3 +import usersRoute from './users';\n 4  \n 5  const router = express.Router();\n 6  \n 7  router.use('/products', productsRoute);\n 8 +router.use('/users', usersRoute);\n 9  router.get('/', (req, res) => res.send('Hello World!'));\n10  \n11  export default router;\n

\n\n\n\n

A próxima etapa será adicionar o arquivo de testes, mas, antes disso, vamos atualizar uma configuração nos nossos testes para que seja possível reutilizar a configuração do Supertest.

\n\n

Vamos começar tornando global a rotina before que atualmente está disponível apenas para products.\nVamos remover o trecho de código referente ao before do arquivo test/integration/routes/products_spec.js:

\n\n

 1 import Product from '../../../src/models/product';\n 2  \n 3  describe('Routes: Products', () => {\n 4 -  let request;\n 5 -  let app;\n 6 -\n 7 -  before(async () => {\n 8 -    app = await setupApp();\n 9 -    request = supertest(app);\n10 -  });\n11 -\n12 - after(async () => await app.database.connection.close());\n13 - \n14    const defaultId = '56cb91bdc3464f14678934ca';\n15    const defaultProduct = {\n16      name: 'Default product',\n

\n\n\n\n

E vamos inserir esse mesmo bloco nas definições globais, em um novo arquivo que vamos chamar de test/integration/global.js:

\n\n

1 before(async () => {\n2   const app = await setupApp();\n3   global.app = app;\n4   global.request = supertest(app);\n5 });\n6 \n7 after(async () => await app.database.connection.close());\n

\n\n\n

A última etapa da nossa refatoração é atualizar o arquivo test/integration/mocha.opts adicionando a chamada para o arquivo global.js que acabamos de criar:

\n\n

1 --require @babel/register\n2 - --require test/integration/helpers.js\n3 + --require test/integration/helpers.js test/integration/global.js\n4 --reporter spec\n5 --slow 5000\n6 + --timeout 5000\n

\n\n\n

Dessa maneira o Mocha vai carregar esse arquivo global e executar o método before sempre antes de qualquer outro callback. Assim, o Supertest vai ser inicializado antes de todos os testes de integração. Também aumentamos o timeout para 5000ms, para evitar que algum teste de integração um pouco mais lento possa quebrar o nosso teste.

\n\n

Agora basta criar os testes de integração para o modulo de users em test/integration/routes/users_spec.js, o código será o seguinte:

\n\n

  1 import User from '../../../src/models/user';\n  2 \n  3 describe('Routes: Users', () => {\n  4   const defaultId = '56cb91bdc3464f14678934ca';\n  5   const defaultAdmin = {\n  6     name: 'Jhon Doe',\n  7     email: 'jhon@mail.com',\n  8     password: '123password',\n  9     role: 'admin'\n 10   };\n 11   const expectedAdminUser = {\n 12     _id: defaultId,\n 13     name: 'Jhon Doe',\n 14     email: 'jhon@mail.com',\n 15     role: 'admin'\n 16   };\n 17 \n 18   beforeEach(async() => {\n 19     const user = new User(defaultAdmin);\n 20     user._id = '56cb91bdc3464f14678934ca';\n 21     await User.deleteMany({});\n 22     await user.save();\n 23   });\n 24 \n 25   afterEach(async() => await User.deleteMany({}));\n 26 \n 27   describe('GET /users', () => {\n 28     it('should return a list of users', done => {\n 29 \n 30       request\n 31         .get('/users')\n 32         .end((err, res) => {\n 33           expect(res.body).to.eql([expectedAdminUser]);\n 34           done(err);\n 35         });\n 36     });\n 37 \n 38     context('when an id is specified', done => {\n 39       it('should return 200 with one user', done => {\n 40 \n 41         request\n 42           .get(`/users/${defaultId}`)\n 43           .end((err, res) => {\n 44             expect(res.statusCode).to.eql(200);\n 45             expect(res.body).to.eql([expectedAdminUser]);\n 46             done(err);\n 47           });\n 48       });\n 49     });\n 50   });\n 51 \n 52   describe('POST /users', () => {\n 53     context('when posting an user', () => {\n 54 \n 55       it('should return a new user with status code 201', done => {\n 56         const customId = '56cb91bdc3464f14678934ba';\n 57         const newUser = Object.assign({},{ _id: customId, __v:0 }, defaultAdmin);\n 58         const expectedSavedUser = {\n 59           _id: customId,\n 60           name: 'Jhon Doe',\n 61           email: 'jhon@mail.com',\n 62           role: 'admin'\n 63         };\n 64 \n 65         request\n 66           .post('/users')\n 67           .send(newUser)\n 68           .end((err, res) => {\n 69             expect(res.statusCode).to.eql(201);\n 70             expect(res.body).to.eql(expectedSavedUser);\n 71             done(err);\n 72           });\n 73       });\n 74     });\n 75   });\n 76 \n 77   describe('PUT /users/:id', () => {\n 78     context('when editing an user', () => {\n 79       it('should update the user and return 200 as status code', done => {\n 80         const customUser = {\n 81           name: 'Din Doe',\n 82         };\n 83         const updatedUser = Object.assign({}, defaultAdmin, customUser)\n 84 \n 85         request\n 86           .put(`/users/${defaultId}`)\n 87           .send(updatedUser)\n 88           .end((err, res) => {\n 89             expect(res.status).to.eql(200);\n 90             done(err);\n 91           });\n 92       });\n 93     });\n 94   });\n 95 \n 96   describe('DELETE /users/:id', () => {\n 97     context('when deleting an user', () => {\n 98       it('should delete an user and return 204 as status code', done => {\n 99 \n100         request\n101           .delete(`/users/${defaultId}`)\n102           .end((err, res) => {\n103             expect(res.status).to.eql(204);\n104             done(err);\n105           });\n106       });\n107     });\n108   });\n109 \n110 });\n

\n\n\n\n

Executando os testes:

\n\n

1 $ npm test\n

\n\n\n\n

Todos os testes devem estar passando, inclusive os testes de usuários.

\n\n

\nEncriptando senhas com Bcrypt

\n\n

Antes de começarmos a trabalhar na autenticação efetivamente, é necessário fazer mais uma melhoria na API. Note que adicionamos usuários, que possuem senhas, e estamos salvando as senhas diretamente no banco como texto.

\n\n

\nSenhas em texto plano

\n\n

Salvar senhas como texto é a maneira mais simples guardar essa informação, e também a mais insegura, pois, se um hacker tiver acesso ao servidor terá acesso às senhas dos usuários. Como as pessoas costumam utilizar a mesma senha para diferentes fins essa falha na nossa aplicação pode comprometer a segurança dos usuários.

\n\n

\nSenhas com hashing de mão única

\n\n

Hashing de mão única é uma prática de encriptação onde se encripta uma mensagem utilizando um algoritmo que não permite a desencriptação, bem mais seguro do que o texto plano. Porém, se o hacker descobrir o algoritmo utilizado pode fazer uso do mesmo para gerar senhas infinitamente, mais cedo ou mais tarde ele vai encontrar a certa, esse ataque é chamado de brute-force.

\n\n

Exemplo:\n\nSHA256(\"minhasenha\") = \"79809644A830EF92424A66227252B87BBDFB633A9DAB18BA450C1B8D35665F20\"\n

\n\n

\nSenhas com hashing e salt

\n\n

Hashing oferece mais segurança do que o texto plano, mas ataques como vimos acima podem acontecer. Uma solução para esse problema é utilizar um salt. Um salt nada mais é do que uma string concatenada a uma mensagem (a senha no nosso caso). Dessa maneira, havendo uma string única para a aplicação é possível gerar um hash que é muito difícil de ser quebrado por brute-force.

\n\n

Exemplo:\n\nSHA256(\"minhasenha\" + \"meusalt\") = \"697FDEADE02B2F4C86A5696D1DF998ADA97A6B1420F5BA0C7B4EE2024DBECD1F\"\n

\n\n

Note que o hash gerado é diferente do exemplo anterior, para alguém gerar um hash igual a esse utilizando brute-force será necessário saber o salt.\nAinda temos uma falha de segurança nesse cenário: Se alguém hackear o servidor e descobrir o salt conseguirá gerar hashs com brute-force que serão iguais aos gerados pela aplicação. Pode parecer muito difícil hackear o servidor, descobrir o salt, descobrir o algoritmo e quebrá-lo com brute-force, mas não é. Se você tem um produto aberto deve se preocupar muito com isso, hackers tentam esse tipo de coisa 24h por dia.

\n\n

\nCriando senhas seguras com Bcrypt

\n\n

Bcrypt é um algoritmo de hashing baseado em Blowfish e com algumas características únicas, como a “key factor” que se refere a habilidade de aumentar a quantidade necessária de processamento para criptografar a informação. Aumentar a complexidade de processamento impossibilita a quebra de hashing por ataques como o brute-force por exemplo, pois o tempo necessário para gerar um hash similar é muito grande. \nO Bcrypt utiliza ainda um salt que é concatenado com o texto (nesse caso, a senha) para aumentar ainda mais a segurança e aleatoriedade do hash final gerado. Uma boa dica é utilizar um salt aleatório para cada senha gerada, isso garante que, mesmo que existam senhas iguais, elas não terão o mesmo hash final.\nMas aí vem a pergunta: se vamos gerar hash aleatórios, como é possível verificar a senha do usuário no momento de fazer login? Mágica! Se passarmos a senha em texto plano (que o usuário vai fornecer na hora do login) e o hash gerado quando o usuário foi salvo no banco, o hash gerado pelo algoritmo será igual ao salvo no banco de dados. Vamos ver como isso funciona na prática, começando com a instalação do Bcrypt:

\n\n

1 $ npm install bcrypt@^3.0.7\n

\n\n\n\n

Após a instalação do Bcrypt vamos atualizar o Model de user adicionando o seguinte:

\n\n

 1 import mongoose from 'mongoose';\n 2 +import Util from 'util';\n 3 +import bcrypt from 'bcrypt';\n 4 \n 5 +const hashAsync = Util.promisify(bcrypt.hash);\n 6 const schema = new mongoose.Schema({\n 7   name: String,\n 8   email: String,\n 9   password: String,\n10   role: String\n11 });\n12 \n13 +schema.pre('save', async function(next) {\n14 +  if (!this.password || !this.isModified('password')) {\n15 +    return next();\n16 +  }\n17 +  try {\n18 +    const hashedPassword = await hashAsync(this.password, 10);\n19 +    this.password = hashedPassword;\n20 +  } catch (error) {\n21 +    next(err);\n22 +  }\n23 +});\n

\n\n\n\n

Muita coisa acontece nesse bloco de código, vamos começar pelo Bcrypt. O módulo nativo do Bcrypt não suporta promises, ou seja, teríamos que usar callbacks, mas como em todo nosso código utilizamos promises vamos seguir o padrão. Atualmente é simples transformar uma função que utiliza callback para se comportar como uma Promise, basta utilizar o módulo nativo util do Node.js e chamar o método promisify passando a referência da função que utiliza callback, como fizemos com bcrypt.hash, o retorno será uma função que utiliza Promise.

\n\n

\nMiddlewares no Mongoose

\n\n

Para garantir que sempre que um usuário for salvo a senha dele será encriptada vamos utilizar uma funcionalidade do Mongoose chamada middlewares (também conhecido como pre e post hooks).\nNo trecho de código anterior utilizamos o pre save, ou seja, esse código será automaticamente executado sempre antes da função save do Model. Começamos verificando se o campo password foi realmente alterado:

\n\n

1   if(!this.password || !this.isModified('password')) {\n2     return next();\n3   };\n

\n\n\n

Se o campo password não foi alterado não podemos gerar um hash novo, se não estaríamos gerando um hash de um hash e o usuário não conseguiria mais utilizar a senha.\nCaso o campo password tenha sido alterado, o trecho de código acima vai gerar um hash para a nova senha do usuário e substituir a antiga no Model, na sequência o Model vai salvar o hash ao invés da senha em texto plano que o usuário enviou.\nA função hashAsync é a função do Bcrypt que transformamos em Promise, ela será responsável por criar um hash a partir da senha que o usuário enviou.

\n\n

Além da senha em texto, também passamos número 10 para o Brcrypt, esse número se refere ao factor; o factor é utilizado para dizer ao Bcrypt o número de complexidade que desejamos para gerar o hash, quanto maior for o número mais tempo ele vai levar para gerar o hash e mais difícil será para desencriptar. \nNa sequência substituimos o password que o usuário enviou pelo hash:

\n\n

1       this.password = hashedPassword;\n

\n\n\n\n

O this nesse contexto se refere ao Model do Mongoose, como estamos utilizando um middleware no momento que chamamos o next ele vai chamar a próxima ação da cadeia de middlewares, que provavelmente será a ação de save, caso não exista outro middleware, então o usuário será salvo no banco com o password como hash.

\n\n

Agora que temos toda a lógica necessária para criar senhas com segurança vamos voltar ao método update do UsersController para entendê-lo melhor:

\n\n

 1   async update(req, res) {\n 2     const body = req.body;\n 3     try {\n 4       const user = await this.User.findById(req.params.id);\n 5 \n 6       user.name = body.name;\n 7       user.email = body.email;\n 8       user.role = body.role;\n 9       if (body.password) {\n10         user.password = body.password;\n11       }\n12       await user.save();\n13 \n14       res.sendStatus(200);\n15     } catch (err) {\n16       res.status(422).send(err.message);\n17     }\n18   }\n

\n\n\n\n

Não vamos alterar nada no código, apenas destaquei o método update novamente para explicar o seu comportamento.\nProvavelmente alguns de vocês leitores já trabalharam com MongoDB e sabem que ele possui um método de update e nesse caso estamos buscando o usuário do banco, atualizando os dados e chamando o método save. Isso acontece por que o update nativo do MongoDB é baixo nível, ou seja, ele não pertence ao Mongoose, nós não podemos utilizar o middleware schema.pre('update') por exemplo para ter acesso aos dados anteriores e aos novos que estão sendo salvos.

\n\n

Esse comportamento tem uma razão, o MongoDB como explicado anteriormente, é um banco de dados NoSQL, ou seja, ele não garante integridade dos dados. Vamos analisar um exemplo do método update do Mongoose:

\n\n

1   async update(req, res) {\n2     try {\n3       await this.Product.updateOne({ _id: req.params.id }, req.body);\n4       res.sendStatus(200);\n5     } catch (err) {\n6       res.status(422).send(err.message);\n7     }\n8   }\n

\n\n\n\n

Esse é o ProductsController, como não utilizamos nenhum middleware do Mongoose nesse update podemos utilizar o método update nativo do MongoDB. O que acontece internamente no findOneAndUpdate é o seguinte:

\n\n

1   db.products.update(\n2   { _id: \"example-id\" },\n3     {\n4       name: \"Updated Name\",\n5     }\n6 )\n

\n\n\n\n

O Mongoose não busca o produto para atualizar e salvar novamente, ele apenas traduz o updateOne em uma query nativa de update do MongoDB, sendo assim mesmo que seja adicionado um middleware no pre update não teremos acesso aos dados anteriores para comparar se a senha do usuário mudou ou não e não saberemos se é necessário gerar outro hash.

\n\n

Antes de pensar que esse comportamento do Mongoose é “burro” vamos lembrar das premissas do MongoDB enquanto NoSQL é não prover Atomicidade e Consistência, isso significa que se o Moongose buscar o produto para a memória, atualizar os campos que mudaram e salvar novamente ele teria que lidar com concorrência, pois, imagine que nesse meio tempo em que o produto está em memória sendo atualizado outro processo também tentar atualizar o mesmo produto, isso causaria inconsistência. Por isso o Mongoose delega essa responsabilidade para o MongoDB que nativamente trata os updates de forma sequencial.

\n\n

O código desse capitulo está disponvivel aqui.

\n\n\n

\nAutenticação e controle de acesso com Access Control List - ACL

\n\n

ACL ou Access Control List, é o termo utilizado na engenharia de software para falar de Controle de Acesso a Sistemas. A maioria das implementações de ACL seguem um padrão estruturado, onde se define as ações que usuários podem executar no sistema, como por exemplo:

\n\n

1 {\n2 \tJohn: read,\n3 \tMeg: admin\n4 }\n

\n\n\n\n

Assim o sistema checa as permissões do usuário e decide se permite ou não que ele execute determinada ação.\nNo Exemplo acima o usuário John tem permissão de leitura e Meg tem permissão de administrador.

\n\n

O padrão de ACL pode ser aplicado a quase todo tipo de sistema onde é necessário controlar ações de usuários, incluindo APIs.

\n\n

Como nossa API utiliza express, vamos usar o módulo express-acl para implementar o ACL em nossa aplicação.

\n\n

\nExpress ACL

\n\n

O express-acl é um módulo feito para o express que realiza checagem de acesso em runtime e pode ser configurado via JSON ou YAML (aqui vamos optar por JSON). Vamos começar instalando o módulo:

\n\n

1 $ npm install express-acl@2.0.2\n

\n\n\n\n

Vamos criar um arquivo chamado nacl.json no diretório de configuração config/nacl.json e adicione o seguinte trecho de código:

\n\n

 1 [\n 2     {\n 3         \"group\": \"admin\",\n 4         \"permissions\": [\n 5             {\n 6                 \"resource\": \"*\",\n 7                 \"methods\": \"*\",\n 8                 \"action\": \"allow\"\n 9             }\n10         ]\n11     },\n12     {\n13         \"group\": \"user\",\n14         \"permissions\": [\n15             {\n16                 \"resource\": \"products\",\n17                 \"methods\": [\n18                     \"GET\"\n19                 ],\n20                 \"action\": \"allow\"\n21             }\n22         ]\n23     }\n24 ]\n

\n\n\n

Ainda não temos todas as configurações necessárias mas já vamos deixar pronta a parte do acl. O express acl funciona por grupos: permitindo ou não ações para um determinado grupo a um determinado recurso da API.\nPor exemplo, o primeiro grupo será o de administrador: admin, os administradores terão acesso a todos os recursos da API, sem limitação alguma, para isso é utilizado * com a \"action\":\"allow\", isso significa que a ação será de “permitir” em todos os recursos (resource) e metodos (methods).

\n\n

O segundo grupo é o de usuário (user), usuários somente terão acesso para leitura dos produtos da API.Como já vimos,a leitura é feita pelo verbo http GET, então para usuários precisamos permitir acesso ao método GET do recurso products. Como feito neste bloco:

\n\n

1         \"group\": \"user\",\n2         \"permissions\": [\n3             {\n4                 \"resource\": \"products\",\n5                 \"methods\": [\n6                     \"GET\"\n7                 ],\n8                 \"action\": \"allow\"\n9             }\n

\n\n\n\n

Agora vamos atualizar o arquivo src/app.js para adicionar a chamada ao acl.

\n\n

 1 + import acl from 'express-acl';\n 2 \n 3 const app = express();\n 4 \n 5 +acl.config({\n 6 +  baseUrl: '/',\n 7 +  path: 'config'\n 8 +});\n 9 \n10 const configureExpress = () => {\n11   app.use(bodyParser.json());\n12 +  app.use(acl.authorize.unless({path:['/users/authenticate']}));\n13 \n14   app.use('/', routes);\n15   app.database = database;\n16 \n17   return app;\n18 };\n

\n\n\n\n

Note que no app.use(acl.authorize.unless({path:['/users/authenticate']})); estamos passando o express-acl como um middleware para o express, além disso adicionamos a configuração authorize.unless que diz para o express acl validar todos os recursos da API unless (a não ser que) seja /users/authenticate, essa rota será pública e utilizada para gerar o token de autenticação.

\n\n

\nAutenticação com JSON Web Token

\n\n

Primeiro falamos de autorização com express ACL e agora vamos trabalhar na autenticação. A diferença entre autenticação e autorização é que na autenticação verificamos a identidade de um usuário e na autorização verificamos se o usuário autenticado tem privilégios para executar determinada ação.\nAutenticação pode ser feita de várias maneiras, a mais utilizada é o login com usuário e senha que cria uma sessão. Como APIs devem ser stateless, ou seja, não devem armazenar estado, não é possível ter sessão, dado que para isso ela teria que ser armazenada no servidor.

\n\n

Quando nada é armazenado no servidor fica mais fácil escalar a aplicação pois ela não tem estado em lugar algum, o usuário que controla o estado. Para resolver esse problema foram criados os tokens (também é comum utilizar cookies para autenticação). Utilizando tokens o usuário que faz a requisição autêntica uma vez com as credenciais, (no nosso caso email e senha) e recebe um token que será usado para fazer requisições para a API.

\n\n

Existem várias maneiras de fazer autenticação baseada em token, como JSON Web Token e OAuth. Aqui utilizamos JSON Web Token.

\n\n

JSON Web Token, JWT, é um padrão aberto RFC 7519 que define uma maneira compacta de transportar objetos JSON seguramente entre partes. A confiança e segurança é alcançada por meio de assinatura digital utilizando algoritmos como HMAC ou chave pública/privada RSA ou ECDSA.\nUtilizaremos um modulo npm chamado jsonwebtoken que implementa a spec oficial do JWT e nos permite gerar e validar tokens no Node.js. Vamos começar pela instalação do módulo:

\n\n

1 $ npm install jsonwebtoken@8.3.0\n

\n\n\n\n

Adicionaremos duas propriedades necessárias para a configuração em config/default.json, primeiro a propriedade key dentro do objeto auth, essa será a chave secreta utilizada para assinar o token, e a propriedade tokenExpiresIn que se refere ao tempo de expiração do token. Na configuração abaixo definimos 7 dias, após esse prazo o usuário precisa gerar um novo token.

\n\n

1 {\n2   \"database\": {\n3     \"mongoUrl\": \"mongodb://localhost:27017/shop\"\n4   },\n5 +   \"auth\": {\n6 +    \"key\": \"thisisaverysecurekey\",\n7 +    \"tokenExpiresIn\": \"7d\"\n8 +  }\n9 }\n

\n\n\n\n

\nCriando Middlewares

\n\n

Como será necessário validar o token do usuário em todas requisições vamos criar um middleware responsável por validar se a requisição possui um token, se sim, vamos decodificar o token e transformá-lo em um objeto que será adicionado na requisição para ser utilizado posteriormente pelo express-acl. Antes de tudo vamos começar pelo teste de unidade do middleware criando um arquivo em test/unit/middlewares/auth_spec.js.

\n\n

 1 import authMiddleware from '../../../src/middlewares/auth';\n 2 import jwt from 'jsonwebtoken';\n 3 import config from 'config';\n 4 \n 5 describe('AuthMiddleware', () => {\n 6   it('should verify a JWT token and call the next middleware', done => {\n 7     const jwtToken = jwt.sign({ data: 'fake' }, config.get('auth.key'));\n 8     const reqFake = {\n 9       headers: {\n10         'x-access-token': jwtToken\n11       }\n12     };\n13     const resFake = {};\n14     authMiddleware(reqFake, resFake, done);\n15   });\n16 });\n

\n\n\n\n

Aqui começamos pelo primeiro happy path, o middleware deve receber uma requisição, verificar o token e chamar o próximo middleware. Note que aqui jwt.sign({ data: 'fake' }, config.get('auth.key')); geramos um token fake para ser utilizado no teste, esse token segue a mesma lógica que a aplicação utiliza.\nPara validar o teste chamamos authMiddleware(reqFake, resFake, done); passamos o reqFake, que simula uma requisição contendo o header com o JWT, e um resFake vazio simulando o objeto de response que o middleware espera. Passamos também o callback done do Mocha como o next do middleware, dessa maneira quando o authMiddleware chamar o próximo middleware ele vai estar chamando o done do Mocha finalizando o teste.

\n\n

Executando os testes de unidade agora teremos um erro

\n\n

1 $ npm run test:unit\n2 \n3 Error: Cannot find module '../../../src/middlewares/auth'\n4     at Function.Module._resolveFilename (internal/modules/cjs/loader.js:548:15)\n5     at Function.Module._load (internal/modules/cjs/loader.js:475:25)\n

\n\n\n

O arquivo não foi encontrado, crie o arquivo em /src/middlewares/auth.js com o seguinte código:

\n\n

1 export default (req, res, next) => {\n2   next()\n3 };\n

\n\n\n\n

Aqui adicionamos lógica somente para o teste passar, passo green do TDD (espero que ainda lembrem!).

\n\n

Executando os testes novamente a saída será:

\n\n

1   AuthMiddleware\n2     ✓ should verify a JWT token and call the next middleware\n

\n\n\n\n

Agora é hora de aplicar a lógica de verdade. Altere o arquivo auth.js como abaixo:

\n\n

 1 +import jwt from 'jsonwebtoken';\n 2 +import config from 'config';\n 3 \n 4 export default (req, res, next) => {\n 5 +  const token = req.headers['x-access-token'];\n 6 +\n 7 +  jwt.verify(token, config.get('auth.key'), (err, decoded) => {\n 8 +    req.decoded = decoded;\n 9 +    next(err);\n10 +  });\n11 };\n

\n\n\n\n

Primeiro passo pegamos o token x-access-token do header da requisição que e depois o verificamos utilizando o módulo jsonwebtoken. O primeiro parâmetro é o token, o segundo é a chave secreta da nossa aplicação para poder decodificar o token e o terceiro parâmetro é o callback que o jsonwebtoken espera.\nEm seguida adicionamos o token decodificado ao objeto req referente a requisição req.decoded = decoded e chamamos o próximo middleware com next. Note que o err é passado como parâmetro para o próximo middleware, isso significa que se ocorrer algum erro na hora de decodificar o token o jsonwebtoken vai passar esse erro para nós e nós vamos passá-lo adiante para o próximo middleware, no futuro teremos um middleware somente para tratar erros.

\n\n

Executando os testes de unidade novamente:

\n\n

1 $ npm run test:unit\n2 \n3   AuthMiddleware\n4     ✓ should verify a JWT token and call the next middleware\n

\n\n\n\n

É um pouco confuso passar o err para o próximo middleware, certo? Isso significa que nosso código possui dois caminhos, um de sucesso e um de falha, então devemos testar ambos. Vamos escrever um teste que simula um caso de erro adicionando o seguinte caso de teste em test/unit/middlewares/auth_spec.js.

\n\n

 1 import authMiddleware from '../../../src/middlewares/auth';\n 2 import jwt from 'jsonwebtoken';\n 3 import config from 'config';\n 4 \n 5 describe('AuthMiddleware', () => {\n 6 \n 7     it('should verify a JWT token and call the next middleware', done => {\n 8         const jwtToken = jwt.sign({ data: 'fake' }, config.get('auth.key'));\n 9         const reqFake = {\n10             headers: {\n11                 'x-access-token': jwtToken\n12             }\n13         };\n14         const resFake = {};\n15         authMiddleware(reqFake, resFake, done);\n16     });\n17 \n18 +    it('should call the next middleware passing an error when the token validation \\\n19 fails', done => {\n20 +        const reqFake = {\n21 +           headers: {\n22 +                'x-access-token': 'invalid token'\n23 +            }\n24 +        };\n25 +        const resFake = {};\n26 +       authMiddleware(reqFake, resFake, err => {\n27 +            expect(err.message).to.eq('jwt malformed');\n28 +            done();\n29 +        });\n30 +    });\n31 });\n

\n\n\n\n

Passando um valor qualquer no header x-access-token fará com que o jsonwebtoken falhe e o nosso código var chamar o next passando o erro recebido pelo jsonwebtoken. No teste basta checarmos a mensagem:\nexpect(err.message).to.eq('jwt malformed')\n“jwt malformed’ é a mensagem lançada pelo jsonwebtoken quando ele recebe um token que não segue o padrão do JWT.

\n\n

Executando os testes, a saída será:

\n\n

1   AuthMiddleware\n2     ✓ should verify a JWT token and call the next middleware\n3     ✓ should call the next middleware passing an error when the token validation fai\\\n4 ls\n

\n\n\n\n

Ainda temos um caso para testar: na implementação atual o código espera que toda a requisição envie um token, mas a requisição para gerar o token não tem como passar um token!. Sendo assim, nosso código precisa verificar se existe token na requisição e chamar o próximo middleware sem executar a lógica de decodificação do jsonwebtoken.\nVamos para o teste:

\n\n

1  it('should call next middleware if theres no token', done => {\n2         const reqFake = {\n3             headers: {}\n4         };\n5         const resFake = {};\n6         authMiddleware(reqFake, resFake, done);\n7     });\n

\n\n\n\n

Adicione o teste acima no teste unitário do auth middleware. Nele não var ser passado o header x-access-token, executando o teste:

\n\n

 1 $npm run test:unit\n 2 \n 3   AuthMiddleware\n 4     ✓ should verify a JWT token and call the next middleware\n 5     ✓ should call the next middleware passing an error when the token validation fai\\\n 6 ls\n 7     1) should call next middleware if theres no token\n 8 \n 9 \n10   2 passing (16ms)\n11   1 failing\n12 \n13   1) AuthMiddleware should call next middleware if theres no token:\n14      JsonWebTokenError: jwt must be provided\n15       at Object.module.exports [as verify] (node_modules/jsonwebtoken/verify.js:39:1\\\n16 7)\n17       at exports.default (src/middlewares/auth.js:8:7)\n18       at Context.done (test/unit/middlewares/auth_spec.js:36:9)\n

\n\n\n\n

O teste vai quebrar. A mensagem é jwt must be provided o que significa que o código tentou verificar o token, vamos alterar o código para não verificar o token quando ele não estiver na requisição. Altere o middleware auth.js:

\n\n

 1 import jwt from 'jsonwebtoken';\n 2 import config from 'config';\n 3 \n 4 export default (req, res, next) => {\n 5   const token = req.headers['x-access-token'];\n 6 +  if (!token) {\n 7 +    return next();\n 8 +  };\n 9   jwt.verify(token, config.get('auth.key'), (err, decoded) => {\n10     req.decoded = decoded;\n11     next(err);\n12   });\n13 };\n

\n\n\n\n

Simples! Se não tiver token chamamos o próximo middleware. Os testes agora devem estar passando

\n\n

1   AuthMiddleware\n2     ✓ should verify a JWT token and call the next middleware\n3     ✓ should call the next middleware passing an error when the token validation fai\\\n4 ls\n5     ✓ should call next middleware if theres no token\n

\n\n\n\n

Nosso middleware esta pronto.

\n\n

O próximo passo é alterar o app.js adicionando o auth middleware ao express.

\n\n

 1 import express from 'express';\n 2 import bodyParser from 'body-parser';\n 3 import acl from 'express-acl';\n 4 import routes from './routes';\n 5 import database from '../config/database';\n 6 +import authMiddleware from './middlewares/auth.js';\n 7 \n 8  const app = express();\n 9 \n10 acl.config({\n11   baseUrl:'/',\n12   path: 'config'\n13 });\n14 \n15 const configureExpress = () => {\n16   app.use(bodyParser.json());\n17 +  app.use(authMiddleware);\n18   app.use(acl.authorize.unless({path:['/users/authenticate']}));\n19 \n20   app.use('/', routes);\n21   app.database = database;\n22 \n23   return app;\n24 };\n

\n\n\n\n

Os testes de integração não estão passando pois ainda não implementamos a autenticação. Vamos começar a implementação da autenticação pelo teste da rota em test/integration/users_spec.js

\n\n

 1 +describe('POST /users/authenticate', () => {\n 2 +    context('when authenticating an user', () => {\n 3 +      it('should generate a valid token', done => {\n 4 +\n 5 +       request\n 6 +         .post(`/users/authenticate`)\n 7 +         .send({\n 8 +           email: 'jhon@mail.com',\n 9 +           password: '123password'\n10 +         })\n11 +         .end((err, res) => {\n12 +           expect(res.body).to.have.key('token');\n13 +           expect(res.status).to.eql(200);\n14 +           done(err);\n15 +         });\n16 +     });\n17 \n18 +     it('should return unauthorized when the password does not match', done => {\n19 \n20 +       request\n21 +         .post(`/users/authenticate`)\n22 +         .send({\n23 +           email: 'jhon@mail.com',\n24 +           password: 'wrongpassword'\n25 +         })\n26 +         .end((err, res) => {\n27 +           expect(res.status).to.eql(401);\n28 +           done(err);\n29 +         });\n30 +     });\n31 +   });\n32 + });\n

\n\n\n\n

Adicionamos 2 testes de integração, um para o caso de sucesso, onde espera-se que o usuário seja autenticado, e um para o caso de falha, onde não foi possível autenticar o usuário.\nVamos executar os testes de integração:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

Ignore os outros testes nesse momento, vamos focar apenas nos novos testes:

\n\n

 1 9) Routes: Users POST /users/authenticate when authenticating a user should generate\\\n 2  a valid token:\n 3 \n 4       Uncaught AssertionError: expected {} to have key 'token'\n 5       + expected - actual\n 6 \n 7       -[]\n 8       +[\n 9       +  \"token\"\n10       +]\n11 \n12       at Test.request.post.send.end (test/integration/routes/users_spec.js:120:38)\n13       at Test.assert (node_modules/supertest/lib/test.js:179:6)\n14       at Server.assert (node_modules/supertest/lib/test.js:131:12)\n15       at emitCloseNT (net.js:1656:8)\n16       at process._tickCallback (internal/process/next_tick.js:178:19)\n17 \n18   10) Routes: Users POST /users/authenticate when authenticating an user should retu\\\n19 rn unauthorized when the password does not match:\n20 \n21       Uncaught AssertionError: expected 404 to deeply equal 401\n22       + expected - actual\n23 \n24       -404\n25       +401\n26 \n27       at Test.request.post.send.end (test/integration/routes/users_spec.js:135:35)\n28       at Test.assert (node_modules/supertest/lib/test.js:179:6)\n29       at Server.assert (node_modules/supertest/lib/test.js:131:12)\n30       at emitCloseNT (net.js:1656:8)\n31       at process._tickCallback (internal/process/next_tick.js:178:19)\n

\n\n\n\n

Estamos recebendo 404 por que a rota não existe, vamos criá-la em src/users/routes/users.js adicionando o seguinte código:

\n\n

 1 import express from 'express';\n 2 import UsersController from '../controllers/users';\n 3 import User from '../models/user';\n 4 \n 5 const router = express.Router();\n 6 const usersController = new UsersController(User);\n 7 \n 8 router.get('/', (req, res) => usersController.get(req, res));\n 9 router.get('/:id', (req, res) => usersController.getById(req, res));\n10 router.post('/', (req, res) => usersController.create(req, res));\n11 router.put('/:id', (req, res) => usersController.update(req, res));\n12 router.delete('/:id', (req, res) => usersController.remove(req, res));\n13 +router.post('/authenticate', (req, res) => usersController.authenticate(req, res));\n14 \n15 export default router;\n

\n\n\n\n

Se executarmos os testes novamente a saída será:

\n\n

 1 9) Routes: Users POST /users/authenticate when authenticating an user should generat\\\n 2 e a valid token:\n 3 \n 4       Uncaught AssertionError: expected {} to have key 'token'\n 5       + expected - actual\n 6 \n 7       -[]\n 8       +[\n 9       +  \"token\"\n10       +]\n11 \n12       at Test.request.post.send.end (test/integration/routes/users_spec.js:120:38)\n13       at Test.assert (node_modules/supertest/lib/test.js:179:6)\n14       at Server.assert (node_modules/supertest/lib/test.js:131:12)\n15       at emitCloseNT (net.js:1656:8)\n16       at process._tickCallback (internal/process/next_tick.js:178:19)\n17 \n18   10) Routes: Users POST /users/authenticate when authenticating a user should retur\\\n19 n unauthorized when the password does not match:\n20 \n21       Uncaught AssertionError: expected 500 to deeply equal 401\n22       + expected - actual\n23 \n24       -500\n25       +401\n26 \n27       at Test.request.post.send.end (test/integration/routes/users_spec.js:135:35)\n28       at Test.assert (node_modules/supertest/lib/test.js:179:6)\n29       at Server.assert (node_modules/supertest/lib/test.js:131:12)\n30       at emitCloseNT (net.js:1656:8)\n31       at process._tickCallback (internal/process/next_tick.js:178:19)\n

\n\n\n\n

Executando os testes de integração novamente a saída será um erro 500, pois não temos o método authenticate no controller de users, vamos criá-lo começando com um teste unitário em test/unit/controllers/users_spec.js.\nO método authenticate recebe os parâmetros req e res. Esperamos que método chame o objeto res do express passando o token como resposta. Abaixo vamos ver como testar esse cenário:

\n\n

 1   describe('authenticate', () => {\n 2        it('should authenticate a user', done => {\n 3       const fakeReq = {\n 4         body: {}\n 5       };\n 6       const fakeRes = {\n 7         send: token => {\n 8           expect(token).to.eql({ token: 'fake-token' });\n 9           done();\n10         }\n11       };\n12       const usersController = new UsersController({});\n13       usersController\n14         .authenticate(fakeReq, fakeRes);\n15     });\n16   });\n

\n\n\n\n

O teste é conciso pois neste momento não sabemos como nosso futuro código será, apenas sabemos que a saída deve ser um token. Aqui seguiremos o TDD de forma evolutiva para entender como o design do código muda durante o desenvolvimento.\nÉ importante atentar no código acima para o fakeRes ele possui um método send que imita o objeto real do express e dentro desse método adicionamos o expect do teste. Esse método é um callback então quando ele for chamado no final do fluxo o expect será executado e saberemos se o teste passou.

\n\n

Agora vamos implementar o metodo authenticate em src/controllers/users

\n\n

1   async authenticate(req, res) {\n2     return res.send({ token: 'fake-token' });\n3   }\n

\n\n\n\n

Aqui estamos no passo GREEN do TDD: o suficiente para o teste passar. Nosso código ainda não está gerando o token, vamos para o REFACTOR para aplicar a lógica necessária.\nNesse caso eu já fiz alguns testes e imagino como a implementação vai ser, por isso posso escrever o teste:

\n\n\n\n

Primeiramente vamos adicionar os seguintes imports:

\n\n

 1 import UsersController from '../../../src/controllers/users';\n 2 import sinon from 'sinon';\n 3 +import jwt from 'jsonwebtoken';\n 4 +import config from 'config';\n 5 +import bcrypt from 'bcrypt';\n 6 import User from '../../../src/models/user';\n 7 \n 8 \n 9     it('should authenticate a user', async() => {\n10       const fakeUserModel = {\n11         findOne: sinon.stub()\n12       };\n13       const user = {\n14         name: 'Jhon Doe',\n15         email: 'jhondoe@mail.com',\n16         password: '12345',\n17         role: 'admin'\n18       };\n19       const userWithEncryptedPassword = {...user, password: bcrypt.hashSync(user.pas\\\n20 sword, 10) };\n21       fakeUserModel.findOne.withArgs({ email: user.email }).resolves({\n22         ...userWithEncryptedPassword,\n23         toJSON: () => ({ email: user.email })\n24       });\n25 \n26       const jwtToken = jwt.sign(userWithEncryptedPassword, config.get('auth.key'), {\n27         expiresIn: config.get('auth.tokenExpiresIn')\n28       });\n29       const fakeReq = {\n30         body: user\n31       };\n32       const fakeRes = {\n33         send: sinon.spy()\n34       };\n35       const usersController = new UsersController(fakeUserModel);\n36       await usersController.authenticate(fakeReq, fakeRes);\n37       sinon.assert.calledWith(fakeRes.send, { token: jwtToken });\n38     });\n

\n\n\n\n

Quando enviados usuário e senha um json web token é gerado, este é o cenário que o teste acima representa. Se o teste não estiver fazendo sentido, não se preocupe, essa parte será mais fácil de entender quando chegarmos na implementação. \nDois pontos são importantes no teste acima:

\n\n

1 const userWithEncryptedPassword = {...user, password: bcrypt.hashSync(user.password,\\\n2  10) };\n

\n\n\n\n

Aqui geramos um hash da senha para poder simular um usuário no banco de dados, para nao tem que escrever todas as propriedades do objeto user novamente utilizamos spread operator para clonar o objecto utilizando … na frente do objeto que queremos clonar e substituindo a propriedade password pela nova com o valor encriptado pelo bcrypt.

\n\n

Na sequência, usando o stub no método findOne do fakeUserModel o usuário é retornado com o password. O método toJSON é usado para simular o método existente no Mongoose.

\n\n

1       fakeUserModel.findOne.withArgs({ email: user.email }).resolves({\n2         ...userWithEncryptedPassword,\n3         toJSON: () => ({ email: user.email })\n4       });\n

\n\n\n\n

O próximo é:

\n\n

1       const jwtToken = jwt.sign(userWithEncryptedPassword, config.get('auth.key'), {\n2         expiresIn: config.get('auth.tokenExpiresIn')\n3       });\n

\n\n\n\n

Aqui é gerado um JWT baseado nos dados falsos de usuário e com a senha encriptada, assim devemos ter o mesmo JWT que o código vai gerar e será possível comparar o token no teste.

\n\n

Agora vamos fazer a implementação do código no usersController, começando pela importação das bibliotecas:

\n\n

1 + import jwt from 'jsonwebtoken';\n2 + import config from 'config';\n3 + import bcrypt from 'bcrypt';\n

\n\n\n\n

Agora, vamos reescrever o método authenticate:

\n\n

 1   async authenticate(req, res) {\n 2     const { email, password } = req.body;\n 3     const user = await this.User.findOne({ email });\n 4     if(!user.password == bcrypt.compareSync(password, user.password)) {\n 5       // To be implemented\n 6       return;\n 7     }\n 8     const token = jwt.sign(\n 9       {\n10         name: user.name,\n11         email: user.email,\n12         password: user.password,\n13         role: user.role\n14       },\n15       config.get('auth.key'),\n16       {\n17         expiresIn: config.get('auth.tokenExpiresIn')\n18       }\n19     );\n20     res.send({ token });\n21   }\n

\n\n\n\n\n\n

O código a seguir busca um usuário no banco de dados baseado no email provido, em seguida compara as senhas e caso sejam iguais será gerado um token para o usuário, caso contrário retornará um erro.\nAgora os testes de unidade devem estar passando.

\n\n

1 $ npm run test:unit\n2 \n3   Controller: Users\n4     authenticate\n5       ✓ should authenticate a user\n

\n\n\n\n

Agora vamos aos testes de integração:

\n\n

1 $ npm run test:integration\n

\n\n\n\n

A saida sera:

\n\n

1 3 passing (689ms)\n2 9 failing\n

\n\n\n\n

Os testes devem estar falhando pois as rotas esperam receber um token. Vamos deixar os testes de integração de lado nesse momento e seguir nossa implementação interna. Os testes de integração servem para garantir que a integração entre os componentes esta funcionando, vamos voltar a eles quando terminarmos a implementação interna dos testes de unidade.

\n\n

Voltando aos testes unitários, o próximo passo é testar um caminho de erro. Um caminho de erro pode ser quando o usuário não for encontrado ou quando a senha não bater.\nVamos adicionar um novo caso de teste:

\n\n

 1     it('should return 401 when the user can not be found', async () => {\n 2       const fakeUserModel = {\n 3         findOne: sinon.stub()\n 4       };\n 5       fakeUserModel.findOne.resolves(null);\n 6       const user = {\n 7         name: 'Jhon Doe',\n 8         email: 'jhondoe@mail.com',\n 9         password: '12345',\n10         role: 'admin'\n11       };\n12       const fakeReq = {\n13         body: user\n14       };\n15       const fakeRes = {\n16         sendStatus: sinon.spy()\n17       };\n18       const usersController = new UsersController(fakeUserModel);\n19 \n20       await usersController.authenticate(fakeReq, fakeRes);\n21       sinon.assert.calledWith(fakeRes.sendStatus, 401);\n22     });\n

\n\n\n\n

Executando o teste teremos o seguinte erro:

\n\n

1  25 passing (264ms)\n2   1 failing\n3 \n4   1) Controller: should return 401 when the user can not be found:\n5      TypeError: Cannot read property 'toJSON' of null\n6       at User.findOne.then.user (src/controllers/users.js:62:37)\n

\n\n\n\n

Vamos à implementação:

\n\n

 1   async authenticate(req, res) {\n 2     const { email, password } = req.body;\n 3 +    try {\n 4       const user = await this.User.findOne({ email });\n 5       if (!user.password == bcrypt.compareSync(password, user.password)) {\n 6 -      // To be implemented\n 7 -      return;\n 8 +        throw new Error('User Unauthorized');\n 9       }\n10       const token = jwt.sign(\n11         {\n12           name: user.name,\n13           email: user.email,\n14           password: user.password,\n15           role: user.role\n16         },\n17         config.get('auth.key'),\n18         {\n19           expiresIn: config.get('auth.tokenExpiresIn')\n20         }\n21       );\n22       res.send({ token });\n23 +    } catch (err) {\n24 +      res.sendStatus(401);\n25 +    }\n26   }\n

\n\n\n\n

Não estamos passando pelo passo GREEN do TDD, estamos fazendo a implementação direta pois, neste caso, é bem simples.\nAqui verificamos se o usuário existe, se não existir retornamos um erro 401.

\n\n

Os testes devem estar passando agora, podemos seguir em frente e testar o comportamento da senha:

\n\n

 1     it('should return 401 when the password does not match', async () => {\n 2       const fakeUserModel = {\n 3         findOne: sinon.stub()\n 4       };\n 5       const user = {\n 6         name: 'Jhon Doe',\n 7         email: 'jhondoe@mail.com',\n 8         password: '12345',\n 9         role: 'admin'\n10       };\n11       const userWithDifferentPassword = {\n12         ...user,\n13         password: bcrypt.hashSync('another_password', 10)\n14       };\n15       fakeUserModel.findOne.withArgs({ email: user.email }).resolves({\n16         ...userWithDifferentPassword\n17       });\n18       const fakeReq = {\n19         body: user\n20       };\n21       const fakeRes = {\n22         sendStatus: sinon.spy()\n23       };\n24       const usersController = new UsersController(fakeUserModel);\n25 \n26       await usersController.authenticate(fakeReq, fakeRes);\n27       sinon.assert.calledWith(fakeRes.sendStatus, 401);\n28     });\n

\n\n\n

A única parte diferente nesse bloco de código é a seguinte:

\n\n

1       const userWithDifferentPassword = {\n2         ...user,\n3         password: bcrypt.hashSync('another_password', 10)\n4       };\n5       fakeUserModel.findOne.withArgs({ email: user.email }).resolves({\n6         ...userWithDifferentPassword\n7       });\n

\n\n\n\n

Aqui simulamos um cenário onde as senhas não batem. Quando isso acontece devemos retornar um erro 401 para o usuário informando que ele não pôde ser autenticado.

\n\n

Neste momento os testes devem estar passando.

\n\n

O próximo passo será extrair a lógica de autenticação para um serviço separado, para isso vamos começar pelo teste unitário em test/unit/services/auth_spec.js:

\n\n

1 import AuthService from '../../../src/services/auth';\n2 \n3 \n4 describe('Service: Auth', () => {\n5   context('authenticate', () => {\n6     it('should authenticate an user', () => {\n7     });\n8   });\n9 });\n

\n\n\n\n

No primeiro passo criamos o arquivo do teste com apenas o mínimo e por isso teremos o seguinte erro:

\n\n

1 Error: Cannot find module '../../../src/services/auth'\n

\n\n\n\n

Vamos criar o AuthService em src/services/auth.js, e então vamos melhorar nosso teste adicionando o comportamento que esperamos:

\n\n

 1 import AuthService from '../../../src/services/auth';\n 2 import bcrypt from 'bcrypt';\n 3 import Util from 'util';\n 4 import sinon from 'sinon';\n 5 \n 6 const hashAsync = Util.promisify(bcrypt.hash);\n 7 \n 8 describe('Service: Auth', () => {\n 9   context('authenticate', () => {\n10     it('should authenticate a user', async() => {\n11       const fakeUserModel = {\n12         findOne: sinon.stub()\n13       };\n14       const user = {\n15         name: 'John',\n16         email: 'jhondoe@mail.com',\n17         password: '12345'\n18       };\n19 \n20       const authService = new AuthService(fakeUserModel);\n21       const hashedPassword = await hashAsync('12345', 10);\n22       const userFromDatabase = { ...user,\n23         password: hashedPassword\n24       };\n25 \n26       fakeUserModel.findOne.withArgs({ email: 'jhondoe@mail.com' }).resolves(userFro\\\n27 mDatabase);\n28 \n29       const res = await authService.authenticate(user);\n30 \n31       expect(res).to.eql(userFromDatabase);\n32     });\n33   });\n34 });\n

\n\n\n\n

Não há nada de novo nesse cenário, é o mesmo teste feito no users controller authenticate, então vamos copiar a lógica do users_controller no método authenticate. O código deve ficar assim no AuthService:

\n\n

 1 import bcrypt from 'bcrypt';\n 2 import jwt from 'jsonwebtoken';\n 3 import config from 'config';\n 4 \n 5 class Auth {\n 6   constructor(User) {\n 7     this.User = User;\n 8   }\n 9 \n10   async authenticate(data) {\n11     const user = await this.User.findOne({email: data.email});\n12 \n13     if(!user || !(await bcrypt.compare(data.password, user.password))) {\n14       return false;\n15     }\n16 \n17     return user;\n18   }\n19 }\n20 \n21 export default Auth;\n

\n\n\n\n

Os testes de unidade agora devem estar passando:

\n\n

1 Service: Auth\n2     authenticate\n3       ✓ should authenticate an user\n

\n\n\n\n\n\n

Vamos adicionar mais um teste de unidade para o caso onde as senhas não batem:

\n\n

 1     it('should return false when the password does not match', async () => {\n 2       const user = {\n 3         email: 'jhondoe@mail.com',\n 4         password: '12345'\n 5       };\n 6       const fakeUserModel = {\n 7         findOne: sinon.stub()\n 8       };\n 9       fakeUserModel.findOne.resolves({ email: user.email, password: 'aFakeHashedPass\\\n10 word' });\n11       const authService = new AuthService(fakeUserModel);\n12       const response = await authService.authenticate(user);\n13 \n14       expect(response).to.be.false;\n15     });\n

\n\n\n\n

Com os teste de unidade prontos o próximo passo será atualizar o código no método authenticate do users controller, para utilizar o AuthService. Para isso serão necessárias algumas alterações, pois precisamos passar o AuthService para o UsersController como dependência. Vamos começar alterando o arquivo de rota onda o UsersController é construído adicionando a dependência ao construtor.

\n\n

1 import express from 'express';\n2 import UsersController from '../controllers/users';\n3 import User from '../models/user';\n4 +import AuthService from '../services/auth';\n5 \n6 const router = express.Router();\n7 - const usersController = new UsersController(User);\n8 + const usersController = new UsersController(User, AuthService);\n

\n\n\n\n

Próximo é passo alterar o Users Controller:

\n\n

1 class UsersController {\n2 - constructor(User) {\n3 +  constructor(User, AuthService) {\n4     this.User = User;\n5 +    this.AuthService = AuthService;\n6   };\n

\n\n\n\n

Agora vamos alterar o metodo authenticate para utilizar o AuthService, o método deve ficar assim:

\n\n

 1   async authenticate(req, res) {\n 2     const authService = new this.AuthService(this.User);\n 3     const user = await authService.authenticate(req.body);\n 4     if(!user) {\n 5       return res.sendStatus(401);\n 6     }\n 7     const token = jwt.sign({\n 8       name: user.name,\n 9       email: user.email,\n10       password: user.password,\n11       role: user.role\n12     }, config.get('auth.key'), {\n13       expiresIn: config.get('auth.tokenExpiresIn')\n14     });\n15     return res.send({ token });\n16   }\n

\n\n\n\n

Se executarmos os testes de unidade os testes do método authenticate do users controller estarão quebrando, pois mudamos o código, antes de qualquer alteração nesse teste vamos executar os testes de integração para garantir que a resposta final ainda é a mesma.\nSe executarmos o teste de integração agora vamos receber um erro do nacl dizendo que não temos permissão para fazer a request, nesse momento entramos em um dilema clássico no mundo dos testes onde é necessário fazer mais de uma alteração para conseguir seguir em frente.\nPara que os nossos testes de integração passem precisamos gerar um JWT e adicionar na request, já possuímos um AuthService então vamos adicionar essa lógica lá para que seja reutilizável no futuro.\nSempre começando pelo teste, vamos adicionar o seguinte no teste de unidade do AuthService:

\n\n

1 import AuthService from '../../../src/services/auth';\n2 import bcrypt from 'bcrypt';\n3 import Util from 'util';\n4 import sinon from 'sinon';\n5 + import jwt from 'jsonwebtoken';\n6 + import config from 'config';\n

\n\n\n\n

Abaixo do contexto do authenticate adicione o seguinte caso de teste:

\n\n

 1   context('generateToken', () => {\n 2     it('should generate a JWT token from a payload', () => {\n 3       const payload = {\n 4         name: 'John',\n 5         email: 'jhondoe@mail.com',\n 6         password: '12345'\n 7       };\n 8       const expectedToken =  jwt.sign(payload, config.get('auth.key'), {\n 9         expiresIn: config.get('auth.tokenExpiresIn')\n10       });\n11       const generatedToken = AuthService.generateToken(payload);\n12       expect(generatedToken).to.eql(expectedToken);\n13     });\n14   });\n

\n\n\n\n

Nada de novo aqui, essa á a mesma lógica utilizada para gerar o token no authenticate do UsersController, no futuro vamos refatorar este método para usar o generateToken do AuthService também. Executando os testes de unidade agora eles estão quebrando, afinal esse método ainda não existe no AuthService, vamos criá-lo agora:

\n\n

1 import bcrypt from 'bcrypt';\n2 + import jwt from 'jsonwebtoken';\n3 + import config from 'config';\n

\n\n\n\n

Adicione o seguinte método, logo abaixo do método authenticate.

\n\n

1   static generateToken(payload) {\n2     return jwt.sign(payload, config.get('auth.key'), {\n3       expiresIn: config.get('auth.tokenExpiresIn')\n4     });\n5   }\n

\n\n\n\n

Agora os testes de unidade para o AuthService devem estar passando (os testes do UsersController vão estar falhando e isso é esperado):

\n\n

1   Service: Auth\n2     generateToken\n3       ✓ should generate a JWT token from a payload\n

\n\n\n\n

Agora vamos adicionar a lógica de gerar token aos testes de integração de user:

\n\n

1 import User from '../../../src/models/user';\n2 + import AuthService from '../../../src/services/auth';\n

\n\n\n\n

Adicione a seguinte linha às definições de constants:

\n\n

1  const expectedAdminUser = {\n2     _id: defaultId,\n3     name: 'Jhon Doe',\n4     email: 'jhon@mail.com',\n5     role: 'admin'\n6   };\n7  + const authToken = AuthService.generateToken(expectedAdminUser);\n

\n\n\n\n

Aqui estamos gerando um JWT manualmente, ele está sendo adicionado às requisições logo abaixo.

\n\n

 1  request\n 2         .get('/users')\n 3 +        .set({'x-access-token': authToken})\n 4 \n 5         request\n 6           .get(`/users/${defaultId}`)\n 7 +          .set({'x-access-token': authToken})\n 8 \n 9         request\n10           .post('/users')\n11 +          .set({'x-access-token': authToken})\n12 \n13         request\n14           .put(`/users/${defaultId}`)\n15 +          .set({'x-access-token': authToken})\n16 \n17 \n18         request\n19           .delete(`/users/${defaultId}`)\n20 +          .set({'x-access-token': authToken})\n

\n\n\n\n

Depois dessa alteração os testes de integração de users devem estar passando:

\n\n

 1  Routes: Products\n 2     GET /products\n 3       1) should return a list of products\n 4       when an id is specified\n 5         2) should return 200 with one product\n 6     POST /products\n 7       when posting a product\n 8         3) should return a new product with status code 201\n 9     PUT /products/:id\n10       when editing a product\n11         ✓ should update the product and return 200 as status code\n12     DELETE /products/:id\n13       when deleting a product\n14         4) should delete a product and return 204 as status code\n15 \n16   Routes: Users\n17     GET /users\n18       ✓ should return a list of users\n19       when an id is specified\n20         ✓ should return 200 with one user\n21     POST /users\n22       when posting an user\n23         ✓ should return a new user with status code 201\n24     PUT /users/:id\n25       when editing an user\n26         ✓ should update the user and return 200 as status code\n27     DELETE /users/:id\n28       when deleting an user\n29         ✓ should delete an user and return 204 as status code\n30     when authenticating an user\n31       ✓ should generate a valid token\n32       ✓ should return unauthorized when the password does not match\n33 \n34 \n35   8 passing (994ms)\n36   4 failing\n

\n\n\n\n

Não vamos nos preocupar com products agora, o que queremos ver conseguimos, o teste end 2 end está funcionando e isso significa que o users controller está com a lógica certa, podemos alterar o teste de unidade do método authenticate agora para que volte a passar, os testes devem ficar assim:

\n\n

 1 describe('authenticate', () => {\n 2     it('should authenticate a user', async () => {\n 3       const fakeUserModel = {};\n 4       const user = {\n 5         name: 'Jhon Doe',\n 6         email: 'jhondoe@mail.com',\n 7         password: '12345',\n 8         role: 'admin'\n 9       };\n10       const userWithEncryptedPassword = {\n11         ...user,\n12         password: bcrypt.hashSync(user.password, 10)\n13       };\n14       class FakeAuthService {\n15         authenticate() {\n16           return Promise.resolve(userWithEncryptedPassword)\n17         }\n18       };\n19 \n20       const jwtToken = jwt.sign(\n21         userWithEncryptedPassword,\n22         config.get('auth.key'),\n23         {\n24           expiresIn: config.get('auth.tokenExpiresIn')\n25         }\n26       );\n27       const fakeReq = {\n28         body: user\n29       };\n30       const fakeRes = {\n31         send: sinon.spy()\n32       };\n33       const usersController = new UsersController(fakeUserModel, FakeAuthService);\n34       await usersController.authenticate(fakeReq, fakeRes);\n35       sinon.assert.calledWith(fakeRes.send, { token: jwtToken });\n36     });\n37 \n38 \n39     it('should return 401 when the user can not be found', async () => {\n40       const fakeUserModel = {};\n41       class FakeAuthService {\n42         authenticate() {\n43           return Promise.resolve(false)\n44         }\n45       };\n46       const user = {\n47         name: 'Jhon Doe',\n48         email: 'jhondoe@mail.com',\n49         password: '12345',\n50         role: 'admin'\n51       };\n52       const fakeReq = {\n53         body: user\n54       };\n55       const fakeRes = {\n56         sendStatus: sinon.spy()\n57       };\n58       const usersController = new UsersController(fakeUserModel, FakeAuthService);\n59 \n60       await usersController.authenticate(fakeReq, fakeRes);\n61       sinon.assert.calledWith(fakeRes.sendStatus, 401);\n62     });\n

\n\n\n\n

O caso de teste “should return 401 when the password does not match” precisa ser removido pois ele nao está ciente da adição do AuthService, no mundo do TDD para fazer esse tipo de alteração precisamos estar seguros. Em nosso caso a maneira mais simples de ficarmos seguros é testar a lógica que compara as senhas no AuthService.

\n\n

Os testes de unidade devem estar passando, isso que significa que o AuthService está tratando esse caso, agora estamos seguros para remover o caso de teste do users controller.

\n\n

 1 -    it('should return 401 when the password does not match', async () => {\n 2 -      const fakeUserModel = {\n 3 -        findOne: sinon.stub()\n 4 -      };\n 5 -      const user = {\n 6 -        name: 'Jhon Doe',\n 7 -        email: 'jhondoe@mail.com',\n 8 -        password: '12345',\n 9 -        role: 'admin'\n10 -      };\n11 -      const userWithDifferentPassword = {\n12 -        ...user,\n13 -        password: bcrypt.hashSync('another_password', 10)\n14 -      };\n15 -      fakeUserModel.findOne.withArgs({ email: user.email }).resolves({\n16 -        ...userWithDifferentPassword\n17 -      });\n18 -      const fakeReq = {\n19 -        body: user\n20 -      };\n21 -      const fakeRes = {\n22 -        sendStatus: sinon.spy()\n23 -      };\n24 -      const usersController = new UsersController(fakeUserModel);\n25 -\n26 -      await usersController.authenticate(fakeReq, fakeRes);\n27 -      sinon.assert.calledWith(fakeRes.sendStatus, 401);\n28 -    });\n

\n\n\n\n

Precisamos alterar o método authenticate que vai utilizar o AuthService. Vamos começar alterando o teste should authenticate a user:

\n\n

 1       const userWithEncryptedPassword = {\n 2         ...user,\n 3         password: bcrypt.hashSync(user.password, 10)\n 4       };\n 5  +     const jwtToken = jwt.sign(userWithEncryptedPassword,\n 6  +       config.get('auth.key'),{\n 7  +         expiresIn: config.get('auth.tokenExpiresIn')\n 8  +      });\n 9 \n10       class FakeAuthService {\n11         authenticate() {\n12           return Promise.resolve(userWithEncryptedPassword)\n13         }\n14 \n15 +        static generateToken() {\n16 +          return jwtToken;\n17 +        }\n18       };\n19 \n20 -      const jwtToken = jwt.sign(\n21 -        Object.assign({}, user, { password: hashedPassword }),\n22 -        config.get('auth.key'),{\n23 -          expiresIn: config.get('auth.tokenExpiresIn')\n24 -        });\n25 -\n

\n\n\n\n

No código acima adicionamos um método fake para simular o generateToken do AuthService que retorna um token manualmente gerado. Se executarmos os testes de unidade agora eles vão estar quebrando, precisamos alterar o método authenticate para usar o generateToken no UsersController:

\n\n

 1 -        const token = jwt.sign({\n 2 +        const token = this.AuthService.generateToken({\n 3            name: user.name,\n 4            email: user.email,\n 5            password: user.password,\n 6            role: user.role\n 7 -        }, config.get('auth.key'), {\n 8 -            expiresIn: config.get('auth.tokenExpiresIn')\n 9 -          });\n10 +        });\n

\n\n\n\n

Vamos remover também as dependências que não serão mais necessárias:

\n\n

1 -import jwt from 'jsonwebtoken';\n2 -import config from 'config';\n3 -import bcrypt from 'bcrypt';\n

\n\n\n\n

Os testes de unidade devem estar passando.

\n\n

Último passo é fixar os testes end 2 end da rota de products, vamos alterar o products_spec.js:

\n\n

1 import Product from '../../../src/models/product';\n2 + import AuthService from '../../../src/services/auth';\n

\n\n\n\n

Agora vamos adicionar o expectedAdminUser para poder gerar o token, e a seguir o código para gerar o token

\n\n

 1  const expectedProduct = {\n 2     __v: 0,\n 3     _id: defaultId,\n 4     name: 'Default product',\n 5     description: 'product description',\n 6     price: 100\n 7   };\n 8 +\tconst expectedAdminUser = {\n 9 +   _id: defaultId,\n10 +  \t name: 'Jhon Doe',\n11 +   email: 'jhon@mail.com',\n12 +   role: 'admin'\n13 +  };\n14 +  const authToken = AuthService.generateToken(expectedAdminUser);\n

\n\n\n\n

O próximo passo será adicionar o authToken nas requests:

\n\n

 1 request\n 2         .get('/products')\n 3 +        .set({'x-access-token': authToken})\n 4         .end((err, res) => {\n 5           expect(res.body).to.eql([expectedProduct]);\n 6           done(err);\n 7 \n 8 \n 9        request\n10           .get(`/products/${defaultId}`)\n11 +         .set({'x-access-token': authToken})\n12           .end((err, res) => {\n13             expect(res.statusCode).to.eql(200);\n14             expect(res.body).to.eql([expectedProduct]);\n15         request\n16           .post('/products')\n17 +\t       .set({'x-access-token': authToken})\n18           .send(newProduct)\n19           .end((err, res) => {\n20             expect(res.statusCode).to.eql(201);\n21 \n22 \n23         request\n24           .put(`/products/${defaultId}`)\n25 +         .set({'x-access-token': authToken})\n26           .send(updatedProduct)\n27           .end((err, res) => {\n28             expect(res.status).to.eql(200);\n29 \n30         request\n31           .delete(`/products/${defaultId}`)\n32 +          .set({'x-access-token': authToken})\n33           .end((err, res) => {\n34             expect(res.status).to.eql(204);\n35             done(err);\n

\n\n\n\n

Pronto! Todos os testes devem estar passando

\n\n

  1 $ npm test\n  2 \n  3  Controller: Products\n  4     get() products\n  5       ✓ should call send with a list of products\n  6       ✓ should return 400 when an error occurs\n  7     getById()\n  8       ✓ should call send with one product\n  9     create() product\n 10       ✓ should call send with a new product\n 11       when an error occurs\n 12         ✓ should return 422\n 13     update() product\n 14       ✓ should respond with 200 when the product has been updated\n 15       when an error occurs\n 16         ✓ should return 422\n 17     delete() product\n 18       ✓ should respond with 204 when the product has been deleted\n 19       when an error occurs\n 20         ✓ should return 400\n 21 \n 22   Controller: Users\n 23     get() users\n 24       ✓ should call send with a list of users\n 25       ✓ should return 400 when an error occurs\n 26     getById()\n 27       ✓ should call send with one user\n 28     create() user\n 29       ✓ should call send with a new user\n 30       when an error occurs\n 31         ✓ should return 422\n 32     update() user\n 33       ✓ should respond with 200 when the user has been updated\n 34       when an error occurs\n 35         ✓ should return 422\n 36     delete() user\n 37       ✓ should respond with 204 when the user has been deleted\n 38       when an error occurs\n 39         ✓ should return 400\n 40     authenticate\n 41       ✓ should authenticate a user\n 42       ✓ should return 401 when theres no user\n 43 \n 44   AuthMiddleware\n 45     ✓ should verify a JWT token and call the next middleware\n 46     ✓ should call the next middleware passing an error when the token validation fai\\\n 47 ls\n 48     ✓ should call next middleware if theres no token\n 49 \n 50   Service: Auth\n 51     authenticate\n 52       ✓ should authenticate a user\n 53       ✓ should return false when the password does not match\n 54     generateToken\n 55       ✓ should generate a JWT token from a payload\n 56 \n 57 \n 58   26 passing (259ms)\n 59 \n 60 \n 61 > node-book@1.0.0 test:integration /Users/wneto/Dev/building-testable-apis-with-node\\\n 62 js-code\n 63 > NODE_ENV=test mocha --opts test/integration/mocha.opts test/integration/**/*_spec.\\\n 64 js\n 65 \n 66   Routes: Products\n 67     GET /products\n 68       ✓ should return a list of products\n 69       when an id is specified\n 70         ✓ should return 200 with one product\n 71     POST /products\n 72       when posting a product\n 73         ✓ should return a new product with status code 201\n 74     PUT /products/:id\n 75       when editing a product\n 76         ✓ should update the product and return 200 as status code\n 77     DELETE /products/:id\n 78       when deleting a product\n 79         ✓ should delete a product and return 204 as status code\n 80 \n 81   Routes: Users\n 82     GET /users\n 83       ✓ should return a list of users\n 84       when an id is specified\n 85         ✓ should return 200 with one user\n 86     POST /users\n 87       when posting an user\n 88         ✓ should return a new user with status code 201\n 89     PUT /users/:id\n 90       when editing an user\n 91         ✓ should update the user and return 200 as status code\n 92     DELETE /users/:id\n 93       when deleting an user\n 94         ✓ should delete an user and return 204 as status code\n 95     when authenticating an user\n 96       ✓ should generate a valid token\n 97       ✓ should return unauthorized when the password does not match\n 98 \n 99 \n100   12 passing (1s)\n

\n\n\n\n

Código deste capitulo está aqui no github

\n\n\n

\nEstilo de código e formatação

\n\n

Até o momento viemos desenvolvendo sem prestar muita atenção no estilo do código. Agora que estamos na reta final é hora de adicionar algumas ferramentas para garantir que o nosso código vai ter o mesmo estilo e formatação independente da pessoa ou da IDE que está sendo utilizada.\nExistem várias ferramentas na comunidade para fazer esse serviço, aqui vamos utilizar eslint e prettier.

\n\n

\nEslint

O eslint é uma ferramenta utilizada para identificar e reportar erros de padrões de código como sintaxe e estilo em Javascript e é apoiada por grandes empresas como Airbnb e Facebook.

\n\n

\nPrettier

O prettier é um formatador de código que já vem praticamente configurado, basta instalar e começar a utilizar, ele segue os padrões mais comuns de formatação de código Javascript da comunidade.

\n\n

Com a combinação de eslint e prettier é póssivel automatizar o trabalho de análise estática de código acelerando assim processos como o de revisão de pull requests.

\n\n

\nConfiguração

\n\n

1 $ npm install --save-dev eslint@^6.7.2 babel-eslint@^10.0.3 eslint-plugin-node@^10.0\\\n2 .0 prettier@^1.19.1 \n

\n\n\n\n

Adicione os seguintes comandos ao package.json

\n\n

1     \"lint\": \"eslint src --ext .js\",\n2     \"lint:fix\": \"eslint src --fix --ext .js\",\n3     \"prettier:list\": \"prettier --check 'src/**/*.js'\",\n4     \"prettier:fix\": \"prettier --write 'src/**/*.js'\",\n5     \"style:fix\": \"npm run lint:fix & npm run prettier:fix\"\n

\n\n\n\n

Aqui descrevemos comandos para analisar e fixar os problemas, é importante ter comandos separados pois quando executamos a análise em uma ferramenta de CI queremos que o build apenas quebre, se o comando tentar fixar os arquivos ele vai ficar somente no CI mas não na branch. O correto é quebrar o build e o desenvolvedor arrumar e pushar o código arrumado novamente para a branch.

\n\n

No nosso ambiente de desenvolvimento podemos executar diretamente os comandos de fix, as ferramentas tentam arrumar o máximo possível automaticamente mas algumas coisas necessitam da revisão manual.

\n\n

Fixando os problemas de estilo e formatação

\n\n

Como falei, no ambiente de desenvolvimento podemos executar diretamente o comando de fix, vamos começar com o eslint:

\n\n

1 $npm run lint:fix\n

\n\n\n\n

Minha saída foi a seguinte

\n\n

1 /Users/wneto/Dev/building-testable-apis-with-nodejs-code/src/controllers/users.js\n2   1:8  error  'jwt' is defined but never used     no-unused-vars\n3   2:8  error  'config' is defined but never used  no-unused-vars\n4   3:8  error  'bcrypt' is defined but never used  no-unused-vars\n5 \n6 /Users/wneto/Dev/building-testable-apis-with-nodejs-code/src/models/user.js\n7   21:10  error  'err' is not defined                 no-undef\n8   26:25  error  'options' is defined but never used  no-unused-vars\n

\n\n\n\n

Estes são os arquivos que não puderam ser corrigidos automaticamente, basta ir neles e corrigir manualmente.\nPor exemplo o arquivo src/controllers/users.js possui imports que não estão sendo utilizados e o src/models/user.js possui um erro de digitação que fazia o err ser undefined, agora percebemos o valor da ferramenta, não é? Provavelmente notaríamos isso somente em produção, quando um erro ocorresse.

\n\n

Todo o código atualizado por ser encontrado aqui

\n\n\n

\nFinal

\n\n

Obrigado pela jornada!

\n\n

\n\n","tocStructure",[432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530],{"_72":73,"_38":74,"_66":-5,"_75":76,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":82,"_66":-5,"_75":83,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":86,"_66":-5,"_75":87,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":90,"_66":-5,"_75":91,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":95,"_66":-5,"_75":96,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":100,"_66":-5,"_75":101,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":103,"_66":-5,"_75":104,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":106,"_66":-5,"_75":107,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":109,"_66":-5,"_75":110,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":112,"_66":-5,"_75":113,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":115,"_66":-5,"_75":116,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":118,"_66":-5,"_75":119,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":121,"_66":-5,"_75":122,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":125,"_66":-5,"_75":126,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":128,"_66":-5,"_75":129,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":131,"_66":-5,"_75":132,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":135,"_66":-5,"_75":136,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":138,"_66":-5,"_75":139,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":141,"_66":-5,"_75":142,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":144,"_66":-5,"_75":145,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":147,"_66":-5,"_75":148,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":150,"_66":-5,"_75":151,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":154,"_66":-5,"_75":155,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":157,"_66":-5,"_75":158,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":160,"_66":-5,"_75":161,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":163,"_66":-5,"_75":164,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":166,"_66":-5,"_75":167,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":169,"_66":-5,"_75":170,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":172,"_66":-5,"_75":173,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":176,"_66":-5,"_75":177,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":179,"_66":-5,"_75":180,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":182,"_66":-5,"_75":183,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":185,"_66":-5,"_75":186,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":188,"_66":-5,"_75":189,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":191,"_66":-5,"_75":192,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":194,"_66":-5,"_75":195,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":198,"_66":-5,"_75":199,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":201,"_66":-5,"_75":202,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":204,"_66":-5,"_75":205,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":207,"_66":-5,"_75":208,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":210,"_66":-5,"_75":211,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":213,"_66":-5,"_75":214,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":216,"_66":-5,"_75":217,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":219,"_66":-5,"_75":220,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":223,"_66":-5,"_75":224,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":226,"_66":-5,"_75":227,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":229,"_66":-5,"_75":230,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":188,"_66":-5,"_75":232,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":234,"_66":-5,"_75":235,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":238,"_66":-5,"_75":239,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":241,"_66":-5,"_75":242,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":244,"_66":-5,"_75":245,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":247,"_66":-5,"_75":248,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":250,"_66":-5,"_75":251,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":254,"_66":-5,"_75":255,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":257,"_66":-5,"_75":258,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":260,"_66":-5,"_75":261,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":263,"_66":-5,"_75":264,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":266,"_66":-5,"_75":267,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":270,"_66":-5,"_75":271,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":273,"_66":-5,"_75":274,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":276,"_66":-5,"_75":277,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":279,"_66":-5,"_75":280,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":234,"_66":-5,"_75":282,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":284,"_66":-5,"_75":285,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":287,"_66":-5,"_75":288,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":276,"_66":-5,"_75":290,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":293,"_66":-5,"_75":294,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":296,"_66":-5,"_75":297,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":299,"_66":-5,"_75":300,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":302,"_66":-5,"_75":303,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":305,"_66":-5,"_75":306,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":308,"_66":-5,"_75":309,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":312,"_66":-5,"_75":313,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":315,"_66":-5,"_75":316,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":319,"_66":-5,"_75":320,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":322,"_66":-5,"_75":323,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":325,"_66":-5,"_75":326,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":328,"_66":-5,"_75":329,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":332,"_66":-5,"_75":333,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":335,"_66":-5,"_75":336,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":338,"_66":-5,"_75":339,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":341,"_66":-5,"_75":342,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":344,"_66":-5,"_75":345,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":348,"_66":-5,"_75":349,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":351,"_66":-5,"_75":352,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":354,"_66":-5,"_75":355,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":357,"_66":-5,"_75":358,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":361,"_66":-5,"_75":362,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":364,"_66":-5,"_75":365,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":367,"_66":-5,"_75":368,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":371,"_66":-5,"_75":372,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":374,"_66":-5,"_75":375,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":377,"_66":-5,"_75":378,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":380,"_66":-5,"_75":381,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":384,"_66":-5,"_75":385,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":387,"_66":-5,"_75":388,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":94,"_38":390,"_66":-5,"_75":391,"_68":77,"_97":-5,"_98":-5,"_80":-5},{"_72":73,"_38":393,"_66":-5,"_75":394,"_68":77,"_97":-5,"_98":-5,"_80":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]