Test Backend Submission - Jonathan Dai

[agreatfool]

Hi Xavier,

I have finished the backend test, and made a pull request. Please have a look. And also document could be found here: README.md.

Best Regards, Jonathan Dai

[MiffyLiye]

Hi Jonathan, I have some questions about the architecture and the test strategy.

1. In the code, there are folders like controller, dao, model, database, what is the responsibility of each layer? Unlike traditional MVC framework, this architecture doesn't have service layer, and controller layer calls dao layer directly, Can you compare this approach with skinny controller (fat model) approach, and service layer approach?

2. In the test code, there are some server API tests, with test data prepared in a global before section with stubs. Can you compare this approach with preparing test data in each test case (in describe.before or describe.it section) approach? Can you compare the benefit & cost of using real Redis service in test cases without stubs?

3. About the test scenarios in test cases, most of them are calling one API and assert the response, but the API specifications are more than API responses, e.g., user created with POST /user should be retrieved from GET /user/:id. Can you design a test strategy that has good support for this kind of specifications?

4. Similar to the 3rd question, many assertions in test cases are more about format, less assertions on business meaning, e.g. GET /usergeo/nearby I would expect the test case to prepare two users, one in the range, the other out of the range, when get nearby users, the assertion assets one user is in the response, and the other user is not in the response. Can you design a test strategy that has good support for assertions with more business meaning?

[agreatfool]

Hi @MiffyLiye, Let me answer the questions one by one.

Question 1:

Functionality of each layer:

• controller: Handling incoming requests, validate params via Joi, and send verified request to service layer (in current test implementation, "service logic" solved directly in controller).
• database: Database handler of redis, utiltiy functions at all. This layer is a helper of database handling.
• model: Model object of business concept, like "user", "friend", "cart", "item", "shop", etc.
• dao: Data access objects, define functions to help the CRUD of model objects. In this layer, there is no business logic.

Let me explain why there is no service layer in codes. Since this test is a small test, there is almost no business logic here. So I omitted the service layer according to the rule "quick and dirty". In other projects of mine, including office projects and side projects, there are service layer existing.

For your question, I think skinny controller fat model (or service approach) is better than leaving logics all in the controller layer. Controller shall only accept requests and validate them, then move the valid requests into model layer, this could separate duties very clearly.

For the choice between skinny controller fat model / service approach. If business logic is not too complex, it's good to use fat model, just move domain logic into model layer directly. And if the project or system is very complex, it's good to use service approach (n-tiers arch), separate domain logic into services. And I prefer service approach in the daily work (If the project I can control), since I think this approach is more clear and flexible.

---

Let me explain a bit about the unit test part. As you know the test project is a bit simple and lack of real business logic. So my concept of unit test part is: Using correct skills/libraries and make simple unit test codes to show you guys how I do unit test in other projects. And as you can see, the logic of test case maybe a bit too simple as you mentioned in questions.

---

Question 2:

As I mentioned above, I thought about the logic part too simplistically. In real case, preparing global data and preparing data for single test case are all possilbe to happen. Difference:

• global data: For the scenario all test cases in one spec are all interrelated, we can create global data to let all the test cases use. For example:
  • create global data: users: [u1, u2, u3, ...], total 10 users
  • test case 1, getUsersAll: expect array length to be 10
  • test case 2, deleteUser: expect the returned array length of getUsersAll to be 9, after deleteUser action
• single case data: For the scenario all test cases in one spec are all doing their own logics, not interrelated. Then data shall be prepared before each test case by themself.

Using real Redis service in test:

• benefit:
  • could ensure the redis api usage is consistent with programmer. For example:
    • programmer think the api A of redis shall return object (actually this api would return number as result), and wrote the codes along with test cases, and he made some test data and redis stubs, as you can imagine, the case passed
    • if real redis is used, this test case could not pass
  • could test some redis API with logic inside, like GEOREDIUS
    • some edge case, programmer may think it's ok, but the result of redis is not
  • could test the case when redis is failed
    • test the reaction of app is expected or not when redis is down
• cost:
  • make the unit test more complex, since test framework have to ensure the redis facility available
  • commonly, real redis using in tests requires CI system, then unit test case could foucus on it's business logic

---

Question 3 and 4:

I have added two spec as Question 3 and Question 4 asked. Please have a look at:

• test/server/2 - user_business.spec.ts
• test/server/3 - lbs_business.spec.ts

[xavierchow]

Thanks all, this is good enough for our evaluation, closing the PR and we will get back to you soon @agreatfool .