Testing 101

[kshitij10496]

This PR lays the basic pattern I propose to use for writing all kinds of tests. The implementation might seem complicated (even an overkill) at first but the pattern is rather intuitive and easy to grasp.

Basically, I've separated the testing into 3 complementary parts:

1. Handler tests

   • What is this? : white-box testing that the handler works with dummy data.
   • Purpose: Does each handler work as expected?
   • Bonus: Local development of endpoints independent of the requirement of having a production database. TDD FTW!

2. Routing tests

   • What is this?: black-box testing the service; primiarily the URL routing.
   • Purpose: Does each service work as expected?

3. Integration tests

   • What is this?: testing with a test DB using live data.
   • Purpose: How does each service work integrated with the DB?

Alternatively, we could have merged all 3 of them into a single "End-to-End" testing pattern. But then, it won't be Clean Architecture according to Uncle Bob.

The best thing about the new implementation is that it allows us to develop the API independent of the underlying database layer. 🕶

I would be interested in discussing the possible pros and cons of the tests below. 😄

cc @icyflame @ghostwriternr @thealphadollar @themousepotato @Ayushk4

Resolves #10

[icyflame]

@kshitij10496 That looks like a good plan, but I have a couple of pointers here.

• It seems like what you mean by "handler testing" is actually unit tests for the handler. Is that what you mean?
• I don't understand the point of the second set of tests. If you are using a router like mux, then you don't need this because the router will always work. If you are rolling your own router, then these tests would basically be the combination of unit and integration tests of that router. So, why do you need these tests? 🤔
• Again, here I think you mean Integration / functional tests for the whole service?

I think naming matters here, especially because testing is confusing as it is, and if you create your own terminology IMHO it will confuse people who are used to the standard terminology. You should think about this. 🙂

[kshitij10496]

It seems like what you mean by "handler testing" is actually unit tests for the handler. Is that what you mean?

Technically, it will be a "unit test" only when we mock the database interaction.

If you are using a router like mux, then you don't need this because the router will always work.

I think you are right here. This might sound a bit redundant at first. However, the routing tests sort of overarch the testing of each service rather than the handler. Basically, I wasn't convinced to combine this step in the handler tests as it would only confuse the testing process.

I think you mean Integration / functional tests for the whole service

Yes! Essentially, this would be a sanity check for the handlers as opposed to using mock data while developing.

P.S: I've added references and the purpose of each test above.

[kshitij10496]

Ping @icyflame @thealphadollar @themousepotato @Ayushk4

I've implemented all the handler tests for now. 🎉

[kshitij10496]

Merging in 24 hours if nobody has any issues! 😅