You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As seen in #54, specific parameter(s) are required in the checker function signature in order to signal to Flake8 that the checker needs to be run on the specified input. While this pitfall was identified previously, a regression was introduced by #53 that prevented Flake8 from determining that this plugin needed to be run. This case is missed by our unit tests, as the way they are mocked assumes that Flake8 has invoked the checker & provided the information that was requested.
To guard against any future regressions, a test case should be developed that invokes Flake8 on an input & checks that the flake8-annotations checker is being run. From some initial mucking around, it seems like a simple stdin test case may be a good candidate for at least an initial approach.
Blocking this for now as there seems to be an upstream issue with Coverage 5.x causing CI to fail when the proposed test is added (reported here).
While this seems to be resolved by pinning Coverage below 5.0, since this is not a critical test let's wait for the issue to be triaged before deciding on the resolving action.
A workaround has been identified in the upstream issue, allowing us to unblock & add this test into the next dev branch.
The immediate issue is apparently caused by the lack of an existing .coverage file when attempting to append coverage information. By specifying parallel runs in a .coveragerc file, the issue is resolved. It is not clear why the presence of subprocess brings out this issue, but the workaround sufficies for now.
As seen in #54, specific parameter(s) are required in the checker function signature in order to signal to Flake8 that the checker needs to be run on the specified input. While this pitfall was identified previously, a regression was introduced by #53 that prevented Flake8 from determining that this plugin needed to be run. This case is missed by our unit tests, as the way they are mocked assumes that Flake8 has invoked the checker & provided the information that was requested.
To guard against any future regressions, a test case should be developed that invokes Flake8 on an input & checks that the flake8-annotations checker is being run. From some initial mucking around, it seems like a simple stdin test case may be a good candidate for at least an initial approach.
Using a simple test case:
Flake8 should yield a
TYP001
error:The text was updated successfully, but these errors were encountered: