User routes CRUD for the Node JS Backend test

[Faz95210]

This is my implementation of the back end test in Node JS.

The code can be found in the src folder.

A postman example JSON can be found in the resources file.

[MiffyLiye]

1. I found some tests are in src/__tests__, others in src/lib/v1/user/__tests__, how do you categorize different kinds of tests?
2. some tests use toMatchSnapshot, while others use more explicit toEqual, toBe, can you compare these two types of assertions, and how to decide which type of assertion is more suitable?
3. some tests use database operations to prepare data, and use web API to verify data, why not read database to verify data, or use web API to prepare data, can you compare these two ways, and how to decide which one is more suitable?

[Faz95210]

@MiffyLiye

1. The point of having those tests in different folders is to separate them by routes, the tests in src/tests are tests for the /ping and / routes while the tests in /src/lib/v1/user/__tests__ are testing the routes in /v1/user . I think it's a good organization as, when you change code in user routes, you can easily find the tests most likely to be impacted by those changes. If , like in the advanced requirements for this project, we end up adding routes for a follower system, we'd most likely end up having a /v1/user/:userID/follower route, test for this route would be in /src/lib/v1/user/follower/__tests__
2. toEqual, toBe simply compare 2 values while toMatchSnapshot is going on its first run capture a value and every other time its going to run it's going to compare your value with the captured snapshot. It's useful when comparing with data that are not supposed to change (In this project the 404 API response)
3. I decided to use the database to store new users rather than calling multiple times the POST route simply for convenience's sake and to have the tests run faster. The reason why I prefer in this scenario comparing API results rather than looking directly in the database is that the API doesn't perform any transformation on the data before storage or on return in the GET routes, so there isn't any reason to look directly in the database and check that said transformation are performed well, and it allows to check more thoroughly that there aren't any unexpected errors in the API. TLDR: So basically I recommend using database to prepare data when having large datasets, and web API to verify the data if there is no transformation done on those data.

[MiffyLiye]

@Faz95210

2. In the 404 API response case, both toEqual({}) & toMatchSnapshot() can work, why choose toMatchSnapshot

   A typical snapshot test case renders a UI component, takes a snapshot, then compares it to a reference snapshot file stored alongside the test. The test will fail if the two snapshots do not match: either the change is unexpected, or the reference snapshot needs to be updated to the new version of the UI component. https://jestjs.io/docs/snapshot-testing

[Faz95210]

@MiffyLiye I do understand that both of these functions can work in that situation but I don't actually have a good reason for this choice, it's mostly a force of habits from seeing this at work...

[xavierchow]

Thank you all, this is good enough for our evaluation, closing.