Move to using interface for better mocking to graphql server

[namkyu1999]

Proposed changes

Following up on the last PR, I've converted all packages to the interface pattern for better mocking in graphql server. I made this PR based on this layered architecture.

Issue No. #3931
Prev PR. #3933

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

• New feature (non-breaking change which adds functionality)
• Bugfix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices applies)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have signed the commit for DCO to be passed.
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Dependency

• Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer: @S-ayanide @amityt

[namkyu1999]

I fixed all codes using the interface. So no more global variable mongo operator now 😄

[namkyu1999]

A is current Changes, and B is my proposals. For example in the chaoshub package, As of now A, When I make a unit test in the ChaosHubService(service layer), I cannot create ChaosHubOperator Mock(repository layer) because ChaosHubOperator is not an interface but a struct. So, For better testing, I propose B. I want to know your opinion. @imrajdas @gdsoumya @amityt @S-ayanide

[gdsoumya]

@namkyu1999 currently the A approach needs you to mock the dboperator instead of the service specific operator so you mock every db method that exists. Imo that should work fine if we can create a generic in-memory mock impl of the db but if that's too complex we can go with B but imo we should avoid going with B if we can as the service specific operator might still have some business logic that we need to test. Also if we go with B then there's no point in having a db interface in the first place as we can just always mock the service specific operator.

[namkyu1999]

@gdsoumya Thanks for your reply. I agree with your opinion. So No more architectural changes here. And I will make the unit test code in the ChaosHub package this week and raise a different PR.

[namkyu1999]

Here's my sample unit test code PR

#3946

[Saranya-jena]

Hi @namkyu1999, can we update the following terminologies in all the logs :
cluster/agent -> chaos infrastructure
workflow -> chaos experiment
experiment -> chaos faults

[namkyu1999]

Hi @namkyu1999, can we update the following terminologies in all the logs : cluster/agent -> chaos infrastructure workflow -> chaos experiment experiment -> chaos faults

@Saranya-jena,
Do I just need to change the terminology in the logs, or do I need to change the terminology in the entire codebase, including package names? And whatever it is, it doesn't seem to be very relevant to this PR, so is it okay to create a new issue and raise a PR?

[Saranya-jena]

Hi @namkyu1999, can we update the following terminologies in all the logs : cluster/agent -> chaos infrastructure workflow -> chaos experiment experiment -> chaos faults

@Saranya-jena, Do I just need to change the terminology in the logs, or do I need to change the terminology in the entire codebase, including package names? And whatever it is, it doesn't seem to be very relevant to this PR, so is it okay to create a new issue and raise a PR?

You can only change the logs as I am making the changes in the codebase(currently in a separate branch). Yes you can raise a separate PR for this, posted here to track this.