Criando APIs testáveis com Node.js (Design Patterns)

[@hermessantos181]

Se o Serasa tivesse a simpatia que todos da Rocket Seat tem eu não teria dívidas

[@sergiodsalles9573]

Vendo agora, em 11:53 quando o Diegão fala que o projeto vai estar hoje no Ignite, a vontade que tive foi de sair "correndo" pra uma nova aba e ver o projeto lá... mas eu vou terminar de asssitir esse video aqui que tá bom demais! Como sempre, conteúdo inigualável!

[@janssenbatista]

Mais uma grande aula, Diegão. 🚀 Só uma pequena correção: o "design pattern" que você mencionou não é "inversão de dependência" e sim "injeção de dependência". 🙂

[@cauenolasco]

A "injeção de dependência" é uma implementação de "inversão de dependência". No caso, ele explicou o pattern "inversão" através da "injeção". e.e

[@jairlopes7268]

@@cauenolasco Na verdade é "inversão de controle" e "injeção de dependência". Inversão de controle, pois quem passa a "controlar" a classe que irá ocupar a vaga da dependencia é quem chama a classe, e não a classe a ser chamada.

[@tiagokost]

Um pouco deselegante essa atitude de corrigir o autor. No fim das contas a explicação e a implementação estão corretas.

[@ebr182]

Uma questão mais filosófica do que prática que costumo discutir com colegas é se testes de regra de negócio (testes de use cases) devem checar estado de repositório em memória (como o Diego mostra no tempo 1:00:50). Particularmente defendo que não devem, porque na prática isso testa a implementação do repositório em memória ao invés de testar a regra de negócio em si, acredito que assim como o use case não deve conhecer a implementação do repositório, o teste do use case também não deve conhecer o estado/implementação do repositório em memória, pois o que faz parte da regra de negócio é a chamada do método do repositório (isso sim deve ser testado e deve ser o suficiente). Quando se testa o estado do repositório em memória, a partir de um teste de use case, está se testando um side effect de uma classe que não importa para a regra de negócio, já que estamos usando inversão de controle e injeção de dependência.

[@leandromoraes1862]

Qual a vantagem de se usar funcao nos useCases e controllers? Classes nao seria melhor? Achei interessante o uso de funcoes

[@paolorr]

Que comando http eh esse q vc usa no terminal para fazer requisicoes http?

[@leandromoraes1862]

Httpie uma cli que você instala

[@geisonflores]

Diego quando vc diz que os testes melhoram a arquitetura eu entendo que se você está misturando conceitos, no caso design e arquitetura. O design de software está mais relacionado com a implementação específica de um software, enquanto a arquitetura de software está mais relacionada com a estrutura geral do sistema de software. A arquitetura de software é uma atividade mais abrangente e estratégica que fornece a estrutura geral para o desenvolvimento do software, desde a escolha de banco de dados, sistemas de fila e etc. Não tem como guiar escolhas de arquitetura por meio de testes, já design de um sistema ou módulo podem sim emergir dos testes.

[@raphaelgibson6555]

O que causa essa confusão são padrões de design de software que possuem arquitetura no nome. Como arquitetura limpa, arquitetura hexagonal, etc

[@dieegosf]

Fala Geison! Valeu pela explicação! Existem na verdade diversas aplicações para os mesmos termos, arquitetura podemos pensar em desde arquitetura de software para arquitetura de infraestrutura, já design de software, se formos pegar o conceito do Eric Evans no DDD, não está ligado a como um software é escrito, ou seja, à sua implementação. O meu ponto em si no vídeo é demonstrar que testes nos guiam como um termômetro de estarmos conseguindo arquitetar o código especificamente de uma maneira bacana, mas é claro que isso não exclui outras partes da aplicação.

[@adrianmouzinho9615]

Alquém pra me ajudar, não entendi como o diego usou o arquivo setup-db.js

[@leleparanormal1579]

QUERO ESSA CAMISA!

[@brunogomes3933]

Olá, eu sou novo na programação mas queria tirar uma duvida muito boba, no caso se a tabela que eu utilizo no banco de dados tenha 30 campos, para fazer os testes eu teria que ficar replicando esses 30 campos ? mesmo que seja criando um modelo da tabela em outro arquivo.

[@fernandocosta3307]

Qual é o modelo do seu fone Diegão?

[@petervestiary5871]

hyperx cloud revolver

[@ricardomartins7227]

Alguém tem o link do formulário ?

[@thiagoporto1635]

Qual o nome desse tema do vscode?

[@fernandoigorap]

Rosé Pine

[@teoquaresma]

@@fernandoigorap e o tema do ícones é o Symbols

[@LeonardoOliveira-tx6by]

Injeção de Dependência e Inversão de Controle!

[@marciusbezerra]

seria melhor que fosse usado interface e injeção de dependência, isso é costume ser feito em c#, causa o mesmo efeito de desacoplamento no final

[@trashmanmt3864]

Deixei pra assistir a live depois e cortaram a explicação toda... ¬¬

[@zilondequadrosmaciel1006]

Diego, simular uma conexao com o banco, indo desde a conexão, passando pela inserção de dados e o retorno para o usuário da mensagem de confirmação, não "PODEM" ser mokados, devem ser feitos de maneira real..., um abraço.

[@jucelinofilho9404]

Não tem problema nenhum fazer testes unitários. Se quiser testar a integração das outras camadas que faça um teste de integração ou e2e. Você disse que não pode ser mockados, mas se não tem mock/spy/stub, não é um teste unitário...

[@StephaniLacerda]

O teste unitário serve pra testar a regra de negócio, não suas implementações, pra isso existe o teste ponta a ponta.

[@dieegosf]

Fala Zilon, dentro de teste unitários a gente não pode depender da implementação do banco, ou seja, ou trabalhamos com mocks ou com test databases que foi o conceito que eu mostrei. Trabalhamos com o banco somente em testes E2E ou integração.

[@zilondequadrosmaciel1006]

Desculpe, só para complementar, a distância ente uma conexão real e uma mokada é qiilometros e quilometros de distância, um abraço.

[@cafécomleite001]

Tu não deve ter entendido o que é um teste UNITÁRIO né?