🔎 findMin() — Interactive: Prime-Path Coverage & Bug Reveal

Week 3 Practice · Q8 (test cases → prime paths) · Q9 (which test reveals the bug)

CFG of findMin() — watch the input trace its path

min starts at 0. Each element: if min > a[i] → node 4 (update), else → node 5. Then i++, back to 2.

1 · Run an input array

min=0i=0
Pick an array and press Play.

2 · Prime-path coverage of your set  0 / 12

3 · Test the 4 options

Click an option to load its whole set of input arrays and see coverage. ✅ Answer = c).

The code under test 


        
The bug: min starts at 0 — a value that may not be in the array. If every element is > 0, the if never fires, min stays 0, and 0 is returned as the "minimum".

      

      

        
Run a JUnit test

        

        

          
select a test

          
min=0

          

            
expected –

            
actual –

            

          

        

        

      

    

    
✅ Answer: c) testCase3() {6} — the only all-positive input. It triggers the fault (min stays 0), and the assertion assertEquals(6, 0) fails → bug revealed. Toggle 🐞 buggy → ✅ fixed above and re-run: testCase3 turns green.

  


  
  

    

      
✍️ Q8 — "which test cases cover all prime paths?" (pen & paper)

      
    
        
  • Don't re-derive 12 prime paths. Instead check the SET has 4 signature inputs:
    • 
        
  • ① an empty array [] → loop runs 0 times → covers 1→2→6. No empty array ⇒ option is WRONG. (kills b)
    • 
        
  • ② an input whose first element updates min (first element < 0, since min starts at 0) → covers 1→2→3→4→5. No such case ⇒ WRONG. (kills a — its arrays all start with 0)
    • 
        
  • ③ an input whose first element does NOT update (first element ≥ 0) → covers 1→2→3→5.
    • 
        
  • ④ multi-element arrays that loop both the update (3→4) and no-update (3→5) branches → covers the loop prime paths.
    • 
        
  • Trace shortcut per array: write 1 2, then for each element: node 3, then if min > a[i] add 4 & set min=a[i], else skip; then 5 2. End with 6.
    • 
        
  • Golden rule: min starts at 0 → an element updates min only when it is below the current min (initially, when it's negative).
    • 
        
  • Winner = the option with empty [] + one negative-first + one positive-first + a mixed array. That's c).
    • 
      

    

    

      
✍️ Q9 — "which test reveals the bug?" (pen & paper) — the RIP trick

      
    
        
  • Step 1 – Find the fault. Here: int min = 0; (should be iarr[0]).
    • 
        
  • Step 2 – Ask "what input makes 0 the wrong answer?" → an array where every element > 0 (so 0 is smaller than all, but 0 isn't in the array).
    • 
        
  • Step 3 – A test reveals a bug only if RIP all hold:
          
      
            
    • Reachability — the faulty line runs (always here),
      • 
            
    • Infection — internal state goes wrong (min stays 0 instead of the true min),
      • 
            
    • Propagation — the wrong value reaches the assertion & makes it FAIL.
      • 
          
    
        
    • 
        
  • Elimination: any array containing a value ≤ 0 accidentally updates min to the real minimum → bug hidden (passes). An empty array returns 0 and the test expects 0 → passes. So scan for the all-positive array.
    • 
        
  • Here only {6} is all-positive → returns 0 ≠ 6 → testCase3() reveals it.
    • 
        
  • Remember: a passing test never proves correctness. You need a test whose correct output the buggy code cannot produce.
    • 
      

    

    

      
🧠 The reusable pattern

      
    
        
  • This "min = 0" / "max = 0" / "sum-init" bug is a classic: an accumulator initialized to a constant instead of the first element. The revealing test is always the one where that constant is out of the data's range.
    • 
        
  • For coverage questions: inputs → execution paths → check the requirement set. Never eyeball inputs; always trace the path.
    •