Software Testing

POTD 9: Program mutation (Good-Fast-Cheap)

Due 9-April-2026, 11am EST

Purpose: Understand and apply mutation testing concept to program source code; get ready to work on homework assignment, and prepare for quiz 5 and the final exam.

You may make a copy of a worksheet and complete this activity or type your answers in any text editor.

You may work alone or with another student in this course.

Consider (again) an implementation of the old engineering joke: Good, Fast, Cheap.

public final class GoodFastCheap 
{
   // boolean variables good, fast, and cheap 
   // and other stuff omitted
    
   public boolean isSatisfactory() 
   {
      if ((good && fast) || (good && cheap) || (fast && cheap)) 
         return true;
      return false;
   }

   public boolean isSatisfactoryRefactored() 
   {
      if (good && fast)     return true;
      if (good && cheap)    return true;
      if (fast && cheap)    return true;
      return false;
   }
}

Consider two mutation operators, one that replaces boolean variables with the constant "true" and one that replaces boolean variables with the constant "false". (Reminder: we are considering first-order mutation testing; i.e., only one change per mutant)

How many mutants do these operator generates for
- isSatisfactory()?
- isSatisfactoryRefactored()?
Are any of these mutants "equivalent"? What is it about these mutation operators that makes this analysis easy?
Some of these mutants are bound to be redundant. How many? Why?
Consider a pair of corresponding mutants, one in each method. Will these mutants be killed by exactly the same tests? Is this a good thing?
For each mutant, find all the tests that kill that mutant
Consider the RACC-adequate tests you designed for the original isSatisfactory() and the refactored version of the isSatisfactory() methods (from Activity: Logic coverage for source code (gfc)). Compute the mutation score for each RACC-adequate test set.
```
From Activity: Logic coverage for source code (gfc)

You may use the RACC-tests you picked or use the following tests. 

The original isSatisfactory()
RACC-adequate test = { 2, 3, 4, 6 }           // let's call it RACC-test1  

The refactored version of the isSatisfactory()
RACC-adequate test = { 2, 3, 4, 5, 6, 7 }     // let's call it RACC-test2 
```
Compute the mutation score for RACC-test1 on isSatisfactory()

Compute the mutation score for RACC-test2 on isSatisfactoryRefactored()

You might find the following table useful. You should add more columns as needed.

  p = ((g && f) || (g && c) || (f && c))

Row

Original

  p1 = (g && f) 
  p2 = (g && c) 
  p3 = (f && c)

Row

Original

Grading rubric

[Total: 10 points]: Done (or provide evidence of your attempt, full or reasonable effort)

(5 points) — Providing evidence of your attempt, minimal effort

(-2.5 points) for 24 hours late (submitted after 9-April-2026 11am EST, by 10-April-2026 11am EST)
(-5 points) for 48 hours late (submitted after 10-April-2026 11am EST, by 11-April-2026 11am EST)

Submission

Take a selfie (or picture) of your team — get creative and have fun! — and submit it with your POTD.
You may do one of the following:
- take picture(s) of your POTD — if you write your answer(s) on papers, or
- save your POTD as a .pdf file — No Word document.
Upload your POTD to POTD 9 on Gradescope.
Make sure you connect your partner to your group on Gradescope so that everyone receives credit
Each team submits only one copy

Making your submission available to instructor and course staff is your responsibility; if we cannot access or open your file, you will not get credit. Be sure to test access to your file before the due date.