No access to target directory in configuration file breaking integration with IDE

Issue #590 closed
Joshkitchens27
created an issue

I'm trying to set up my working environment using Visual Studio Code, and have run into an issue with Coverage that I can't find a solution to.

I'm trying to integrate automation of my unit tests with my VS Code environment, in which upon certain events, a command is executed which invokes my unit tests and reports the results in the IDE.

"python -m pytest --cov=Scripts --cov-config ${workspaceRoot}/.coveragerc --cov-report html:${workspaceRoot}/locale/coverage_html --cov-report xml:${workspaceRoot}/local/coverage.xml --cov-report annotate:${workspaceRoot}/local/coverage_annotate ${workspaceRoot}/UnitTests/ "

Here, ${workspaceRoot} is provided by the automation utility to point to the current 'home' directory of my project.

Unfortunately, pytest-cov does not expose an option to specify an output file location, likely because coverage does not expose a way to do so outside using an environment variable.

The problem with the approach I've defined here is that because it's VS Codes plugin system doing the actual command invocation, my "current working directory" at execution time is the Microsoft VS Code folder in C:\Program Files, meaning there's no write permissions and coverage throws an exception.

My solution would be to use the data_file field in the .coveragerc file to point to my project directory, but that would mean I have to hardcode the path to the project on my local machine, which doesn't work when I move the coverage analysis to our CI system.

If there was a key-word exposed in the config file which exposed the path to the target module, I could use that to set the data_file path properly.

Am I making sense? Is there some mechanism I'm not aware of that could help me here?

Comments (3)

  1. Joshkitchens27 reporter

    Hi Ned,

    Thanks for the fast response.

    My hope was to avoid environment variables if possible, but perhaps that's not the case.

    The core of the issue is that I'm not invoking coverage myself, and the application that is has a working directory at runtime within Program Files, which is write-protected, so Coverage throws an exception when it can't write the .coverage file.

    My hope was to be able to configure coverage to use the directory containing the target module for the data_file, rather than relying on the . operator which expands to "current working directory" since in my case, that directory isn't an option.

  2. Log in to comment