Skip to content
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

Add test coverage #7414

Open
chrahunt opened this issue Nov 30, 2019 · 2 comments
Open

Add test coverage #7414

chrahunt opened this issue Nov 30, 2019 · 2 comments
Labels
C: tests Testing and related things type: maintenance Related to Development and Maintenance Processes

Comments

@chrahunt
Copy link
Member

chrahunt commented Nov 30, 2019

What's the problem this feature will solve?

Currently, pip does not have any coverage tracking integrated into its test suite. This comes with a few downsides:

  1. Not possible to quickly identify gaps in test coverage
  2. Can't use test techniques like mutation testing, which depend on coverage data
  3. Can't use it as a factor for PR evaluation

The current tox environment configured with coverage-py3 is limited to unit tests only.

Describe the solution you'd like

In a separate tox target, configure pytest-cov/coverage to:

  1. record coverage details for the pip package and sub-packages/modules, as invoked by:
    1. unit tests directly
    2. tests using the script/virtualenv pytest fixture (see tests/conftest.py -> virtualenv_template)
    3. pip itself, as part of build_env.BuildEnvironment.install_requirements
  2. exclude vendored libraries
  3. exclude type-only code (guarded with if MYPY_CHECK_RUNNING)
  4. exclude Python 2 on Python 3 and vice-versa
  5. combine the coverage results for all pips, which may have different paths
  6. support getting coverage while using local paralellization with xdist (i.e. -n option)

If it helps, this could be done in Python 3 only (at first).

I have a basic first implementation here, but when combining the coverage reports the records from the integration tests seemed to be dropped.

Alternative Solutions

  1. Do nothing, which comes at the cost of not having the initially mentioned capabilities

Additional context

@chrahunt chrahunt added C: tests Testing and related things type: maintenance Related to Development and Maintenance Processes labels Nov 30, 2019
@chrahunt
Copy link
Member Author

I'd call this done once we have it mentioned in the docs, along with the instructions for generating the report as mentioned in #7416.

@pradyunsg
Copy link
Member

pradyunsg commented Jul 15, 2020

I think there's a couple more things to do before we close this:

  • Document how to generate coverage reports / run tests while tracking coverage.
  • Document how we treat coverage during development (in general, PRs that make changes should strive to increase the coverage not decrease it?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: tests Testing and related things type: maintenance Related to Development and Maintenance Processes
Projects
None yet
Development

No branches or pull requests

2 participants