Category Archives: CS-443

Effective Exception Testing in JUnit 5: Boundary Value Testing and AssertThrows

Introduction

In modern software development, ensuring that a program handles exceptions correctly is crucial for building robust applications. Exception testing in JUnit 5 allows developers to verify that their code properly handles error scenarios, improving reliability and maintainability. This blog post explores key techniques such as Testing for Exceptions in JUnit 5, Boundary Value Testing, and using AssertThrows to create effective test cases.

Testing for Exceptions in JUnit 5

JUnit 5 provides a streamlined way to test exceptions in Java applications. Unlike JUnit 4, which required using the expected attribute or @Rule, JUnit 5 introduces Assertions.assertThrows(), offering a more flexible and readable approach.

Example of Exception Testing in JUnit 5

Consider a method that calculates the square root of a number. If a negative number is provided, it should throw an IllegalArgumentException.

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class MathUtilsTest {

    double calculateSquareRoot(double number) {
        if (number < 0) {
            throw new IllegalArgumentException("Number must be non-negative");
        }
        return Math.sqrt(number);
    }

    @Test
    void testCalculateSquareRootException() {
        IllegalArgumentException exception = assertThrows(IllegalArgumentException.class, () -> {
            calculateSquareRoot(-5);
        });
        assertEquals("Number must be non-negative", exception.getMessage());
    }
}

This test verifies that the method correctly throws an exception when given invalid input, ensuring robustness.

Boundary Value Testing

Boundary Value Testing (BVT) is a technique used to test the limits of input values. It focuses on edge cases, such as minimum and maximum values, where software is most likely to fail.

Example: Boundary Testing for Age Validation

Consider a function that validates a user’s age for registration, allowing only ages between 18 and 65.

boolean isValidAge(int age) {
    return age >= 18 && age <= 65;
}

Boundary tests should check values just inside and just outside the valid range:

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class AgeValidatorTest {
    
    @Test
    void testAgeBoundaries() {
        assertTrue(isValidAge(18)); 
        assertTrue(isValidAge(65));  
        assertFalse(isValidAge(17)); 
        assertFalse(isValidAge(66)); 
    }
}

BVT ensures the system correctly distinguishes between valid and invalid inputs.

Testing for Exceptions with AssertThrows

The assertThrows method in JUnit 5 simplifies exception testing, making tests more readable and maintainable. It helps validate that methods correctly handle invalid inputs by throwing the expected exceptions.

Example: Division by Zero Handling

Consider a simple method that performs division:

int divide(int dividend, int divisor) {
    if (divisor == 0) {
        throw new ArithmeticException("Cannot divide by zero");
    }
    return dividend / divisor;
}

We can use assertThrows to verify proper exception handling:

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

class DivisionTest {

    @Test
    void testDivideByZero() {
        ArithmeticException exception = assertThrows(ArithmeticException.class, () -> {
            divide(10, 0);
        });
        assertEquals("Cannot divide by zero", exception.getMessage());
    }
}

This ensures that the division method correctly throws an exception when dividing by zero.

Conclusion

Testing exceptions effectively is a vital part of software quality assurance. JUnit 5’s assertThrows method, combined with Boundary Value Testing, enables developers to create thorough test cases that improve the reliability and robustness of applications. By writing well-structured exception tests, developers can prevent unexpected failures and ensure their applications behave as expected under various conditions.

For further reading, check out:

#JUnit5 #ExceptionTesting #AssertThrows #BoundaryValueTesting

From the blog Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

More JUnit

On my previous post, I stated that I was introduced to JUnit. I stated its definition, and a vast list of its annotation uses.

Now I have moved past that and started applying that knowledge. Last class, my group and I were unit testing with JUnit 5. We ran and made tests in the Rectangle class. We also ran tests using Gradle, which makes testing easier.

