Giter Site home page Giter Site logo

serverest / serverest Goto Github PK

View Code? Open in Web Editor NEW
669.0 9.0 80.0 5.47 MB

APIs REST simulando loja virtual para servir de estudo de testes de API de forma manual ou automatizada

Home Page: https://serverest.dev

JavaScript 95.96% Dockerfile 0.47% Makefile 1.33% Shell 0.17% Go 2.07%
api-rest testing api-testing rest serverest hacktoberfest

serverest's Issues

Adicionar execução via Docker

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Não!

Descreva a solução que você deseja
Seria legal a inicialização do projeto via docker, ja com uma imagem docker do docker hub, evitando conflitos de versionamento do computadores locais.

Implementar entrega contínua (CD)

Descreva a solução que você deseja
Ter entrega contínua.
Ao realizar push para a master deve realizar todas as etapas necessárias e publicar no NPM.

Descreva as alternativas que você considerou

  • Implementar o Semantic Release na CI para pushes na branch.
  • Remover npm standard-version.
  • Atualizar o contributing.md e informar sobre a CD.
  • Incluir badge do semantic-release.

Importante

  • Nesse workflow de CD deve realizar todas os jobs já criados, como lint, commitlint e testes. Se algum quebrar a release é abortada.
  • Deve ser gerado changelog. Analisar como o semantic-release gera.

Material de apoio:

Etapas do semantic-release:

Step Description
Verify Conditions Verify all the conditions to proceed with the release.
Get last release Obtain the commit corresponding to the last release by analyzing Git tags.
Analyze commits Determine the type of release based on the commits added since the last release.
Verify release Verify the release conformity.
Generate notes Generate release notes for the commits added since the last release.
Create Git tag Create a Git tag corresponding to the new release version.
Prepare Prepare the release.
Publish Publish the release.
Notify Notify of new releases or errors.

PRÉ-REQUISITO

Somente implementar entrega contínua com os testes de API finalizados. Está sendo tratado na issue #1.

Executar teste de mutação apenas para arquivos alterados

Agora ao invés de rodar teste de mutação para todos os arquivos, o que demora aproximadamente 19 minutos, irá rodar apenas nos arquivos JS em /src que foram alterados na branch do PR. Com isso a execução será muito mais rápida e vai possibilitar que faça parte da pipeline de entrega contínua.

Essa issue já está em andamento no PR #172
Será utilizada a lib stryker-diff-runner.

Erro 'entity.parse.failed' ao usar CURL

Descreva o bug
Ao realizar a seguinte request:
curl --request POST --header "Content-Type: application/json" --data "{'nome':'Lucas Amaral', 'email':'[email protected]', 'password':'123457', 'administrador':'false'}" http://localhost:3500/usuarios

É retornado o seguinte erro:
{"error":{"expose":true,"statusCode":400,"status":400,"body":"{'nome':'Lucas Amaral', 'email':'[email protected]', 'password':'123457', 'administrador':'false'}","type":"entity.parse.failed"}}

Comportamento esperado
O POST seja feito corretamente ou a mensagem auxilie na solução do problema.

Opção de debug

Opção de debug para que o usuário consiga visualizar os dados da request que chegaram no ServeRest, como header, e body.

Esses dados serão impressos no console.

Para utilizar basta passar -D ou --debug.

Erro 500 - Rota de produtos com a nova propriedade /imagem

