search

Wiredcraft / test-backend

39 stars 76 forks source link

Test backend yingjun #101

Open yingjun opened 1 year ago

yingjun commented 1 year ago

Tech used:

  1. NodeJS & NestJS framework & Prisma orm
  2. Mongodb

How to run

  1. start mongodb container use provided docker-compose file docker-compose up -d
  2. run nvm use
  3. and run yarn dev
  4. go to http://localhost:3000/api-docs you can use this swagger page test api

High level design diagram

Class Diagram

bsdelf commented 1 year ago

In the high-level design diagram, what's the meaning of "->" arrow, is it a directed association?

MiffyLiye commented 1 year ago

In controller level test, dependency in service level is mocked. In service level test, an in memory database is used as a mock database. Some test styles only mock a few dependencies, e.g. external API (e.g. WeChat Service API), and not mock dependencies like database. Can you compare the benefit and cost of those test styles? What do you think when should we use mock?

yingjun commented 1 year ago

pros: mock service layer during controller testing we can focusing controller's behavior in isolation. Also some times service layer is not implemented yet in this case we need mock it. cons: since the service dependency is mocked, it may not catch integration issues between the controller and the service. we need e2e test for whole calling chain.

pros: for the service testing sometimes we need mock database since database server is not accessible, also the memory db is much more faster, if we have lots of tests it may has very long execution time. also real database is highly relay on environment. cons: since memory db is emulate the behavior of a real database, which can introduce the risk of missing potential issues. in this case we need test against with real database in qa/uat/stg env before go to prod.

MiffyLiye commented 1 year ago

pros: mock service layer during controller testing we can focusing controller's behavior in isolation. Also some times service layer is not implemented yet in this case we need mock it. cons: since the service dependency is mocked, it may not catch integration issues between the controller and the service. we need e2e test for whole calling chain.

there is one e2e test in test/app.e2e-spec.ts, but just a hello world api test. what blocks you from adding e2e test there?

pros: for the service testing sometimes we need mock database since database server is not accessible, also the memory db is much more faster, if we have lots of tests it may has very long execution time. also real database is highly relay on environment. cons: since memory db is emulate the behavior of a real database, which can introduce the risk of missing potential issues. in this case we need test against with real database in qa/uat/stg env before go to prod.

with docker, it's easy to setup database server. there are 10 ~ 20 tests in this project, not so many. what else blocks you from using real database? what do you think about using real database in e2e test in local or CI runner, before deploy to shared environment (qa/uat/stg)?

yingjun commented 1 year ago

there is one e2e test in test/app.e2e-spec.ts, but just a hello world api test. what blocks you from adding e2e test there?

lol. it is default e2e test. when I finished the interview test there is no time to do it, and it was 2 days delayed so just no time to do it. I don't want to find any excuse but I had really long week, we release new product last week. I start this project early but don't have time to do it until weekend.

with docker, it's easy to setup database server. there are 10 ~ 20 tests in this project, not so many. what else blocks you from using real database?

Actually there is nothing blocks me using real database, just provided another option here. Personally I prefer to use memory db b/c of it is fast and easy to maintain, also it if we use real database it may cased some dirty read issue which may fails unit tests and it will be wasting time on debug the failure tests.

what do you think about using real database in e2e test in local or CI runner, before deploy to shared environment (qa/uat/stg)?

Pros: using a real database during E2E testing helps replicate the actual production environment more accurately. This ensures that you are testing against the same data storage and retrieval mechanisms that your application will use in production. Cons: using real databases during E2E testing provides more accurate testing scenarios, but it requires careful management of test data and consideration of performance factors. It needs careful test data management. e.g. test should not rely on specific data existing in the database, data should create on fly to prevent dirty read fails the tests. Also needs consider test performance if we have lots of tests in project.