coveragepy
coveragepy copied to clipboard
Branch condition covered but labeled as uncovered
Bug Description The following code says a branch condition is never false when it is.
To Reproduce Python code to reproduce the issue (parsers.py):
import unittest
def parse_sms(text):
data = {}
for i, split in enumerate(text.split(",")):
if i == 0:
data["name"] = split.title()
print(len(data['name'].split()) == 1)
if len(data['name'].split()) == 1:
return None
continue
return data
class TestParsers(unittest.TestCase):
def test_parse_sms(self):
messages = [
"John Doe, Jane",
"Jane, John Doe",
]
for message in messages:
parse_sms(message)
Command to reproduce the issue:
python -m coverage erase
python -m coverage run --branch -m unittest parsers.py
python -m coverage html
I expected line 9 to be both True and False, but the coverage report says it is never False. The print statement on line 8 prints both False and True.

Relevant details:
$ python --version
Python 3.9.13
$ python -m coverage --version
Coverage.py, version 7.0.3 with C extension
$ python -m coverage debug sys
-- sys -------------------------------------------------------
coverage_version: 7.0.3
coverage_module: C:\Users\...\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\coverage\__init__.py
tracer: -none-
CTracer: available
plugins.file_tracers: -none-
plugins.configurers: -none-
plugins.context_switchers: -none-
configs_attempted: .coveragerc
setup.cfg
tox.ini
pyproject.toml
configs_read: -none-
config_file: None
config_contents: -none-
data_file: -none-
python: 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
platform: Windows-10-10.0.19042-SP0
implementation: CPython
executable: C:\Users\...\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\python.exe
def_encoding: utf-8
fs_encoding: utf-8
pid: 6636
cwd: ...
path: ...
environment: HOME = C:\Users\...
PYTHONPATH = ...
PYTHONUSERBASE = C:\Users\...\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages
TEMP = C:\Users\...\AppData\Local\Temp
TMP = C:\Users\...\AppData\Local\Temp
command_line: C:\Users\...\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\coverage\__main__.py debug sys
sqlite3_sqlite_version: 3.37.2
sqlite3_temp_store: 0
sqlite3_compile_options: ATOMIC_INTRINSICS=0, COMPILER=msvc-1929, DEFAULT_AUTOVACUUM,
DEFAULT_CACHE_SIZE=-2000, DEFAULT_FILE_FORMAT=4,
DEFAULT_JOURNAL_SIZE_LIMIT=-1, DEFAULT_MMAP_SIZE=0, DEFAULT_PAGE_SIZE=4096,
DEFAULT_PCACHE_INITSZ=20, DEFAULT_RECURSIVE_TRIGGERS,
DEFAULT_SECTOR_SIZE=4096, DEFAULT_SYNCHRONOUS=2,
DEFAULT_WAL_AUTOCHECKPOINT=1000, DEFAULT_WAL_SYNCHRONOUS=2,
DEFAULT_WORKER_THREADS=0, ENABLE_FTS3, ENABLE_FTS4, ENABLE_FTS5,
ENABLE_JSON1, MALLOC_SOFT_LIMIT=1024, MAX_ATTACHED=10, MAX_COLUMN=2000,
MAX_COMPOUND_SELECT=500, MAX_DEFAULT_PAGE_SIZE=8192, MAX_EXPR_DEPTH=1000,
MAX_FUNCTION_ARG=127, MAX_LENGTH=1000000000, MAX_LIKE_PATTERN_LENGTH=50000,
MAX_MMAP_SIZE=0x7fff0000, MAX_PAGE_COUNT=1073741823, MAX_PAGE_SIZE=65536,
MAX_SQL_LENGTH=1000000000, MAX_TRIGGER_DEPTH=1000,
MAX_VARIABLE_NUMBER=32766, MAX_VDBE_OP=250000000, MAX_WORKER_THREADS=8,
MUTEX_W32, SYSTEM_MALLOC, TEMP_STORE=1, THREADSAFE=1
This issue does not occur on Python 3.11, but using your example I was able to reproduce it on Python 3.8 using Coveragepy 3.0.3.
Additionally, this issue still occurs in the latest stable release using Python 3.8 so I'm going to try to pick this up for the PyCon 2023 sprints.