feat: add test coverage command in the CONTRIBUTING.md file

[zeelrupapara]

Describe your change:

• add run testcase and see code coverage command in the CONTRIBUTING.md file

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Add or change doctests? -- Note: Please avoid changing both code and tests in a single pull request.
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
• If this pull request resolves one or more open issues then the description above includes the issue number(s) with a closing keyword: "Fixes #ISSUE-NUMBER".

[tianyizheng02]

I think this is a good idea, but IMO it would be more helpful to contributors if the command was for getting the coverage for a single file. After all, it's more likely that a contributor will want to see the coverage for the file that they're working on, rather than the coverage for the entire repo.

[zeelrupapara]

@tianyizheng02 You're right, but in some cases, I want to check which files have the least test coverage so I can contribute by writing those files or functions testcases.
what you think about that because I m facing same issue.

[tianyizheng02]

I want to check which files have the least test coverage so I can contribute by writing those files or functions testcases.

@zeelrupapara That makes sense. In your case, it may be best to just run the pytest command in .github/workflows/build.yml.

I'm hesitant to add the pytest command from build.yml directly into CONTRIBUTING.md because it would become outdated somewhat quickly. As you can see in the file, we sometimes have to add files to be ignored with --ignore=..., and it's likely for the best that contributors refer to build.yml directly so that they get the most up-to-date command.