Test coverage for the search scheduler

[olivierobert]

Overall, there are not many unit tests for the codebase but one of the packages that are tested is scheduler. However, why not test the public methods such as ScheduleKeywordParser or ScrapResult as these are exposed to the rest of the application?

In addition, this would also might put in question if many of the other methods should not be exported e.g., PrintSearchResult, GetSearchResult, etc. should probably be printSearchResult, getSearchResult, etc.

[rashikzaman]

A lot of business logic in the code-base are directly db related. This kind of test involves mocking db client. Sadly, I still need to learn mocking db layer. However, since I used interfaces across the layers, mocking should be done pretty easily.

Other than the tests in scheduler packages, I've done some end-to-end test in http package. But writing end-to-end to cover all edge cases is pretty lengthy process.

ScheduleKeywordParser or ScheduleKeywordParser methods directly depends upon querying google search result page due to their dependency on getSearchResult method. One way to mock test this were to use mock http client and use dependency injection. I need to study how to do these properly.

[rashikzaman]

Methods in the scheduler packages are properly encapsulated now. This is the pull request

[olivierobert]

Thank you for your comments and efforts 👍