django app cannot connect to cassandra when run with coverage #445
We have a django app that talks with 2 DBs - postgresql and cassandra. Though the django app's runserver starts up fine and work (with ./manage.py runserver) as well as we have a gunicorn+nginx setup that works fine, when I try to measure coverage using a command like this:
things don't work as the django app bails out with connection failure with cassandra.
Nothing changes across running with coverage or running normally. Cassandra server has not stopped across these 2 ways of running the server. Is there some issue with authentication that cannot be taken care when running with coverage. All the auth is anyway in the django settings, and there is no hack or anything that goes beyond django structure.
Here is the trace of the failure:
And here is how it works fine without coverage:
System check identified no issues (0 silenced).
I have installed the coverage tool today and I can see the version to be 4.0.2 as in /usr/local/bin/coverage, /usr/local/bin/coverage2 and /usr/local/bin/coverage-2.7.
I am using ubuntu 14.04 and python 2.7.
The text was updated successfully, but these errors were encountered:
Here is the output of pip freeze:
Even if this worked and I was able to get some coverage output, it is incorrect. I ran my tests that made the code flow across all the functions in my Django views.py; but the coverage shown is 0%! Here is the process I used:
$ coverage run --source='.' manage.py runserver
Then I ran my testcases that make several http calls for exercising several APIs in the code including all possible branches of code.
Then I used ctrl-C to make the server quit which created the .coverage file, and I got the output using coverage report/coverage html.
Is there anything wrong in this process?
Here's the steps to create a minimal test environment, and reproduce the issue:
1, Create a virtualenv (I'm using
2, Activate the venv:
3, Install packages:
4, Create a django project:
5, Edit the django
Note: you need to have Cassandra installed and running on your test environment.
I hope that's enough for you, and let me know if you need more information.
I just checked in the initial report above that the coverage version was 4.0.2 and when I ran
Also, this is where coverage runs from on my server:
Please ignore my last comment. The new version is 4.0.3. I assumed it's the same as the older one, when it's not, as the earlier one is 4.0.2.
However; still wanted to understand if the current version 4.0.3 has this fix, or I am still running a version without the fix.
@nedbat : I have created a test application that runs using a virtual environment. Please get it here. Please use the README to set the project. I have included a script
However; I am running into a new problem and not able to get to the coverage step. This is the issue I am facing:
My app runs fine when started in the usual way:
Please note that I am inside my virtual environment. The state of my virtual environment is in sync with the
Calling the test API also works fine:
However; when I try to run coverage.py, I get into the following:
Somehow the django settings cannot be loaded, and I am not sure why. Is there something different needed to make coverage.py work with django while running in a virtual environment? I did not have this issue earlier when I was running things globally (not in a virtual environment). I tried to look up; but could not find much on this.
Once this works, I would be able to hopefully reproduce the issue.
Adding output of
I found the issue. It was some messy conflict between package names. I create the django project with the name 'coverage' and it was conflicting with the package name that coverage.py uses. Changed my django project name to 'covtest' and things are fine. I have pushed the changes to the sample app repository. Please pull the latest.
Post fixing the above, I collected the coverage data and I get the problematic data. Here is a description:
Then I make an API call
Logged by the test server run by coverage.py
Which executes this piece of code in
You see the output 'All well!' on the prompt that is returned by this API. Here is the binding of the URL to this API:
Now I stop the running server
I see the coverage data file in the directory:
And I collect the coverage report which shows 0% coverage in
Following the instructions and fixing the problems I found on the way, I ran this:
I did not try to fix this last error. My advice is that you provide and test detailed instructions to create a reproducer for this bug. The proposed reproducer is a good step forward but it fails in a number of ways and cannot be used effectively.