Blog Post: Making Code Stronger with JUnit 5

This week, I found a blog post called “Increasing Code Fortification: A Guide to Security Testing in JUnit 5”, and it gave me a new way of thinking about security in my code. I already knew JUnit 5 was useful for unit testing, but I hadn’t really thought about using it to test for security issues too.

The post talks about how developers can use regular unit tests to check for vulnerabilities early on, instead of waiting until the very end of development. It explains different strategies, like testing bad input, enforcing boundary checks, and even trying to break your own code to make it stronger. The idea of using parameterized tests to throw lots of different attacks at your code really stood out to me. I liked how the blog makes it so straight-forward.

Reading this made me realize I thought of testing as a question of”does it work?” — not “is it secure?” I like the idea of making security testing part of the normal coding routine, instead of something extra you only do if you have time. It’s a good reminder that security isn’t just about firewalls and encryption; it’s about the small choices you make in everyday code. The blog really emphasized that testing for edge cases and unexpected behavior can be just as important as making sure the “happy path” works.

One thing I found especially interesting was how JUnit 5 makes it easy to run the same test with multiple different inputs using parameterized tests. I had used this feature a little bit before for checking different types of valid inputs, but I hadn’t thought about using it to simulate attacks or unexpected bad inputs. For example, passing in SQL injection strings or unexpected data types could help catch vulnerabilities early before they become serious security problems.

I also liked how the blog encouraged starting small, not talking about designing a full-blown security test suite right away. Even adding a few security-focused tests for each feature you write can slowly build a stronger, more resilient application over time. It made me think about how easy it is to treat the idea of “security” as something separate from “normal” code and how easy it is to break it down into a couple tests per feature makes it much more manageable that coding the project and then trying to apply security testing.

In my future projects, especially ones involving databases, user input, or authentication, I want to make sure I’m thinking about security from the start. Testing with bad input and thinking like an attacker isn’t just for cybersecurity experts — it’s something every developer should get comfortable doing. Using JUnit 5 for this feels like a natural extension of skills I’m already using.

Overall, this blog post made security feel a lot more approachable. It gave me some simple ideas I can apply right away, and it motivated me to be a little more critical and thoughtful about the code I write, not just whether it works, but whether it’s strong enough to handle real-world problems.

From the blog Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

In our Software Quality Assurance and Testing course, we have been learning about Test-Driven Development (TDD) and how it supports building stable, maintainable software. Chris James’ blog post, “The TDD Thinking Hats,” connects directly to our coursework by offering a helpful way to think about the different stages of test-driven development. Instead of just following steps, James introduces the idea of “thinking hats” to better focus on what kind of mindset is needed at each point in the process. James also acknowledges the concept he is applying to test-driven development in this post stems from the “Six Thinking Hats” which is a broader idea that is from an Dr. Edward de Bono book.

James outlines three main hats:

• The Green Hat is worn when writing a new test, emphasizing thinking like a user and focusing on desired behavior.
• The Red Hat is worn when tests are failing, where the priority is to quickly fix the issue without making too many changes outside of the direct problem.
• The Blue Hat is for the refactoring stage, when the tests are passing, allowing the developer to enhance the code

I chose this blog post because while test-driven development has been introduced in our coursework, I have sometimes found it difficult to manage the different phases clearly when applied. It is easy to get ahead of yourself — trying to refactor before a test passes, or worrying too much about details when writing a test. This concept helps me see how keeping a more distinct mindset at each step can prevent mistakes.

A point of interest for me was James noting that feeling uncomfortable during the Red stage is normal and even expected. In the past, when facing failing tests, I would often get discouraged or rush to fix the code without even thinking. Now I see that treating the Red stage as a signal to slow down and focus on getting back to green is a better approach. I also learned the importance of avoiding large changes while tests are failing, something I will pay closer attention to moving forward. Small incremental steps seems to be the recurring idea behind test-driven development

As I continue to learn, I plan to consciously apply this “thinking hats” approach when practicing test-driven development. I will aim to be more intentional: practical when writing tests, focused when resolving failures, and careful when refactoring. I expect that doing so will not only help me better follow the test driven development cycle, but also improve the quality and structure of my code overall. This blog post gave me a new practical framework to apply what we have been learning about test-driven development. It made the process feel more organized and achievable, which I believe will help me develop stronger habits for quality-focused software development.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.

As a computer science student delving into the world of software development, I’ve come to appreciate the significance of various practices that ensure the delivery of high-quality software. One such practice that recently caught my attention is the concept of technical reviews in software quality assurance.​

I explored the article “What is Technical Review in Software Testing?” by Testsigma, which provided a comprehensive overview of this critical process. A technical review is a structured evaluation conducted by a team of peers to assess the technical aspects of software artifacts, such as design documents, code, and test plans. The primary goal is to identify defects and areas for improvement early in the development lifecycle, thereby reducing the cost and effort associated with fixing issues later on.​

