Added static type checker test for unknown error codes

[angelayzheng]

Proposed Changes

Added a test to improve code coverage in static_type_checker.py. Ensures that StaticTypeChecker._add_message returns early without error if an unsupported mypy error code is passed in.

Previous coverage report: https://coveralls.io/builds/81479893/source?filename=packages%2Fpython-ta%2Fsrc%2Fpython_ta%2Fcheckers%2Fstatic_type_checker.py

...

Screenshots of your changes (if applicable)

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type	Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
✨ New feature (non-breaking change that adds functionality)
🐛 Bug fix (non-breaking change that fixes an issue)
♻️ Refactoring (internal change to codebase, without changing functionality)
🚦 Test update (change that only adds or modifies tests)	x
📚 Documentation update (change that only updates documentation)
📦 Dependency update (change that updates a dependency)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

• I have performed a self-review of my changes.
  • Check that all changed files included in this pull request are intentional changes.
  • Check that all changes are relevant to the purpose of this pull request, as described above.
• I have added tests for my changes, if applicable.
  • This is required for all bug fixes and new features.
• I have updated the project documentation, if applicable.
  • This is required for new features.
• I have updated the project Changelog (this is required for all changes).
• If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

• I have verified that the CI tests have passed.
• I have reviewed the test coverage changes reported by Coveralls.
• I have requested a review from a project maintainer.

Questions and Comments

(Include any questions or comments you have regarding your changes.)

[coveralls]

Coverage Report for CI Build 35781130294

Coverage increased (+0.03%) to 90.907%

Details

• Coverage increased (+0.03%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	4091
Covered Lines:	3719
Line Coverage:	90.91%
Coverage Strength:	17.67 hits per line

---

💛 - Coveralls

[david-yz-liu]

In general, private methods should not be called directly in tests. A better test case is one that uses a Python file that triggers a mypy error, but an error that does not appear in the dictionary of supported errors in the checker.

[angelayzheng]

Thank you for the feedback!

I started implementing a test case using a Python file triggering an unsupported mypy error. However, in the process_module method, any unsupported mypy errors are already filtered out if they do not match any of the SPECIFIC_PATTERNS regex. Thus, the _add_message method would never get called, and line 123 (the early return that was previously not covered by unit tests) would subsequently not be reached.

Lines 103-108 of static_type_checker.py:

specific_pattern = self.SPECIFIC_PATTERNS.get(common_data["code"])  # The error code would not be in SPECIFIC_PATTERNS, so this returns None
if specific_pattern:  # Since specific_pattern is None, we do not enter this if block
    specific_match = specific_pattern.search(common_data["message"])
    if specific_match:
        specific_data = specific_match.groupdict()
        self._add_message(common_data, specific_data)  # This call is never reached

Could you please advise on what next steps would be best to take?

[david-yz-liu]

@angelayzheng ah excellent question. In this case, please mock the subprocess.run call to return an error message that isn't on the list, in the expected format (you could try running mypy separately to see the output format). You can use unittest.mock's patch function (take a look at other tests where we've done some mocking).

[angelayzheng]

Hi Professor @david-yz-liu,

I've pushed a new commit with the updated tests, which mock the subprocess.run call.

One question: I believe I may have taken a slightly different approach than what you were referring to. With the patch.dict method already adding the unknown pattern into SPECIFIC_PATTERNS during the call to process_module, the subprocess.run patch could technically be removed. Then mypy would be actually called on mypy_unknown_error.py, and it would still enter StaticTypeChecker._add_message (due to the patch to SPECIFIC_PATTERNS), inside which the mypy code func-returns-value would be unrecognized and return early.

Please let me know what you think of this approach. Thank you!

[david-yz-liu]

Hi @angelayzheng, yes I'm happy patching SPECIFIC_PATTERNS and removing the patch for subprocess.run.

[angelayzheng]

Hi Professor @david-yz-liu, sounds good! I've pushed a new commit with the subprocess.run patch removed.

[david-yz-liu]

Nice work, @angelayzheng!