Esse projeto contém uma série de informações sobre o que eu aprendi aqui na Trybe ao longo do curso de desenvolvimento web da Trybe.
Esse projeto foi proposto pelo curso de desenvolvimento web da Trybe.
Esse proejto foi desenvolvido no bloco de back-end, usei query de MySQL.
Os commits foram feitos de acordo com os requisitos finalizados.
Todo o projeto foi feita na branch 'juliana-oliveira-store-manager-teste', isso por conta da exigência do curso.
Antes de realizar o projeto, precisei instalar as dependências usando npm install, dentro do container. Usei o comando docker exec -it store_manager bash, depois dei npm install.
Os testes usando foram feitos através dos comandos, feitos dentro do container docker:
- Primeiro fiz docker exec -it store_manager bash
- Depois fiz npm test
Esse foi um projeto individual,que desenvolvido somente por Juliana Oliveira.
Foi usado Visual Studio Code, além do Trello que auxiliou na organização das tarefas.
Nenhum.
O banco de dados usado foi o StoreManager. O script de criação do banco de dados pode ser visto:
https://github.com/tryber/sd-019-a-store-manager/blob/master/migration.sql
O script que popula o banco de dados pode ser visto:
https://github.com/tryber/sd-019-a-store-manager/blob/master/seed.sql
Antes de começar, seu docker-compose precisa estar na versão 1.29 ou superior.
No trabalho do desenvolvimento de software a gente sempre tem prazos, muitas vezes os prazos são apertados.
Por outro lado, eu não quero criar algo que não entendo perfeitamente, como também fazer códigos rápidos pode levar a erros que podem demorar muito pra corrigir.
Por isso, usei e sempre uso o método Baby Steps, que é uma estratégia de abordar o desafio passo à passo, defensivamente.
Baby steps é um termo em inglês que quer dizer passos de bebê. Refere-se a fazer as coisas, quaisquer que sejam, devagar, com calma, passo a passo.
- O endpoint para listar produtos deve ser acessível através do caminho (
/products
) e (/products/:id
); - Através do caminho
/products
, todos os produtos devem ser retornados; - Através do caminho
/products/:id
, apenas o produto com oid
presente na URL deve ser retornado; - O resultado da listagem deve ser ordernado de forma crescente pelo campo
id
;
Os seguintes pontos serão avaliados
-
[Será validado que é possível listar todos os produtos]
- Ao listar usuários com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
200
:
[ { "id": 1, "name": "Martelo de Thor", }, { "id": 2, "name": "Traje de encolhimento", } /* ... */ ]
- Ao listar usuários com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
-
[Será validado que não é possível listar um produto que não existe]
- Se o produto for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
404
:
{ "message": "Product not found" }
- Se o produto for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
-
[Será validado que é possível listar um produto específico com sucesso]
- Ao listar um produto com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
200
:
{ "id": 1, "name": "Martelo de Thor", }
- Ao listar um produto com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
- Seus arquivos de teste devem ficar no diretório
tests/unit
, como é descrito em Para escrever seus próprios arquivos de teste; - Seus testes da
model
devem fazer mock do banco de dados obrigatóriamente; - Opcionalmente você pode parar o serviço do
MYSQL
em sua máquina. Para rodar seus teste utilizenpm run test:mocha
; - Antes de executar os testes da Trybe, seus testes não devem conter erros.
Os seguintes pontos serão avaliados
- [Será validado que a cobertura total das linhas dos arquivos de CADA camada
models
,services
econtrollers
é maior ou igual a 5%. Ou seja, cada uma das camadas tem de ter, ao menos, 5% de cobertura de testes.]
- O endpoint deve ser acessível através do caminho (
/products
); - Os produtos enviados devem ser salvos na tabela
products
do banco de dados; - O corpo da requisição deverá seguir o formato abaixo:
{
"name": "ProdutoX"
}
Os seguintes pontos serão avaliados
- [Será validado que é possível cadastrar um produto com sucesso]
- Se o produto for criado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
201
:
{ "id": 4, "name": "ProdutoX" }
- Se o produto for criado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
- O endpoint de produtos deve ser acessível através do caminho (
/products
); - Lembre-se, o banco de dados não deve ser acessado nas validações iniciais do corpo da requisição;
Os seguintes pontos serão avaliados
-
[Será validado que não é possível realizar operações em um produto sem o campo
name
]- Se a requisição não tiver o campo
name
, o resultado retornado deverá ser conforme exibido abaixo, com um status http400
:
{ "message": "\"name\" is required" }
- Se a requisição não tiver o campo
-
[Será validado que não é possível realizar operações em um produto com o campo
name
menor que 5 caracteres]- Se a requisição não tiver
name
com pelo menos 5 caracteres, o resultado retornado deverá ser conforme exibido abaixo, com um status http422
{ "message": "\"name\" length must be at least 5 characters long" }
- Se a requisição não tiver
- Seus arquivos de teste devem ficar no diretório
tests/unit
, como é descrito em Para escrever seus próprios arquivos de teste; - Seus testes da
model
devem fazer mock do banco de dados obrigatóriamente; - Opcionalmente você pode parar o serviço do
MYSQL
em sua máquina. Para rodar seus teste utilizenpm run test:mocha
; - Antes de executar os testes da Trybe, seus testes não devem conter erros.
Os seguintes pontos serão avaliados
- [Será validado que a cobertura total das linhas dos arquivos de CADA camada
models
,services
econtrollers
é maior ou igual a 10%. Ou seja, cada uma das camadas tem de ter, ao menos, 10% de cobertura de testes.]
- O endpoint de vendas deve ser acessível através do caminho (
/sales
); - As vendas enviadas devem ser salvas nas tabelas
sales
esales_products
do banco de dados; - Deve ser possível cadastrar a venda de vários produtos através da uma mesma requisição;
- O corpo da requisição deverá seguir o formato abaixo:
[
{
"productId": 1,
"quantity":1
},
{
"productId": 2,
"quantity":5
}
]
Os seguintes pontos serão avaliados
-
[Será validado que não é possível realizar operações em uma venda sem o campo
productId
]- Se algum dos itens da requisição não tiver o campo
productId
, o resultado retornado deverá ser conforme exibido abaixo, com um status http400
:
{ "message": "\"productId\" is required" }
- Se algum dos itens da requisição não tiver o campo
-
[Será validado que não é possível realizar operações em uma venda sem o campo
quantity
]- Se algum dos itens da requisição não tiver o campo
quantity
, o resultado retornado deverá ser conforme exibido abaixo, com um status http400
:
{ "message": "\"quantity\" is required" }
- Se algum dos itens da requisição não tiver o campo
-
[Será validado que não é possível realizar operações em uma venda com o campo
quantity
menor ou igual a 0 (Zero)]- Se a requisição tiver algum item em que o campo
quantity
seja menor ou igual a zero, o resultado retornado deverá ser conforme exibido abaixo, com um status http422
{ "message": "\"quantity\" must be greater than or equal to 1" }
- Se a requisição tiver algum item em que o campo
-
[Será validado que não é possível realizar operações em uma venda com o campo
productId
inexistente, em uma requisição com um único item]- Se o campo
productId
do item da requisição não existir no banco de dados, o resultado retornado deverá ser conforme exibido abaixo, com um status http404
{ "message": "Product not found" }
- Se o campo
-
[Será validado que não é possível realizar operações em uma venda com o campo
productId
inexistente, em uma requisição com vários items]- Se a requisição tiver algum item cujo campo
productId
não existe no banco de dados, o resultado retornado deverá ser conforme exibido abaixo, com um status http404
{ "message": "Product not found" }
- Se a requisição tiver algum item cujo campo
-
[Será validado que é possível cadastrar uma venda com sucesso]
- Se a venda for criada com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
201
:
{ "id": 3, "itemsSold": [ { "productId": 1, "quantity":1 }, { "productId": 2, "quantity":5 } ] }
- Se a venda for criada com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
💬 Em caso de dúvidas, lembre-se de consultar a seção Dicas e Diagrama ER, Entidades e Scripts
- Seus arquivos de teste devem ficar no diretório
tests/unit
, como é descrito em Para escrever seus próprios arquivos de teste; - Seus testes da
model
devem fazer mock do banco de dados obrigatóriamente; - Opcionalmente você pode parar o serviço do
MYSQL
em sua máquina. Para rodar seus teste utilizenpm run test:mocha
; - Antes de executar os testes da Trybe, seus testes não devem conter erros.
Os seguintes pontos serão avaliados
- [Será validado que a cobertura total das linhas dos arquivos de CADA camada
models
,services
econtrollers
é maior ou igual a 15%. Ou seja, cada uma das camadas tem de ter, ao menos, 15% de cobertura de testes.]
- O endpoint para listar vendas deve ser acessível através do caminho (
/sales
) e (/sales/:id
); - Através do caminho
/sales
, todas as vendas devem ser retornadas; - Através do caminho
/sales/:id
, apenas a venda com oid
presente na URL deve ser retornada; - o resultado deve ser ordernado de forma crescente pelo campo
saleId
, em caso de empate, ordernar também de forma crescente pelo campoproductId
;
Os seguintes pontos serão avaliados
-
[Será validado que é possível listar todas as vendas]
- Ao listar vendas com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
200
:
[ { "saleId": 1, "date": "2021-09-09T04:54:29.000Z", "productId": 1, "quantity": 2 }, { "saleId": 1, "date": "2021-09-09T04:54:54.000Z", "productId": 2, "quantity": 2 } /* ... */ ]
- Ao listar vendas com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
-
[Será validado que não é possível listar uma venda que não existe]
- Se a venda for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
404
:
{ "message": "Sale not found" }
- Se a venda for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
-
[Será validado que é possível listar uma venda específica com sucesso]
- Ao listar uma venda com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
200
:
[ { "date": "2021-09-09T04:54:29.000Z", "productId": 1, "quantity": 2 }, { "date": "2021-09-09T04:54:54.000Z", "productId": 2, "quantity": 2 } /* ... */ ]
- Ao listar uma venda com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
- Seus arquivos de teste devem ficar no diretório
tests/unit
, como é descrito em Para escrever seus próprios arquivos de teste; - Seus testes da
model
devem fazer mock do banco de dados obrigatóriamente; - Opcionalmente você pode parar o serviço do
MYSQL
em sua máquina. Para rodar seus teste utilizenpm run test:mocha
; - Antes de executar os testes da Trybe, seus testes não devem conter erros.
Os seguintes pontos serão avaliados
- [Será validado que a cobertura total das linhas dos arquivos de CADA camada
models
,services
econtrollers
é maior ou igual a 20%. Ou seja, cada uma das camadas tem de ter, ao menos, 20% de cobertura de testes.]
- O endpoint deve ser acessível através do caminho (
/products/:id
); - Apenas o produto com o
id
presente na URL deve ser atualizado; - O corpo da requisição deve ser validado igual no cadastro;
- O corpo da requisição deverá seguir o formato abaixo:
{
"name": "Martelo do Batman"
}
Os seguintes pontos serão avaliados
-
[Será validado que não é possível alterar um produto que não existe]
- Se o produto for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
404
:
{ "message": "Product not found" }
- Se o produto for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
-
[Será validado que é possível alterar um produto com sucesso]
- Se o produto for alterado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
200
:
{ "id": 1, "name": "Martelo do Batman" }
- Se o produto for alterado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http
- Seus arquivos de teste devem ficar no diretório
tests/unit
, como é descrito em Para escrever seus próprios arquivos de teste; - Seus testes da
model
devem fazer mock do banco de dados obrigatóriamente; - Opcionalmente você pode parar o serviço do
MYSQL
em sua máquina. Para rodar seus teste utilizenpm run test:mocha
; - Antes de executar os testes da Trybe, seus testes não devem conter erros.
Os seguintes pontos serão avaliados
- [Será validado que a cobertura total das linhas dos arquivos de CADA camada
models
,services
econtrollers
é maior ou igual a 25%. Ou seja, cada uma das camadas tem de ter, ao menos, 25% de cobertura de testes.]
- O endpoint deve ser acessível através do caminho (
/products/:id
); - Apenas o produto com o
id
presente na URL deve ser deletado;
Os seguintes pontos serão avaliados
-
[Será validado que não é possível deletar um produto que não existe]
- Se o produto for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
404
:
{ "message": "Product not found" }
- Se o produto for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http
-
[Será validado que é possível deletar um produto com sucesso]
- Se o produto for deletado com sucesso não deve ser retornada nenhuma resposta, apenas um status http
204
;
- Se o produto for deletado com sucesso não deve ser retornada nenhuma resposta, apenas um status http
💬 Em caso de dúvidas, lembre-se de consultar a seção Diagrama ER, Entidades e Scripts