Descreva o bug
No monitoramento do moesif surgiu erro 500 na rota de /produtos. E pelos detalhes da request o usuário utilizou a nova propriedade /imagem (incluído no PR #134) da rota POST /produtos com o Postman.

Reproduzir
Acessar o Postman v7.26.5 e realizar POST em /produtos com o seguinte body:

{
  "preco": "18",
  "imagem": "nada",
  "nome": "Produto Novo 2",
  "quantidade": "1",
  "descricao": "descrição produto novo"
}

É preciso autenticar em /login

Response:

{
  "message": "Abra uma issue informando essa resposta. https://github.com/PauloGoncalvesBH/ServeRest/issues",
  "error": {}
}

Comportamento esperado
O cadastro deveria ter retorno 400 ou 201.

Capturas de tela

Print do moesif com os detalhes da request:

Captura de tela de 2020-10-12 16-19-55

Detalhe do user agent:

Captura de tela de 2020-10-12 16-25-18

Contexto:

  • Versão do ServeRest: 2.13.2
  • O usuário levantou o ServeRest utilizando npx serverest, e não docker.

Criar badge do ServeRest

Inserir no README.md informação sobre badge do ServeRest, contendo sugestão para as pessoas incluírem em seus projetos.

Acredito que o melhor local é antes da seção 'Empresas que utilizam o ServeRest', mas fica a seu critério essa implementação.(Podemos discutir sobre na PR)

O texto deve estar em português e deve ter o a badge em si e o código da badge em markdown para o usuário copiar. (é assim nos 2 exemplos abaixo)

Projetos que pode usar de inspiração:

  1. commitizen
  2. Standard

Sugestão de página para gerar a badge:
img.shields

Rodar os testes em várias versões do Node

Os testes das pipelines de entrega contínua e integração contínua são executadas apenas na última versão do Node disponibilizada pela action setup-node.

Para garantir que o ServeRest suporta todas as versões LTS do Node, é preciso que ele execute nas versões 10, 12 e 14.

Isso é possível utilizando matrix.

Material de apoio:

Arquivos que serão alterados:

Token de autenticação é lido como válido em sessões diferentes

Descrição do bug

Ao gerar um token de autenticação com duração longa (5 minutos) e reiniciar o ServeRest, o token permanece sendo utilizável.

Comportamento esperado

Que o token seja válido apenas para a sessão existente. Ao reiniciar o ServeRest ele deve ser considerado inváido.

Descrição técnica

A chave utilizada para gerar o token de autenticação está fixo.
https://github.com/PauloGoncalvesBH/ServeRest/blob/90dfff4458af725aa0bf582ee1846ad119c310bc/src/services/auth-service.js#L7
Substituir essa chave pelo v4 fornecido pelo uuid. Dessa forma será randômico, por sessão.

Código de retorno errado quando o método não é suportado pelo recurso

** Descreva o bug **
Código de retorno errado quando o método não é suportado pelo recurso. O código está 404, quando deveria ser 405 - Method not Allowed

referencias:
https://tools.ietf.org/html/rfc7231#section-6.5.5
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status/405

Reproduzir
Etapas para reproduzir o comportamento:

  1. Enviar DELETE para um Produto
  2. Ver o erro

Comportamento esperado
deve retornar 405

** Capturas de tela **
Se aplicável, adicione capturas de tela para ajudar a explicar seu problema.

** Contexto (preencha as seguintes informações): **

** Contexto adicional **

Disponibilizar no docker hub

Disponibilizar o ServeRest no docker hub.

Estando no docker hub será possível que usuários tenham 2 formas de utilizar o serverest, sem serem obrigados instalarem node.

  • Incluir informação de uso com docker no README.md
  • OPCIONAL: Incluir na entrega contínua o build e disponibilização no docker hub. Pré-requisito do job será criação de release.

Documentação:

  • Revisar documentação do CONTRIBUTING.md
  • Revisar Dockerfile
  • Revisar MAKEFILE

Melhorias nas mensagens defaults

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Nâo considero um problema.
Acredito que seja apenas uma futura feature para melhorar ainda mais o serverest.

Hoje, através de uma possível lib, temos a resposta default do tipo:

{
  "error": {
    "name": "ValidationError",
    "message": "Validation Failed",
    "statusCode": 400,
    "error": "Bad Request",
    "details": [
      {
        "email": "\"email\" is not allowed to be empty",
        "password": "\"password\" is not allowed to be empty"
      }
    ]
  }
}

Descreva a solução que você deseja
A solução seria padronizar as mensagens de erro.

Como podemos ver, as mensagens de erro aparecem no padrão em EN. Seria interessante além de personalizar as mensagens para PT-BR, elas fossem mais claras para os usuários, por exemplo:

{
    "email": "Email é obrigatório",
    "password": "Password é obrigatório"
}

Contexto adicional
Segue response de /login sem enviarmos um email e um password:

Screenshot from 2020-07-08 16-35-32

Executar os testes de API no pré-push

Descreva a solução que você deseja
Os testes de API são executados apenas na integração e entrega contínua nas Actions do GitHub.
Para garantir qualidade e velocidade é interessante que os testes sejam executados no pré-push, abortando o commit caso os testes e a cobertura de código (executado automaticamente após os testes de API) falhem.

Descreva as alternativas que você considerou
No arquivo package.json, dentro de husky (linha 34), incluir a hooks pre-push com o comando npm test.

Para saber mais do husky, acesse a página do projeto.

Contexto adicional
Além de adicionar o pre-push no hooks do husky, é importante:

  • Alterar o arquivo CONTRIBUTING.md
    • Inserir na seção Testes de API o ícone de que a validação é executada localmente (ícone de notebook)
    • Inserir o mesmo ícone acima no sumário
    • Alterar na seção Legenda o texto do ícone de notebook para Validação realizada localmente
    • Inserir texto no Testes de API de que commit será abortado. Seguir exemplo da seção de Lint e Commit
    • Mudar a seção Cobertura de código para ser uma subseção da seção de testes de API e remover os ícones dela.
    • Ao mudar a seção de cobertura de código, corrigir o sumário para que ela esteja como filha da seção testes de API.

Mover a documentação do apiary para o swagger UI

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.

  1. A documentação atual não é tão clara e sucinta igual uma gerada no swagger UI.
  2. Não é possível o usuário consumir as APIs de forma amigável, pois não há campo para realizar as requests.
  3. Outro problema é de que para edição da doc atual é preciso fornecer acesso à ferramenta apiary, o que é inviável. Com swagger qualquer usuário conseguirá editar a documentação.

Descreva a solução que você deseja
Refazer toda a documentação utilizando swagger UI

Internationalize ServeRest

Internationalize ServeRest

Internationalization will make it possible to increase the number of contributors and users.

Being in Portuguese it is already having 200 daily downloads, with the internationalization the number of downloads should increase considerably.

Besides, there is no project in English that provides REST server in an easy way as the serverest containing the main verbs and settings.

It is necessary to translate all tests, routes, schemas, functions, variables, documentation, help and response of the routes.

Traduzir mensagem 'must be of type object'

Descreva o bug
A mensagem de erro de que propriedade deve ser objeto não está traduzido igual as outras mensagens.

Reproduzir
Enviar POST em /carrinhos com o seguinte corpo:

[
  null
]

O retorno será o seguinte:

{
  "value": "\"value\" must be of type object"
}

Comportamento esperado
A mensagem deve ser traduzida para algo como X deve ser objeto.

Contexto:
Versão do ServeRest: 2.9.2

Descrição técnica

Ajuste deve ser feito no arquivo montarMensagemDeErroDeSchema.js e novo teste de API deve ser criado para garantir cobertura.

Falta aspas no json de autenticação na documentação

** Falta aspas no json de autenticacao **
Na documentação do projeto, o json de autenticação esta faltando aspas na cabeçalho do atributo.

Reproduzir
Etapas para reproduzir o comportamento:

  1. Abrir documentação
  2. e ir no item "Passando o seguinte corpo:"

pois esta:

{
  email: "[email protected]",
  password: "paulo"
}

para funcionar no meu foi necessário por aspas. conforme abaixo:

{
  "email": "[email protected]",
  "password": "paulo"
}

Adequação à LGPD

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
O ServeRest não está adequado à LGPD, embora não use os dados coletados para fins de ganhos financeiros.

Descreva a solução que você deseja
Precisamos informar aos usuários logo após a execução do ServeRest de que coletamos o nome de usuário da máquina da pessoa para entendermos o uso que ela faz e fazer os ajustes necessários (correção de bug e criação de novas features).

Precisamos informar que:

  1. Coletamos o nome da máquina da pessoa.
  2. Coletamos TODOS os dados das requests feitas, como: Headers, body, response, status code, user agent e versão do ServeRest.
  3. A pessoa pode solicitar todos os dados coletados dela e o mais breve possível será enviado link para ela com todas as informações. Para isso a pessoa precisará abrir issue informando nome de usuário da máquina dela.
  4. A pessoa pode solicitar que o perfil dela seja excluído, mantendo todos os dados anônimos.
  5. A pessoa pode solicitar que o perfil e todos os dados coletados dela sejam excluídos.
  6. Que esses dados são importantes para a manutenção do ServeRest, já tendo revelado bugs em produção.

Print mostrando os dados de usuários coletados:
image

Código do ServeRest que coleta o nome de usuário da máquina:
https://github.com/PauloGoncalvesBH/ServeRest/blob/6d040e6fa0dcb876a8d3b440122d128b79f48805/src/monitor.js#L19

Descreva as alternativas que você considerou

  1. Colocar no README sobre essa coleta, criando a seção LGPD.
  2. Criar template de issue chamado LGPD, facilitando a solicitação de exclusão dos dados ou repasse dos dados.
  3. No terminal logo após a execução do ServeRest informar que alguns dados são coletados, e que para se informar mais ler a seção LGPD no README. (Ainda sem certeza de se a mensagem será exibida logo após o início do ServeRest ou na seção de help npx serverest -h) Para essa implementação será preciso verificar se está sendo utilizado docker ou npm para rodar.

Contexto adicional

  • A ferramenta utilizada é a moesif.com.
  • Essa coleta de nome de usuário é feita exclusivamente quando utiliza o ServeRest via npx. Ao utilizar com docker os dados são enviados de forma anônima.

Implementar monitoramento

Ainda necessita de estudos e encontrar ferramenta que sirva a esse propósito.
Implementar monitoramento para entender o comportamento dos usuários.
Exemplo: saber quais rotas os usuários mais consomem, status Code que mais ocorre, ferramenta mais utilizada para chamar o ServeRest (a partir da info no header).

Mensagem de campo vazio está em inglês

Descreva o bug
A mensagem de erro de campo vazio não está traduzido igual as outras mensagens.

Reproduzir
Enviar POST em /login com o seguinte corpo:

{
  password: "senha"
  email: ""
}

O retorno será o seguinte:

{
  email:""email" is not allowed to be empty"
}

Comportamento esperado
A mensagem deve ser traduzida para algo como email não pode estar em branco.

Contexto:
Versão do ServeRest: 2.9.0

Descrição técnica

Ajuste deve ser feito no arquivo montarMensagemDeErroDeSchema.js e novo teste de API deve ser criado para garantir cobertura.

Implementar badge - Semantic release

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Uma descrição clara e concisa de qual é o problema. Ex. Fico sempre frustrado quando [...]

Descreva a solução que você deseja
Uma descrição clara e concisa do que você deseja que aconteça.

Descreva as alternativas que você considerou
Uma descrição clara e concisa de qualquer solução ou recurso alternativo que você tenha considerado.

Contexto adicional
Adicione qualquer outro contexto ou captura de tela sobre a solicitação de recurso aqui.

Cross-origin resource sharing não liberado

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Quando criei uma aplicação react e axios, E quando tento me conectar com a sua api acontece o erro de cors, devido não estar liberado, assim não é possível se comunicar localmente pela url http://localhost:3000/qualquer_rota.

Descreva a solução que você deseja
Apenas instalar o pacote "cors": "^2.8.5"
e adicionar o seguinte comando no arquivo app.js

const cors = require('cors');
app.use(cors());

Assim quem tem um client consegue se comunicar com a sua api.

Implementar testes de regressão

Após o deploy em serverest.dev e da publicação de novas versões no NPM e Docker (seja @beta ou @latest), é preciso executar os testes de regressão pra validar se o comportamento do ServeRest está como esperado.

  1. Taguear alguns dos testes como @regressao.
  2. Executar os testes na pipeline de entrega contínua.
    1. Teste no NPM e Docker serão executados na etapa release. https://github.com/PauloGoncalvesBH/ServeRest/blob/3559189167669da148e9de396834515407df1168/.github/workflows/continuous_delivery.yml#L58
    2. Teste no serverest.dev será executado na etapa release-on-serverest-dev. https://github.com/PauloGoncalvesBH/ServeRest/blob/3559189167669da148e9de396834515407df1168/.github/workflows/continuous_delivery.yml#L80
    3. Teste no Docker será direcionado para a tag @latest e no NPM será direcionado para @beta ou @latest de acordo com a branch atual. Ver mais aqui

Docker publica as versões da branch beta e trunk sempre como tag @latest. Isso é uma limitação do semantic-release de docker.

Mover arquivos relacionados à documentação

@PauloGoncalvesBH what about moving the CHANGELOG.md, CODE_OF_CONDUCT.md and CONTRIBUTING.md to the .github folder since it's related to the project documentation or setting the visibility of Wiki page?

Originally posted by @leandromuto in #54 (comment)

Achei muito boa a sugestão do @leandromuto sobre mover arquivos relacionados à documentado para o diretírio .github ou para a Wiki (que está desabilitada).

Porém não sei qual seria a melhor opção, e com isso gostaria de iniciar aqui uma discussão.

O único ponto que penso é que deixando no repositório, dentro de .github, ao invés de mover para a wiki, mantém tudo versionado.

Adicionar imagens dos produtos

Solicitação de recurso.
Comecei a fazer um front para a pi e senti falta de foto dos produtos ao criar a lista de produtos.

Solução
Seria legal adicionar o parâmetro de foto do produto, quem usar isso pra front fica melhor visualmente.

Subir serverest em background via terminal

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Nâo considero um problema.
Acredito que seja apenas uma futura feature para melhorar ainda mais o serverest.

Hoje, com o comando npx serverest, nosso terminal acaba por se "ocupar" até que o servidor seja parado, então, acaba por ser necessário a abertura de outro terminal e/ou aba. Para uma maior facilidade e até rapidez, subir o servidor em background via terminal seria uma ótima solução.

Descreva a solução que você deseja
A solução seria criarmos um argumento que fizesse o servidor subir em background via terminal.

Descreva as alternativas que você considerou
O webdriver-manager possui exatamente essa funcionalidade que pode ser vista AQUI

Podemos observar a opção: webdriver-manager start --detach

Contexto adicional
Acredito que poderiamos criar essa opção para os usuários e não mais travarmos o terminal ao subirmos o server.

Screenshot from 2020-05-26 20-24-27

alguns workflows não estão rodando em PR de terceiros

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Um usuário abriu determinado pull request e apenas o workflow continuous_integration.yml foi executado, enquanto os outros, de teste de mutação, check-links e codeql, não foram executados.

Com isso a qualidade do PR não está sendo garantida.

Descreva a solução que você deseja
Alterar os seguintes workflows para rodarem em pull_request:

  1. check-link
  2. codeql
  3. mutation test

Descreva as alternativas que você considerou
Na seção on: desses arquivos inserir a tag pull_request:. Dessa forma esses workflows rodarão em PR.

Utilize a linha 4 do workflow de integração contínua como inspiração caso esteja com dúvidas: https://github.com/PauloGoncalvesBH/ServeRest/blob/trunk/.github/workflows/continuous_integration.yml

https://github.com/PauloGoncalvesBH/ServeRest/blob/1f9f6339d2cd00a81804c64e0a1d2b463b677f90/.github/workflows/continuous_integration.yml#L4

Implementar stub nos testes

Muitos testes podem ter trechos substituídos por stubs, reduzindo a quantidade de requests e dependências.
Implementação está sendo feita na branch stub-test.

Incluir logo de empresas na documentação

Adicionar na seção de empresas que utilizam o ServeRest, no README, a logo das empresas:

  1. Trybe (Escola de programação)
  2. AILOS - Sistema de cooperativas de crédito
  3. Ânima Educação

Erro ao acessar http://localhost:3000/ com Docker

Estou testando o ServeRest com Docker, e ao acessar http://localhost:3000/ no navegador, recebo a seguinte mensagem:

{
    "message": "Abra uma issue informando essa resposta. https://github.com/PauloGoncalvesBH/ServeRest/issues",
    "error": {
        "errno": -2,
        "code": "ENOENT",
        "syscall": "stat",
        "path": "/usr/src/app/docs/localhost.html",
        "expose": false,
        "statusCode": 404,
        "status": 404
    }
}

Implementar GraphQL

Será criado nova rota utilizando GraphQL.
Assim que possuir mais detalhes serão inseridos aqui.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.