Editing Code coverage (section)

=== Other coverage criteria ===
There are further coverage criteria, which are used less often:
* '''[[Linear Code Sequence and Jump]] (LCSAJ) coverage''' a.k.a. '''JJ-Path coverage'''{{snd}} has every LCSAJ/JJ-path been executed?<ref name="On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC">M. R. Woodward, M. A. Hennell, "On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC", Information and Software Technology 48 (2006) pp. 433-440</ref>
* '''Path coverage'''{{snd}}Has every possible route through a given part of the code been executed?
* '''Entry/exit coverage'''{{snd}}Has every possible call and return of the function been executed?
* '''Loop coverage'''{{snd}}Has every possible loop been executed zero times, once, and more than once?
* '''State coverage'''{{snd}}Has each state in a [[finite-state machine]] been reached and explored?
* '''Data-flow coverage'''{{snd}}Has each variable definition and its usage been reached and explored?<ref name="A Survey on Data-Flow Testing">Ting Su, Ke Wu, Weikai Miao, Geguang Pu, Jifeng He, Yuting Chen, and Zhendong Su. "A Survey on Data-Flow Testing". ACM Comput. Surv. 50, 1, Article 5 (March 2017), 35 pages.</ref>

[[Safety-critical]] or [[Dependability|dependable]] applications are often required to demonstrate 100% of some form of test coverage.
For example, the [[European Cooperation for Space Standardization|ECSS]]-E-ST-40C standard demands 100% statement and decision coverage for two out of four different criticality levels; for the other ones, target coverage values are up to negotiation between supplier and customer.<ref name="ECSS-E-ST-40C">ECSS-E-ST-40C: Space engineering - Software. ECSS Secretariat, ESA-ESTEC. March, 2009</ref>
However, setting specific target values - and, in particular, 100% - has been criticized by practitioners for various reasons (cf.<ref name="is 100 percent reasonable">C. Prause, J. Werner, K. Hornig, S. Bosecker, M. Kuhrmann (2017): ''[https://www.researchgate.net/profile/Marco_Kuhrmann/publication/319141355_Is_100_Test_Coverage_a_Reasonable_Requirement_Lessons_Learned_from_a_Space_Software_Project/links/599467faaca272ec9087f82a/Is-100-Test-Coverage-a-Reasonable-Requirement-Lessons-Learned-from-a-Space-Software-Project.pdf Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project]''. In: PROFES 2017. Springer. Last accessed: 2017-11-17</ref>)
[[Martin Fowler (software engineer)|Martin Fowler]] writes: "I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing".<ref name="fowler blog">Martin Fowler's blog: [https://martinfowler.com/bliki/TestCoverage.html TestCoverage.] Last accessed: 2017-11-17</ref>

Some of the coverage criteria above are connected. For instance, path coverage implies decision, statement and entry/exit coverage. Decision coverage implies statement coverage, because every statement is part of a branch.

Full path coverage, of the type described above, is usually impractical or impossible. Any module with a succession of <math>n</math> decisions in it can have up to <math>2^n</math> paths within it; loop constructs can result in an infinite number of paths.  Many paths may also be infeasible, in that there is no input to the program under test that can cause that particular path to be executed.  However, a general-purpose algorithm for identifying infeasible paths has been proven to be impossible (such an algorithm could be used to solve the [[halting problem]]).<ref>Dorf, Richard C.: ''Computers, Software Engineering, and Digital Devices'', Chapter 12, pg. 15. CRC Press, 2006. {{ISBN|0-8493-7340-9}}, {{ISBN|978-0-8493-7340-4}}; via [https://books.google.com/books?id=jykvlTCoksMC&dq=%22infeasible+path%22+%22halting+problem%22&pg=PT386 Google Book Search]</ref> [[Basis path testing]] is for instance a method of achieving complete branch coverage without achieving complete path coverage.<ref name="SrikantShankar2002">{{cite book|author1=Y.N. Srikant|author2=Priti Shankar|title=The Compiler Design Handbook: Optimizations and Machine Code Generation|year=2002|publisher=CRC Press|isbn=978-1-4200-4057-9|page=249}}</ref>

Methods for practical path coverage testing instead attempt to identify classes of code paths that differ only in the number of loop executions, and to achieve "basis path" coverage the tester must cover all the path classes.{{citation needed|date=July 2014}}{{clarify|date=July 2014}}