COSC 102 Testing Guide

This function is part of a larger program that models a MyCar class, an object-oriented simulation of a car's essential behaviors such as fuel consumption, mileage tracking, and gas refilling. The class includes attributes like fuel efficiency (mpg), gas tank size, total mileage, and gas price, and supports methods that simulate realistic interactions with a car, such as driving, refueling, and maintenance tracking.

The driveCar(double miles) method plays a central role in modeling how fuel is consumed when a car is driven. It checks whether the requested number of miles can be driven based on the car's current gas level and miles-per-gallon efficiency. If the request is valid, it updates the fuel level accordingly and returns true; otherwise, it denies the request and returns false. This simple check ensures that the simulation remains realistic, drivers can't magically exceed their car's fuel limits.

Testing this method is essential because it represents a core mechanic of the simulation: the link between fuel and distance traveled. If the function allows negative or overly long trips to be recorded, the simulation becomes unrealistic. By applying both Boundary Value Testing and Equivalence Class Testing, we can ensure that the driveCar() method behaves as expected across all relevant input ranges and scenarios, preserving both the integrity and believability of the simulation.

public boolean driveCar(double miles){
    if (miles < 0 || miles > this.mpg*this.currentGas){
        return false;
    }
    this.currentGas = this.currentGas - (miles/this.mpg);
    return true;
}
                        

We want to test the boundaries of the variable miles in this function. To do this, we apply the principles of Boundary Value Testing (BVT), which focuses on values at the very edges of a variable's allowed range—specifically where the program's behavior transitions from one state to another. Rather than merely identifying out-of-bounds errors, BVT is used to verify that logical conditions flip precisely when they're supposed to. These transition points might reflect shifts such as false to true, valid to invalid, or rejected to accepted.

In order to isolate the behavior of the miles parameter, we'll fix the other variables in the function to known values. Specifically, we set mpg = 20 and currentGas = 5, which means the maximum drivable distance is 20 * 5 = 100 miles.

Now we can systematically test values at and around the key thresholds. Because miles is a double, we can test with precise decimal values, not just whole numbers. This allows us to observe how small variations near those critical boundaries affect program behavior.

Test Cases Created in Step 1

Equivalence Class Testing (ECT) involves dividing input values into categories, or "classes," where all values in a class are expected to produce the same outcome. Rather than testing individual edge values like in BVT, ECT helps ensure the function behaves correctly across broader types of inputs. In the case of driveCar(double miles), we again assume mpg = 20 and currentGas = 5, which means the car can drive a maximum of 100 miles.

We can identify the following equivalence classes for the miles input:

• EC1: Negative input values. Any value less than 0 should be considered invalid and return false.
• EC2: Valid range values. Any value greater than or equal to 0 but less than or equal to 100 should return true.
• EC3: Values exceeding the fuel range. Any value greater than 100 should be considered too far to drive and return false.

To ensure representative coverage across the equivalence classes and validate transitions between them, we design the following four test cases:

Test Cases Created in Step 2

These test cases verify that the function correctly interprets inputs from within each behavioral region and handles the transitions across class boundaries appropriately.

ECT is most effective when used after BVT has exposed where those behavioral boundaries lie. While BVT stresses the inputs right at the turning points—such as 0.0, 100.0, or just beyond, ECT steps back and ensures each logical region on either side of those boundaries is being properly represented and covered.

In this way, building one strategy actually helps inform the construction of the other: BVT pinpoints exactly where logic transitions occur, and ECT maps out the broader regions those transitions define. This allows you to test thoroughly without redundancy, using BVT to confirm precision and ECT to ensure consistent coverage across meaningful input classes.

Using JaCoCo to analyze our code coverage, we can verify that our test cases from the previous steps provide complete coverage of the driveCar method.

The JaCoCo report confirms that our BVT and ECT test cases fully exercise all lines and branches in the method:

As shown in the report, this function is very simple and JaCoCo confirms that it is fully covered by our BVT and ECT test cases. The coverage analysis shows that we've exercised both the true and false conditions of the if statement, ensuring that all execution paths have been tested.

For this simple example, no significant refinement is needed. The driveCar method has straightforward logic with clear boundaries and equivalence classes that we've already covered in our BVT and ECT test cases.

Here is our complete test suite for the driveCar method, organized by test type:

JaCoCo confirms we've achieved 100% code coverage, and our tests are minimal with minimal redundancy. Each test case serves a specific purpose, and together they provide complete coverage of the method's behavior.

This function comes from the Fantasy Garden project in COSC 102, where students simulate plant growth based on environmental conditions. The simDailyGrowth(int temp, int weather) method models a plant's daily growth depending on both current weather and temperature inputs, but also internal state such as whether the plant is wilted and how many consecutive chilly days have occurred. The function includes several conditional branches and makes use of constants defined in the FantasyGarden class:

