> > During development, web frameworks often spawn a subprocess to serve >> requests so that they can reload the code if it changes. You might be >> measuring only the first process, and not the spawned process that is >> actually doing the work. >> > Ah, thanks Ned. That makes sense. I suspect the subprocess coverage > section in the documentation might be helpful. >
I fiddled around with sitecustomize.py, defining COVERAGE_PROCESS_START, and tweaking the --concurrency flag. Nothing worked. In fact, my code coverage went to zero. :-( I then looked at the flask docs to see if it had some clues and noticed its run command has a --no-reload flag. Setting that worked like a charm. Since I'm not actively fiddling on-the-fly when running tests, that's perfect. Now I have nice coverage stats. I figured I'd toss out my solution in case someone else comes along looking for flask+coverage assistance. Skip
_______________________________________________ code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-le...@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: arch...@mail-archive.com
