Category Archives: CS-443

Week 6: Boundary Value vs Equivalence Class Testing

This week we learned about boundary value testing and equivalence class testing. Boundary value testing focuses on making sure the values in, out, and around the expected boundary works as it should. Equivalence class testing does the same, but also tests the function itself.

I wanted to know more about the two methods and found a blog post that explains them a little more in depth. The author, Apoorva Ram, says they are more thought processes than testing methods really. The thought process of boundary value testing is self explanatory: testing the edge boundaries of the function. The thought process of equivalence class testing is organizing every possible input into groups of expected outputs and testing the result from each.

Ram also explains the benefits of the methods and how they can be used in software testing. The two seem to go hand in hand. Planning your tests before writing them and knowing the expected output makes the testing process a lot smoother. You know what points you need to hit and have a plan to execute them. Additionally, knowing all the points you need to hit allows you to prioritize ones that are more important.

For example, say you have a boolean function that looks for the input value to be between 15 and 30, but accepts values from 0 to 100. Boundary testing would test the values of x_min-, x_min, x_min+, x_nom, x_max-, x_max, and x_max+. In this case: -1, 0, 1, 50, 99, 100, and 101. It mostly makes sure the 0 and 100 boundaries work. But equivalence class testing breaks down the function into classes of values that will give every result: invalid inputs (under 0 and above 100), false cases (between 0-14 and between 31-100), and the true case (between 15-30). In this case: -1, 12, 20, 45, and 101. This method tests the valid ranges as well as the function ranges.

In my opinion, equivalence class testing is better than boundary value testing because it actually tests the function and not just the illegal argument exception, and it eliminates redundant tests like x_min+, x_nom, and x_max-, all testing for the same output without actually testing the function. Though ideally, a mix of both would probably be the method I choose. For this example, I would test each equivalence class and its boundaries: x_min-, x_min, x_min+, x_truemin-, x_truemin, x_truemin+, x_truemax-, x_truemax, x_truemax+,x_max-, x_max, and x_max+ (-1, 0, 1, 14, 15, 16, 29, 30, 31, 99, 100, 101).

Blog post referenced: https://testsigma.com/blog/boundary-value-analysis-and-equivalence-class-partitioning/

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

JUnit 5 Testing

2/27/2025

This week we learned about Junit test cases. Coming from a C++ background it was a bit difficult to order my tests and to use one global object that runs before all other tests. In C++ the tests run in the order that you write them, and I learned that in java that is not a thing unless you specifically use order(N) N being the order number. This way of testing makes you able to order your test cases in whatever way you want. Also, I learned that you can just make a setup function with a single object and by using “Before All” this means the set up will run before any other test which helps with repetitive tasks of making objects over and over. I personally would rather create a fresh object for each test, but it was a nice experience learning that java just randomly tests and does not have an actual order unless stated otherwise.

Looking through the Junit 5 user guide when doing the homework I also learned that you can use “Before Each” for tests that you want to run before each test sort of like a for loop. One very interesting thing I have never encountered is that you can use lambda in order to compare variables using in objects. This makes it nice and compact for simpler tests because this can all be done within one line.

In class I also learned that gradle will give a different output for the test’s cases compared to vscode. I also encountered that when I would hit the checkmark in vscode for individual test cases they would pass and then other occurrences where they would not pass. Also, the same with running them globally all together. This confused me and took me a few hours to figure out why, but I realized it was due to my global object that I created. I also noticed that gradle would give me a different result as well, but it was much better and consistent than running the tests individually.

Source: JUnit 5 User Guide
Source: Writing Templates for Test Cases Using JUnit 5 – GeeksforGeeks

From the blog CS@Worcester – Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.

JUnit, Test, and Repeat

I’ve decided that I wanted to practice making more JUnit tests. I did well on my last homework assignment, but I feel like I still need more practice. It took me some time to do it. I may have to generate my own JUnit tests in the midterm so I would need to make them at a faster rate. Anyway, practice makes perfect so there is no such thing as too much practice.

For this post I will be using this website: Inheritance in Java – GeeksforGeeks

This website contains two examples of code but I will use the first one. The code does not allow for user input but I’ll be drafting tests as if it does.

Before I write any test I would write:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

import static org.junit.jupiter.api.Assertions.assertThrows;

They will be useful later.

The first test I would make is a constructor test. I believe it should be one of the first tests. It is good to know the test works as it is supposed to since if it cannot do that it will need to be immediately revised. So, I would do this:

@Test

public void testMountainBikeConstructor() {

MountainBike mb = new MountainBike(30, 10, 45);

assertEquals(30, mb.gear);

assertEquals(10, mb.speed);

assertEquals(45, mb.seatHeight);

}

This is supposed to be take in three values and tests if the constructor initializes them correctly. I used the name “mb” because it was already in a class that was used to test inputs. It just made sense to me.

Another test I created tests the set string height method.

@Test

public void testSetHeight() {

mountainBike.setHeight(40);

assertEquals(40, mountainBike.seatHeight);

}

This tests if the height of the mountain bike can handle user input.

@Test

public void testMountainBikeMethods() {

mountainBike.applyBrake(5);

assertEquals(10, mountainBike.speed);

mountainBike.speedUp(10);

assertEquals(20, mountainBike.speed);

}

This tests if the mountain bike can speed up and brake.

@Test
void testToString() {
String expected = “No of gears are 6\nspeed of bicycle is 25\nseat height is 10”;
assertEquals(expected, mountainBike.toString());
}
}

This is supposed to test that the code has the expected output.

For the final test, I wanted to up the ante. What if I could test the limits of the code?

@Test

public void testSpeedLimits() {

MountainBike mb = new MountainBike(3, 100, 25);

mb.setSpeed(0);

assertEquals(0, mb.getSpeed(), “No negative speed!”);

assertThrows(IllegalArgumentException.class, () -> mb.setSpeed(-10), “No negative speed!”);

}

Overall, this was an interesting challenge. The main difficulty was finding the code to do this project on. There was code that was too easy thus difficult to generate meaningful tests on. There was also code that was too complicated which made it difficult to make a significant number of tests. In the end, it was nice to get some practice.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

On CI/CD Pipelining

In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.