// Temperature types
public static final int TEMP_CHILLY = 0;
public static final int TEMP_WARM = 1;
public static final int TEMP_HOT = 2;
// Weather types
public static final int WEATHER_SUNNY = 0;
public static final int WEATHER_CLOUDY = 1;
public static final int WEATHER_RAINY = 2;
                    

The growth logic is influenced by whether the plant is already wilted (isWilted()), if the day is chilly, and whether the weather is cloudy or not. If specific chilly and cloudy conditions repeat, the plant may wilt. If the day is suitable, it grows by incrementing previousGrowth. If not, it might reset the growth counter or even return zero. This function illustrates both the challenge of managing internal object state and the complexity introduced when conditions depend on multiple variables interacting.

public int simDailyGrowth(int temp, int weather){
    if (isWilted()){ //if wilted
        return 0;
    }
    if (chillyCounter == 1 && temp == FantasyGarden.TEMP_CHILLY){
        wilt(); //wilted condition
        return WILTED_VALUE;
    } else if (weather != FantasyGarden.WEATHER_CLOUDY){
        chillyCounter = 0;
        previousGrowth += 1;
        return (grow(previousGrowth));
    } else if (chillyCounter != 1 && weather == FantasyGarden.WEATHER_CLOUDY && temp == FantasyGarden.TEMP_CHILLY){
        previousGrowth = 1;
        chillyCounter = 1;
        return (grow(previousGrowth));
    } else if (weather == FantasyGarden.WEATHER_CLOUDY && temp != FantasyGarden.TEMP_CHILLY){
        previousGrowth = 1;
        chillyCounter = 0;
        return grow(previousGrowth);
    }
    return 0;
}
                        

In this function, boundary value testing isn't about numeric min/max thresholds. Instead, we're testing the logic around conditional transitions, the exact points where the function's behavior flips due to changes in temperature, weather, or internal state. These boundaries may not look like traditional math, but they represent the edges of behavioral change. For example, the plant's transition from healthy to wilted is not determined by a simple number, it's the combination of a specific internal state (chillyCounter == 1) and a triggering input (temp == TEMP_CHILLY).

BVT is used here to deliberately probe those transitions: when a plant starts to grow, when it resets its growth cycle, or when it shuts down altogether. We don't need to try every possible input; instead, we construct targeted test cases that sit precisely at those flip points. These are the decision thresholds where the program's return value will change based on just one piece of input. For clarity, we'll use the numerical values (0, 1, 2) rather than the constant names in our test cases.

For example:

• BVT2 tests the moment when the plant switches from being on the edge of wilting to actually wilting. This is only triggered under very specific conditions (counter = 1 and temp = 0, which is the TEMP_CHILLY constant in the code).
• BVT4 confirms that non-chilly temperatures on cloudy days do not cause wilting, helping isolate the logic that distinguishes these similar but subtly different paths.
• Each test case uses a fresh Plant instance to avoid state contamination between tests, which was critical for tests BVT3 and BVT5.

Test Cases Created in Step 1

This focused approach lets us quickly confirm that all logical gates in the function work properly without needing a bloated test suite. It emphasizes precision over repetition.

Here we categorize input scenarios that result in consistent behavior and group them into equivalence classes. These categories help simplify the testing process by covering more ground with fewer cases. Instead of trying every single permutation of temp, weather, and internal state, we select one representative input for each class that exhibits a unique behavior pattern. This function presents a classic case where internal state influences outcomes just as much as input parameters. For example, a test where temp = TEMP_CHILLY and weather = WEATHER_CLOUDY might result in different outcomes depending on whether chillyCounter is 0 or 1. That's why our equivalence classes take both current inputs and the plant's internal memory into account.

Each test here is chosen to represent a class of behavior, not just a unique line of code:

• EC1 is a hard stop: once a plant is wilted, nothing else matters, it always returns 0.
• EC3 and EC4 both deal with cloudy days, but the difference in temperature causes very different logic to execute. These are tested separately because they reflect two distinct branches of the function.
• EC5 captures all non-cloudy weather outcomes where growth should continue, offering a broader behavioral region that's consistent in logic.

Equivalence Classes for simDailyGrowth

Test Cases Created in Step 2

By clearly separating these equivalence classes and testing only once per class, we avoid redundancy while still ensuring total behavioral coverage. It's a high-efficiency way to confirm that each type of scenario behaves as expected without overwhelming the test suite with duplicates.

After running our BVT and ECT tests through JaCoCo, we found that there was still one line of code that wasn't being executed at all (shown in red in the JaCoCo report):

