ternary ifs not taken into account by branch coverage
See original GitHub issueOriginally reported by Antony Lee (Bitbucket: anntzer, GitHub: anntzer)
coverage 4.1, python 3.5.2, arch linux
test.py
cond = True
if cond:
x = 1
else:
x = 2
x = 1 if cond else 2
x = cond and 1 or 2
Getting branch coverage for this file shows partial coverage of the first if cond:
, but not of the ternary (inline) if cond
, or of the short-circuiting binary operators.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:18 (8 by maintainers)
Top Results From Across the Web
Devel::Cover Branch coverage on conditional ternary ...
1 Answer 1 · go with the empty list and just remove the ternary like ikegami suggested, and take into account that you...
Read more >Code coverage testing, when enough is enough - JS.dev
This doesn't even account for using ternary operators to set values, that are then used in conditional logic in the same block of...
Read more >Interviewer thinking that if-else is better than ternary ...
Maybe the opinion of interviewer is the ternary operator always leads the condtional move and doesn't generate branches. But I think it's ......
Read more >Increase your code coverage using Istanbul | by Abha Gupta
2. Conditional Statements: These are important for branch coverage. In the following example, the coverage is dropped because test case is not covering...
Read more >How to use Java's conditional operator
(condition) ? (return if true) : (return if false);. You often see the Java ternary operator symbols ( ? : ) used in...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Just fyi: it might be possible to implement this on 3.11 where we now expose column information for bytecode: https://docs.python.org/3.11/reference/datamodel.html#codeobject.co_positions
Either it will or pycoverage will be replaced by whatever new project comes along and does it. Sub-expression-level branching is simply the the correct way to measure coverage, and now it’s finally possible!