-
-
Notifications
You must be signed in to change notification settings - Fork 448
Assume if TYPE_CHECKING: ... else: ...
block is covered
#831
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
You can solve this yourself today by adding this to your .coveragerc file:
More details about this setting are here: Advanced exclusion. Since this is something that is configurable by the user, I would rather not change coverage.py to deal with it. |
…e from urxvt to kitty * It doesn't fuck up your terminal colors. * You can use [peek](peek.md) to record your screen. * Easier to extend. feat(pytest#Excluding code from coverage): Exclude the `if TYPE_CHECKING` code from the coverage If you want [other code to be excluded](nedbat/coveragepy#831), for example the statements inside the `if TYPE_CHECKING:` add to your `pyproject.toml`: ```toml [tool.coverage.report] exclude_lines = [ # Have to re-enable the standard pragma 'pragma: no cover', # Type checking can not be tested 'if TYPE_CHECKING:', ] ``` fix(peek): Add note that it works with kitty feat(prompt_toolkit_fullscreen_applications#Pass more than one key): Pass more than one key To map an action to two key presses use `kb.add('g', 'g')`. feat(prompt_toolkit_fullscreen_applications#styles): Add note on how to debug the styles of the components Set the style to `bg:#dc322f` and it will be highlighted in red.
@nedbat - when would you expect code inside |
A few years later, I think you are right that it should be part of the default. If the user wants to measure those lines, they can. |
Can we also add |
@ikonst - I'm not 100% sure that's a good idea, but also as I've painfully discovered, you really mean |
Yeah, obviously in its escaped form. I think the sharp change in coverage would tell you :) |
It can be quite the footgun when your projects are starting from 100% line coverage... |
This is so we can get a more accurate picture of coverage. For more info see: - nedbat/coveragepy#831
This is so we can get a more accurate picture of coverage. For more info see: - nedbat/coveragepy#831
@nedbat Is the |
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
This might become the default in the future, see: - nedbat/coveragepy#831
While coveragepy itself seems to recognized the excluded lines as covered, it seems that uploading the reports to codecov.io does show them as not covered in their reporting. If someone spotted a workaround for that, please let me know. |
I think "excluded" is its own status in coveragepy, are you sure it's "covered" and not "excluded"? Or are you just concerned about coverage %? |
Am I correct that solving this happens in these lines: Lines 152 to 155 in fcdce1d
...+ adding test case(s)? |
Yes, that is where the default exclusions are defined. |
**Context:** 🤔 The current dependency structure within the codebase is complex and difficult to manage effectively. This PR introduces architectural layering using `tach` to enforce clearer dependency boundaries between different parts of PennyLane. We are adopting a standard four-layer architecture: "ui", "tertiary", "auxiliary", and "core", - **ui**: This should NOT be in our source code and instead is a user-interface layer. Examples of using this layer are `from pennylane import *` or `import pennylane as qml`. - **tertiary**: These modules can depend on *both* "auxiliary" and "core" and its itself. - **auxiliary**: These modules can depend on *only* "core" and itself. - **core**: These modules can not depend on anything outside this layer. This is the first step to untangling PennyLane source code. **Description of the Change:** 📝 * Updates `tach` to latest supported version. * **`tach.toml` Configuration:** Updated `tach.toml` to define all `pennylane` modules. Modules clearly fitting the new architecture were assigned to their respective layers ("ui", "tertiary", "auxiliary", "core"). Modules needing further analysis remain unlayered for future PRs. * Changed `QuantumFunctionError` in `math` module to `ValueError`. ❗ `labs` and `ftqc` are still considered "closed" modules (nothing can import from them). ❗ * Updates `.coveragerc` to ignore `TYPE_CHECKING` conditionals (nedbat/coveragepy#831). * **Import Optimization:** Reviewed and updated import statements in relevant modules to import only strictly necessary components, minimizing dependencies without code refactoring. * **Refactoring:** Removed the dependency on `pennylane.operation.Operator` from `pennylane/numpy/tensor.py` . This dependency contributed to circular import issues, and code coverage indicated the relevant logic was untested and likely unused, justifying its removal. **Benefits:** ❤️ * Enforces dependency rules via `tach` for all modules assigned to a layer, preventing invalid imports and improving architectural integrity. * Provides a clearer, more organized structure for dependencies, enhancing code maintainability. * Establishes a foundation to prevent problematic dependency cycles and invalid layer traversals going forward. **Possible Drawbacks:**⚠️ As a direct result of enforcing these architectural layers there are few issues I can forsee, - modules assigned to specific layers can no longer use the top-level `import pennylane as qml` pattern. Imports must target specific submodules according to the allowed dependencies defined in `tach.toml`. This enforces the intended layering and prevents unintended coupling. - a developer might hit a situation where they *need* to do something that involves breaking this dependency graph. In this case, they should consider re-factoring or just temporarily disable this dependency requirement in the `tach.toml`. [sc-88205] --------- Co-authored-by: Astral Cai <[email protected]> Co-authored-by: Christina Lee <[email protected]>
**Context:** 🤔 The current dependency structure within the codebase is complex and difficult to manage effectively. This PR introduces architectural layering using `tach` to enforce clearer dependency boundaries between different parts of PennyLane. We are adopting a standard four-layer architecture: "ui", "tertiary", "auxiliary", and "core", - **ui**: This should NOT be in our source code and instead is a user-interface layer. Examples of using this layer are `from pennylane import *` or `import pennylane as qml`. - **tertiary**: These modules can depend on *both* "auxiliary" and "core" and its itself. - **auxiliary**: These modules can depend on *only* "core" and itself. - **core**: These modules can not depend on anything outside this layer. This is the first step to untangling PennyLane source code. **Description of the Change:** 📝 * Updates `tach` to latest supported version. * **`tach.toml` Configuration:** Updated `tach.toml` to define all `pennylane` modules. Modules clearly fitting the new architecture were assigned to their respective layers ("ui", "tertiary", "auxiliary", "core"). Modules needing further analysis remain unlayered for future PRs. * Changed `QuantumFunctionError` in `math` module to `ValueError`. ❗ `labs` and `ftqc` are still considered "closed" modules (nothing can import from them). ❗ * Updates `.coveragerc` to ignore `TYPE_CHECKING` conditionals (nedbat/coveragepy#831). * **Import Optimization:** Reviewed and updated import statements in relevant modules to import only strictly necessary components, minimizing dependencies without code refactoring. * **Refactoring:** Removed the dependency on `pennylane.operation.Operator` from `pennylane/numpy/tensor.py` . This dependency contributed to circular import issues, and code coverage indicated the relevant logic was untested and likely unused, justifying its removal. **Benefits:** ❤️ * Enforces dependency rules via `tach` for all modules assigned to a layer, preventing invalid imports and improving architectural integrity. * Provides a clearer, more organized structure for dependencies, enhancing code maintainability. * Establishes a foundation to prevent problematic dependency cycles and invalid layer traversals going forward. **Possible Drawbacks:**⚠️ As a direct result of enforcing these architectural layers there are few issues I can forsee, - modules assigned to specific layers can no longer use the top-level `import pennylane as qml` pattern. Imports must target specific submodules according to the allowed dependencies defined in `tach.toml`. This enforces the intended layering and prevents unintended coupling. - a developer might hit a situation where they *need* to do something that involves breaking this dependency graph. In this case, they should consider re-factoring or just temporarily disable this dependency requirement in the `tach.toml`. [sc-88205] --------- Co-authored-by: Astral Cai <[email protected]> Co-authored-by: Christina Lee <[email protected]>
if typing.TYPE_CHECKING
blocks are never run but are still counted as needing test coverage.( https://docs.python.org/3.7/library/typing.html#typing.TYPE_CHECKING )
Example
You have to add
# pragma: no_cover
to theif
block here because coverage.py assumes TYPE_CHECKING to be False, and therefore assumes one of the blocks does not have a test case. It would be good if you didn't have to, and blocks requiring TYPE_CHECKING to be True are assumed to not need test cases.The text was updated successfully, but these errors were encountered: