[DevEx] Improve Code Coverage

[becevka]

Summary
We need to improve overall code coverage and stability

Describe the solution you'd like
We have integrated Playwright in our code, and removed existing Postman based-tests, now we need to improve coverage to achieve at least 80% of line rate.

Acceptance criteria

• Scenario: Improve code coverage to 70% or more
  Given the current code coverage is 42%
  When more tests are added
  Then the code coverage should reach at least 70% or more

[chungthuang]

To support the Dev Recruit team, we should test the APIs for the Applicant and Opportunity collections. The typical flow is a team lead will create an opportunity for a project. Then people will apply for the opportunity. When the role is filled, the opportunity will be unpublished, but not deleted so it can be reused in the future. To test this, we first need to make sure there is a project because an opportunity references a project. Then we need to test create, get, list and update opportunity APIs. Finally, we need to test create and get applicants.

[nikita-pardeshi-github]

As part of code coverage, we verify if each line of code is executed at least once. I tested two APIs in total which are listed as below.

• Project API:
  In project api, I basically tested two scenarios to ensure each line of project api code is called at least once.

   _Test Data_ : Created projects with and without associating team
  
     - _Scenario 1_ : 
           _API endpoint_ : /api/projects/{project-slug}  (Team is associated with a project) 
           _Method_ : GET
           _Test_ : Fetch the project using above endpoint and compare expected project attributes with actual attributes.
  
      - _Scenario 2_ : 
           _API endpoint_ : /api/projects/{project-slug}  (Test project details when team is not associated with it) 
           _Method_ : GET
           _Test_ : Fetch the project using above endpoint and compare expected project attributes with actual attributes.           
  

• Opportunity API:
  In opportunity api, I basically tested two scenarios. First scenario was to fetch all the available opportunities and second was to fetch the opportunity with specific id.

  _Test Data_ : Create opportunities with different details
  
     - _Scenario 1_ : 
           _API endpoint_ : /api/opportunities
           _Method_ : GET
           _Test_ : Fetch the available opportunities using above endpoint and compare expected opportunities attributes with actual attributes.
  
      - _Scenario 2_ : 
           _API endpoint_ : /api/opportunities/{id}  
           _Method_ : GET
           _Test_ : Fetch single opportunity with specific id number using above endpoint and compare expected opportunity attributes with actual attributes.           
  

[dbradham]

@chungthuang @becevka are there any specific reasons we want to remove postman tests?

Also, is the goal here to have 70% coverage, or 80% coverage? Are these purely internal standards, or are they tied to any regulatory/control systems?

[dbradham]

We are using Playwright because it emphasizes end to end testing.

The numbers here are arbitrary, but it would help to align on an internal metric or goal for code coverage.

[dbradham]

We want to improve code coverage in the following files. @nikita-pardeshi-github will post test cases here for review as a next step.

• src.api.user-recommendations.controllers
• src.extensions.users-permissions.server.services
• src.api.user-recommendations.controllers
• src.api.profile.content-types.profile
• src.api.google-meet.content-types.google-meet
• src.api.github-repo.services
• src.api.github-repo.controllers
• src.api.applicant.content-types.applicant