On that note I was looking through an article that gave me more information on JUnit testing. It is called: JUnit Testing Framework – A Comprehensive Guide | HeadSpin. It retreads on known ground but gives step by step guides on how to access and download certain things. One thing I can commend it for is the detail in certain parts of the blog. It feels like a more advanced version of the previous one like, the previous one would be used for a quick Google search while this one would be used for a step-by-step guide.

It also introduces new information such as debugging. I personally know barely anything about debugging. I have seen it but I never really understood its function. I remember in freshman year I assumed that it would aid in fixing coding mistakes so I tried it. Unfortunately, it did not do anything.

Now, how does debugging work in JUnit? There are two modes: Java Debug Wire Protocol and Standard Streams. Java Debug Wire Protocol is the one that is more likely to be recommended. It can be used broadly and provides a lot of information from test execution. In Standard Streams everything that would usually go to the main console window would be printed to the standard output stream. Unfortunately, this provides less information than Java Debug Wire Protocall so is better fit for simple tests.

I also learned some troubleshooting techniques for Java applications. I learned that one way to troubleshoot is to use log files or profiles to gather information about the application. Also when there are issues with libraries or testing frameworks, it is good to check their documentation and forums.

Overall, I feel like the article should have described more about debugging in JUnit. I feel like I got a good understanding of Standard Stream, but I do not feel like I fully grasped Java Debug Wire Protocol. The definition provided was not enough. Maybe because the article assumed the reader knows debugging and/or used it. I am not sure. Nevertheless, It was nice to learn more about JUnit. I hope to use it again in the future.

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

Introductory Blog CS-443

Hello and welcome to my blog!

My name is Elio Ngjelo and I am taking Software Quality Assur & Test, CS-443. This is where I will be posting blogs on the different topics I will be learning throughout the semester.

Thank you for reading!

From the blog CS@Worcester – Elio&#039;s Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

First CS-443 Blog

This is my first blog for CS-443. It will include posts related to software testing.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Intro to Software Quality Assurance & Testing

My name is Alex Moulton and this is my blog I use to talk about interesting happenings in computer science or interesting things I learn about.

From the blog CS@Worcester – Coder&#039;s First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Introduction to Software Quality and Assurance

Author: Petraq Mele

Hello ladies, gentlemen, or whoever has stumbled across my blog and portfolio. This is my first experience creating this sort of thing and so I am hoping to learn how to be proficient in it. My blogs this semester will be mainly about a current class I am taking on Software Quality and Assurance where I hope to learn how to professionally make sure that any software that I am programming, whether myself or with a team, is able to be produced with quality.

A little about myself:
I am currently a Junior at Worcester State University studying a bachelors in Computer Science with a minor in Astronomy. I came to the US when I was around 2 years old from a city in Albania known as Korçë.

From the blog Petraq Mele by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance Blog: Introduction

Hello internet! This will be my blog for my CS-443 Software Quality Assurance and Testing class. I’ll be writing about things that I find interesting in the world of software testing, and I look forward to writing my first entry.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Updated Introduction Blog Post (CS443)

Hello everyone! My name is Aidan Noone, and I am now a Senior at Worcester State University. I am currently pursuing a bachelor’s degree in computer science with a Homeland Security Minor, and I will be updating this blog often as I continue to progress through this final semester of mine, working on software quality assurance.

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

CS-443 Intro

From the blog CS@Worcester – Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

Software Testing Class Introduction

Photo by Quang Nguyen Vinh on Pexels.com

Hello this is Debug Ducker again, now here to document my experience and anecdotes relating to software tesitng. I am looking forward to it as I am somewhat familiar with testing from previous computer science class and this looks to go in depth in the process on an industry level.

As a reminder I am a college student and this will hopefully be my final semester. I am a comp sci major and hoping to have a career in software development. So good thing I am taking this class.

Speaking of testing for software here is a funny story relating to computing history. The first computer bug was an actual bug. In September 9, 1947 a team of computer scientist in Cambridge, Massachusetts reported finding a dead moth caught in the computer they were using causing the system to malfunction. Now we refer to software errors/mistakes as computer bugs.

Thank you for your time and have a nice day.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.