The article outlines several key objectives of technical reviews:​

• Defect Detection: Identifying errors in function, logic, or implementation before they propagate further into the development process
• Standards Compliance: Ensuring that the software adheres to organizational and industry standards.​
• Knowledge Sharing: Facilitating the exchange of ideas and knowledge among team members, which can lead to better design decisions and coding practices.​
• Process Improvement: Providing feedback that can be used to refine development processes and prevent future issues.​

Reflecting on this, I realize that incorporating technical reviews into our academic projects could be highly beneficial. Often, we focus on completing assignments and meeting deadlines, sometimes overlooking the importance of peer evaluations. By implementing structured reviews, we can catch mistakes early, learn from each other’s perspectives, and produce more robust and reliable code.​

Moreover, understanding the practice of technical reviews prepares us for industry expectations, where such evaluations are integral to the development process. It emphasizes the collaborative nature of software engineering and the collective responsibility of a team to ensure quality.​

In conclusion, technical reviews are a vital component of software quality assurance, offering numerous benefits that extend beyond mere defect detection. As students aspiring to become proficient software engineers, embracing this practice can enhance our learning experience and better equip us for professional challenges ahead.​

For a more in-depth understanding, I recommend reading the full article: What is Technical Review in Software Testing?

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

In complex programs, choosing valid test cases often means choosing from many different possible combinations of inputs to find the correct cases. Doing this could take an unnecessarily long time, slowing down the development process, and possibly causing some important cases can be missed. In the article, “Combinatorial testing: What is it, how to perform, and tools”, author Shanika Wickramasinghe explains the details of combinatorial testing, and how it solves the aforementioned problem.

Combinatorial testing involves using multiple combinations of variables for testing, with the goal of this being to verify which/how many inputs of test data, with this information then being used to design future tests. Some of the benefits of combinatorial testing include a larger coverage of possible test cases than normal testing, since multiple inputs are used, reduces the cost and effort of the testing process through the fact that it’s a faster method of testing, and avoiding redundancy, as combinatorial testing ensures that the same cases aren’t tested multiple times.

To better understand how combinatorial testing works, lets take a look at the author’s example. Say we’re trying to test a username and password functionality, and we decide we’re using combinatorial testing for this. Instead of each test case only including one username OR one password, like what would happen if normal testing was being used, each test case includes 1 username and 1 password from a pool of multiple usernames and passwords. For example, let the tested usernames be User1, User2, User3 and let the tested passwords be PW1, PW2. Then, test case 1 could be testing User1 and PW1, then case 2 would test User2, PW1, then case 3 would test User3,PW1, and so on. By doing this, every case would be covered with only 6 test cases, with the same case never being covered twice.

Other types and ways of implementing combinatorial testing are available as well. For example, the example listed above would be an example of manual combinatorial testing, where cases are manually selected from the pools of parameters, where in automated combinatorial testing, software or scripts are used to automate this process and create many test cases automatically. This is especially beneficial if there are many possible inputs, and manually picking each case would be too time consuming.

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

Unit testing is a very useful and secure way to stabilize the development process, but despite that, some developers forgo the testing process altogether. In Gergely Orosz’s blog entry, “The pyramid of unit testing”, he covers the relationship between the time it takes to notice the benefit of certain types of unit tests, and the experience of the coder designing the tests. For example, a coder with limited experience may look at a code body, see there are no obvious problem cases to be caught by unit testing, and forgo the process, while an experienced coder may see the same code and choose to design tests for it for reason that aren’t as obvious, and that are more based on experience and intuition.

Gergely details 5 different tiers of the Pyramid of Unit Testing Benefits, with the tiers lower on the pyramid listing benefits that can be noticed immediately, and tiers higher showing benefits that are only noticed in a later stage in development. The lowest tier are the benefits offered by tests designed to validate code changes. These tests are purely designed to validate recent changes, and make no attempt to catch future cases that might not be a problem now, showing an immediate benefit compared to not testing. The next tier up is the benefit of separating concerns in your code, which serves to somewhat force the coder to write clean code, since if a code is to be testable, that usually means that dependencies are declared upfront, leading the code to have an easier to follow structure. The next tier is the benefit of having an always up to date documentation. Well written tests can serve as useful documentation for code, and, unlike documentation of implementation code, these tests won’t get out of date. The second to last tier is avoiding regressions. If changes are made to a code body with no unit testing, than regression and conflicts are more likely to be introduced compared to a code body with tests. Designing tests helps avoid this by catching these regressions/conflicts before they become problems. The highest tier of the pyramid is using tests as a refactoring safety net. While testing is useful for validating small changes, it’s equally as useful for providing a stable environment for refactoring. When required to make large scale changes, a developer is more likely to be comfortable changing a code body with a large amount of coverage over many unit tests, rather than a code body with no means of catching problem cases.

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