Category Archives: CS-443

Software Testing Thinking Hats

The blog post I’ve chosen talks about the different mind sets that you should use when tackling different situations. When writing tests, it helps to write tests with different goals so that you don’t forget to test every aspect of some section of code. The blog author talks about how trying to do the tests out of order or without any order in mind you can forget things and cause it to take more time in the long run. The author categorizes these as “hats” to wear during each progressive stage. There is the ambitious hat which is for when you are testing the code in the way the customer will be using the code. There is then an uncomfortable hat which is for when your tests are failing, and you need to fix what you can in your testing. The confident hat is the one you can wear while you are refactoring your code and running just to confirm everything passes. The author also makes specific mention to not try and wear multiple hats at once.
From my experience in the classes I’ve taken so far, I’ve done some built in testing in files for whole programs that I myself have written, and so I know exactly what the code should do, what I need to have pass in order to meet the homework criteria. In these cases, because I am both the author of the code and the author of the test cases, I am able to make edits in both parts with the knowledge of exactly what the test cases should be. This has helped in my current class so far but as we move forward, we will be approaching testing like it is done in the workplace and when the people testing the code are a separate group that has not touched the program code. I’ve definitely seen myself as the coder that the author describes who frantically moves around the code and tests trying whatever I can to get everything to work instead of approaching it with any methodology. I want to become both better and more efficient at testing code as it will help me write code also and further my understanding of what makes a complete program. Testing is a big part of working in the computer science field and I know that quality assurance is very important, so I look forward to both learning more about this within the course and doing more blogs about the industry.

Chris James – The TDD Thinking Hats

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

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.