Q. Definition? A. The degree to which a test reflects production. Full logical coverage means our [[Test]] completely ensures a stable mapping from inputs to outputs. Even for an extremely simple function (int -> bool), where exactly one int returns true, complete documentation is not feasible. We need to test that the entire rest of the input space returns false. There is a spectrum of this: * [[Logical coverage]] * ==Expert-guided testing== * [[Boundary test]] * [[Pseudo-exhaustive testing]] * [[Property-based testing]] * [[Exhaustive testing]] * [[Formal verification]] * [[Snapshot test[[Logical coverage]]nt that we can reason about [[Logical coverage]]. There are a few ways of doing that: * Reasoning from the interface. What should the tests cover? * Using patterns, e.g. [[Overlapping sociable tests]]. * Checking for negatives: If a test does not cover a line, it cannot cover the line's logic To identify [[Code coverage]]: * [[Execution coverage]] * [[Mutation testing]] * [[Path analysis]] --- Q. What can nudge you to test at lower levels? A. 1) Speed, 2) Reliability, Q. Why is it important you reason from the concept, not the code, when determining what to test? A. Reasoning from the code can **never** tell you if you are missing a feature. Q. How to identify whether our [[Logical coverage]] is sufficient? A. Do your [[Overlapping sociable tests]] cover logic in each module? Q. To fully ensure behaviour of a program, you need to verify that all inputs map to correct outputs. What is typically a pragmatic approach? A. [[Boundary test]]; verify the relevant boundaries in the input space that separate between outputs. Q. You can almost never test the full input space of a program. What does this imply about program design? A. You want to design programs which are obviously correct (small input spaces). Q. How do you interpret [[Logical coverage|Code coverage]] metrics? A. Did someone attempt to tests this code; since it provides no guarantees that the logic is tested. Q. For software tests, why do I use the term [[Fidelity (test)]] rather than [[Coverage]]? A. History; coverage is about whether the tests cover your code, I want [[Fidelity (test)]] to be about whether we cover functionality.