• The final return 0 statement at the bottom was never executed (red line)
• This represents an important edge case in our ECT that we missed in our original analysis
• While there was also yellow highlighting for some conditions, we're primarily focused on achieving line and branch coverage at this stage, not condition coverage

To achieve complete line and branch coverage, we added a specific test to target the red line (the uncovered fall-through path):

The JaCoCo report now confirms that with our complete test suite, we've eliminated all red lines, achieving full line and branch coverage for the simDailyGrowth method. This test case was essential because it represents a missed equivalence class in our earlier analysis - a case where the plant has a chillyCounter of 1 on a cloudy, chilly day but doesn't wilt:

As shown in the report, all lines of code are now exercised, with no red lines remaining. Upon rerunning JaCoCo with our updated test suite, the previously missed return line (line 671) turned green. While some conditions may still show yellow highlighting (indicating that not all possible boolean combinations were tested), we've achieved our primary goal of ensuring every line of code and every branch is exercised at least once. This highlights why JaCoCo is such a valuable final check - it revealed a meaningful edge case that our ECT analysis had overlooked.

After examining our complete test suite, we can make the following refinements:

1. Eliminate redundancy: EC1-A duplicates BVT Case 1, so we can remove one of them
2. Combine similar cases: EC2-A and BVT Case 3 test the same condition, so we can merge them
3. Prioritize the most revealing tests: The wilting transition tests are particularly important

Here is our complete comprehensive test suite for the simDailyGrowth function, organized by test type and showing the priority of each test:

This refined suite balances thorough coverage with efficiency, focusing on the most important behavioral aspects while still ensuring all code paths are tested at least once. By eliminating redundant tests and prioritizing the most critical scenarios, we've created a test suite that efficiently validates the simDailyGrowth function's behavior across all its logical boundaries.

This function supports a Wordle-style game mechanic. It compares the guessed letter at index j in the current row with the secret word's character at the same index. If the characters match exactly, the tile is colored green and the rightSpot counter is incremented. If the guessed character exists elsewhere in the secret word (but not at the current index), the tile is colored yellow unless it's already marked green. If the guessed character is not in the secret word at all, the tile is colored gray.

public static int checkLetters(int j, int rightSpot){ //compares the guessed word to the secret word
    char wordLetter = GameGUI.getSecretWordArr()[j]; //gets letter from answer word
    char guessLetter = GameGUI.getGridChar(currentRow, j); //gets letter in the spot
          if (wordLetter == guessLetter){ //colors in boxes if leters are equal
                GameGUI.setGridColor(currentRow, j, CORRECT_COLOR); //sets color to green
                GameGUI.setKeyColor(wordLetter, CORRECT_COLOR);
                rightSpot += 1; // is this guess correct for the secret at this spot, if it is then we color and are done, if it is not then we need to differentiate between yellow and dark gray
             }else{
                for (int i = 0; i< MAX_COLS; i++){
                   if (guessLetter == GameGUI.getSecretWordArr()[i]){
                      GameGUI.setGridColor(currentRow, j, WRONG_PLACE_COLOR);
                      if (GameGUI.getKeyColor(guessLetter) != CORRECT_COLOR){
                         GameGUI.setKeyColor(guessLetter, WRONG_PLACE_COLOR);
                      }
                   } else if (GameGUI.getKeyColor(guessLetter) != WRONG_PLACE_COLOR && GameGUI.getKeyColor(guessLetter) != CORRECT_COLOR){
                      GameGUI.setKeyColor(guessLetter, WRONG_COLOR);
                   }

                   }
                }
             return rightSpot;
          }
                        

This problem has two dimensions that influence the function's behavior: the index j and the guessed word itself. To thoroughly apply Boundary Value Testing, we isolate each of these variables and test how the logic transitions as we move across their respective boundaries. First, we hold the index constant and vary the guessed letter to reveal how matches, near-matches, and mismatches affect the outcome. Next, we hold the guessed word constant and vary the index to examine how the same characters behave across different positions in the word.

This two-dimensional BVT approach demonstrates how we can apply boundary testing not only across numeric thresholds, but across distinct control flow transitions, validating correctness from multiple interacting angles.

Equivalence Classes for checkLetters

These values represent boundaries between green → yellow → gray transitions, based on exact character alignment and word inclusion. We keep the index constant (j = 0) and vary only the guessed letter to examine how the output behavior changes across key logical transitions: an exact match, a letter in the word but in the wrong position, and a letter not in the word at all.

