.coverage.prefork

!coverage.py: This is a private format, don't read it directly!{"lines": {"/home/elyezer/code/celery/examples/app/myapp.py": [35, 39, 24, 25, 27, 28, 29]}}

.coverage.solo

!coverage.py: This is a private format, don't read it directly!{"lines": {"/home/elyezer/code/celery/examples/app/myapp.py": [35, 37, 39, 24, 25, 27, 28, 29]}}

gistfile1.txt

git clone https://github.com/celery/celery.git
cd celery
git checkout 3.1
cd examples/app/

mkvirtualenv -p python3 celery
pip install celery==3.1 coverage threadpool

cat > ~/.virtualenvs/celery/lib/python3.4/site-packages/sitecustomize.py << EOF
import coverage
coverage.process_startup()
EOF

cat > .coveragerc << EOF
[run]
include=myapp
source=.
concurrency=
    thread
    multiprocessing
EOF

export COVERAGE_PROCESS_START=.coveragerc

# Run celery using the default prefork pool class
# and call the add.delay from another window
# then quit the celery process with Ctrl+c
celery -A myapp worker -l info

# Check for the .coverage.* files generated
# They will not have the line 37 which is the body of the add task

# Clean up all previous coverage data files and quit the window where add task was run
rm .coverage.*

# Now run the celery using the solo or threads pool class
# and call the add.delay from another window.
# then quit the celery process with Ctrl+c
celery -A myapp worker -l info -P solo

# Check for the .coverage.* files generated
# They will have the line 37 which is the body of the add task

# Considering the prefork and solo pool cls the former generates more than one coverage data file,
# on the other hand the latter will generate nly one file.

# The additional files on this gist shows the difference on coverage data being captured depending on the pool cls used.
# threads also generates the same output for the solo pool cls