Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why doesn't coverage.py properly measure Flask's runserver command?

I'm trying to figure out which lines of a Flask application are being run. I start Flask like this:

coverage run manage.py runserver

Output looks like this:

 * Running on http://127.0.0.1:5000/
 * Restarting with reloader

manage.py looks like this:

#!/usr/bin/env python
from flask.ext.script import Manager

from my_flask_app import app

manager = Manager(app)

if __name__ == '__main__':
    manager.run()

I then access various parts of the application via HTTP.

When I look at the coverage HTML report, it says only the method definitions are covered, not the actual bodies of the methods.

I suspect it's because the methods are being executed by a subprocess which is not covered by coverage.py.

Any ideas?

like image 976
Julian Pistorius Avatar asked Oct 24 '13 22:10

Julian Pistorius


People also ask

What happens when we run Python manage PY Runserver?

This executes the command and perform base checks if needed. This performs normal checks and migration checks if needed and then calls a function called handle . This function makes all the checks regarding IP address like checking port, IP address format ipv4 or ipv6.

How is coverage calculated Python?

"It monitors your program, noting which parts of the code have been executed, then analyzes the source to identify code that could have been executed but was not." It's the percentage of potentially-executable code which is executed during tests, generally measured per-line.

What is coverage in Django coverage?

Code coverage is a simple tool for checking which lines of your application code are run by your test suite. 100% coverage is a laudable goal, as it means every line is run at least once. Coverage.py is the Python tool for measuring code coverage.


1 Answers

So it turns out that the problem is related to the 'reloader' message above. The coverage report is correct when I start Flask like this instead:

coverage run manage.py runserver -R

Output then only contains this:

* Running on http://127.0.0.1:5000/

This way it doesn't start up the server in a separate process, and coverage works great.

I found this solution thanks to this related Django question:

Why doesn't coverage.py properly measure Django's runserver command?

like image 122
Julian Pistorius Avatar answered Sep 30 '22 20:09

Julian Pistorius