This isolation allows us to precisely identify the boundaries that shift the program from one behavior (green coloring and incrementing rightSpot) to another (yellow or gray coloring with no increment). Boundary Value Testing is not limited to numeric comparisons; it can be extended to categorical logic, such as character string comparisons and boolean condition transitions, wherever a meaningful behavioral boundary exists.

Test Cases Created in Step 1 - Dimension 1: Character Variation

For these tests, we hold the index constant (j = 0) and vary only the guessed letter to examine how the output behavior changes across the key logical transitions.

Test Cases Created in Step 1 - Dimension 2: Position Variation

We then shift focus to the second dimension, position. By keeping the guess word constant and varying the index j, we test how the function applies the same comparison logic across multiple positions in the word. Using a partially overlapping word like "CRASS" against the secret word "CRANE" allows us to track how the same letter behaves differently depending on its position.

To make this truly reflect Boundary Value Testing, we observe how the same guessed letter produces different behavior at different positions. For example, the character 'C' appears in both guess words, "CRASS" and "SCARS", but at different indices. In "CRASS", it aligns with the same position in the secret word (index 0), triggering a correct match (green). In "SCARS", the same 'C' appears at index 1, which does not match the corresponding character in the secret word, resulting in gray. This demonstrates that the function's output is not solely determined by the presence of the letter but also by its position.

While BVT focuses on finding the precise transition points in logic, ECT helps validate the consistency of behavior within those broader regions. It is most effective when used after BVT has mapped out where those boundaries occur. For example, once BVT shows that the function transitions from green to yellow when the guessed letter changes or moves, ECT ensures that any value that falls into the "green" or "yellow" category behaves as expected, regardless of the specific input.

In the case of checkLetters, BVT helps identify that the output changes based on character match and position. ECT then groups those outcomes into logical classes—exact match, partial match, and no match—and checks whether the function treats all members of each class consistently. This layered approach reduces redundancy while improving coverage: BVT highlights the edges, and ECT confirms the rules within each region.

1. EC1: Exact Character Match - The guessed letter matches the secret letter at the same position
2. EC2: Character in Word but Wrong Position - The guessed letter exists in the secret word but not at the current position
3. EC3: Character Not in Word - The guessed letter does not appear anywhere in the secret word

Now we'll create test cases that represent each equivalence class, ensuring that all types of character matches are properly handled by the function.

Test Cases Created in Step 2

By using ECT to sweep across each class, we confirm that the function applies the same logic to any input that falls within a class—ensuring reliability and coherence in its behavior. This approach provides broad coverage while keeping our test suite manageable.

After running our BVT and ECT tests through JaCoCo, we analyzed the coverage report to determine if additional test cases were needed:

The JaCoCo report shows that all lines in the checkLetters method are green, with only two conditional statements showing yellow highlighting. Since the lines are yellow rather than red, we know that both paths of these conditionals are being tested, just not all possible combinations of conditions.

For this method, we're not concerned with achieving the full level of rigor in testing all conditional combinations, as it would significantly increase the number of test cases without proportional benefit. The yellow highlighting represents minor variations in how certain edge cases are handled, particularly related to keyboard color assignments that have already been set.

The coverage report confirms that our BVT and ECT approach was sufficient in testing the checkLetters method, as all execution paths are being exercised at least once. This validates our testing strategy and demonstrates that focusing on meaningful boundaries and equivalence classes is an efficient approach to achieve comprehensive testing without creating an excessive number of test cases.

After examining our complete test suite, we identified opportunities to optimize our testing approach while maintaining comprehensive coverage:

1. We want to retain tests that verify each of the three main color outcomes (green, yellow, gray)
2. We need to keep both the single-character tests (BVT) and the multi-character tests (ECT)
3. We want to ensure tests across different positions to verify index-based behavior

Here is our refined comprehensive test suite for the checkLetters function, organized by test type:

We've dropped BVT4 as it provided similar coverage to BVT1, testing an exact match but at a different position. Since we've retained BVT6 which tests an exact match at position 2, we have sufficient position variation coverage without BVT4.

This refined suite balances thorough coverage with efficiency, focusing on the most important behavioral aspects while still ensuring all code paths are tested at least once. By organizing our tests in this way, we can quickly see which aspects of the function are most thoroughly tested and which critical behaviors are verified. The high-priority tests capture the essential transition points between the three color states (green, yellow, gray), while the medium-priority tests ensure complete coverage of edge cases.

The checkLetters function demonstrates how our test approach is able to handle more complex code with conditional logic, loops, and state changes. The simple yet robust principles of Boundary Value Testing (BVT) and Equivalence Class Testing (ECT) scale well to this complexity by focusing on the key transitions in behavior rather than exhaustively testing every possible input combination. This approach yields comprehensive test coverage with a manageable number of thoughtfully designed test cases.