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.

The article I selected is titled What is Test-Driven Development? It explores TDD, which stands for Test-Driven Development. A software development methodology where tests are written before writing the actual code. At first, this idea sounded very backward to me, especially as a student still learning how to code. Originally introduced by Kent Beck in the 1990s, TDD follows a specific cycle: first, you write a failing test for a small piece of functionality. Next, you write the minimal amount of code needed to make that test pass. Finally, you refactor the code while continuing to pass all the tests. This method aims to create reliable and well-structured code from the very beginning.

I chose this article because while working on the TDD assignment for class, I found myself very confused about why the process was designed this way. It felt unnatural to write tests before even having code to test. After reading a few articles, including this one, I learned that the main purpose of TDD is to reduce the amount of time spent debugging and to automate testing early. It helps ensure that the code behaves correctly as new features are added, reducing bugs and saving time later.

After practicing more during the assignment, I began to see the benefits firsthand. I enjoyed the process once I understood it better, even though there were moments when I had to refactor my code multiple times to make all the tests pass. One important takeaway from the article was how TDD encourages continuous improvement. As developers write more tests, their code quality naturally improves over time. I also learned that TDD plays an important role in Agile workflows, pushing developers to prioritize testing before writing large chunks of code. This mindset shift promotes creativity, collaboration between developers and QA testers, and reduces technical debt, making it easier to maintain and update code in the future.

This article and topic really changed how I view software development. It showed me that TDD can be both a creative and collaborative process rather than just a strict set of rules. I now plan to apply TDD practices in my future career. By writing tests first, I can better organize my development process, catch issues early, and build more reliable software. Exploring this topic helped me overcome my confusion during class and appreciate why Kent Beck created this approach in the first place.

Reference:
Moore, Paul. “What Is Test-Driven Development?” Scrumalliance.org, 2023, resources.scrumalliance.org/Article/test-driven-development.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

In the article I selected, the topic of JUnit, a popular Java testing framework, is introduced and explained. The article simplifies JUnit for beginners or those who have never used it before. It discusses key features such as assertions, test runners, test suites, and reporting tools. The article is divided into several sections, including an overview of what JUnit is, how it functions, the different types of testing it supports, and the key benefits of using it. It also provides a step-by-step guide on how to download and set up JUnit, making it an accessible resource for new learners.

Before taking this class, I barely knew anything about JUnit. As I read through the article, I learned that JUnit is part of the xUnit family of testing frameworks and is primarily used for automating unit tests in Java applications. It can also support other types of testing, such as functional and integration tests. One of the biggest takeaways for me was understanding the features that make JUnit so effective: assertions for verifying test results, test runners for executing tests, test suites for grouping tests together, and reporting tools for easily spotting problems. I also learned why using JUnit is important not only because it helps developers write more organized and readable code, but it also improves error detection and correction early in the development process. This ultimately boosts the efficiency of QA testers and software engineers.

I chose this article because we recently discussed JUnit in class, and I wanted to deepen my understanding beyond just what was covered in lectures. As someone studying to become a future software engineer, I realized that knowing how to write effective tests is just as important as writing code itself. Testing frameworks like JUnit ensure that applications behave as expected, making them more reliable and easier to maintain over time.

Reflecting on what I learned, I feel much more confident about incorporating unit testing into my future projects. Learning about assertions and test runners especially helped me see how testing can be integrated smoothly into the development process rather than being something added at the end. Going forward, I plan to apply this knowledge by writing unit tests alongside my code from the beginning, which I believe will make me a more efficient and thoughtful developer. Overall, this article not only expanded my technical skills but also shifted my mindset about the importance of testing in building quality software.

Reference:
Abhaya. “JUnit: A Complete Guide – Abhaya – Medium.” Medium, 9 Jan. 2024, medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

URL: https://stackoverflow.blog/2022/01/03/favor-real-dependencies-for-unit-testing/

Mark Seeman brings us an interesting idea about which dependencies should be used during testing. In his article Favor real dependencies for unit testing, he explains that not every dependency necessarily helps you develop your tests. His main point concerns the use of dependencies that generate some kind of fake implementation of your methods in order to allow you to test them. One great example of this is Mockito, a widely used Java library where you can ask the tool to mock an entire class implementation. Although that sounds completely reasonable at first glance, what could be one issue that Mark is possibly missing in his argument? I would say that he is missing the reason why developers often rely on mocks and stubs in real-world development scenarios.

The main reason someone may choose to use mocks and stubs is more related to collaborative group work rather than projects handled by a single developer. In group settings, such as when working on a complex system like a hotel booking website, developers are usually assigned to different components or features of the system. For example, imagine a situation where you are working as a developer on such a project and are responsible for the Bookings class, while your teammate is assigned to the Suites class. Both of you have been making progress on your respective parts, and now you want to start writing tests to ensure everything functions as expected.

However, if any of your methods rely on a function that your teammate has not yet implemented, you could run into difficulties. Without the other function available, you might not be able to fully test your own code, even though your part is technically complete. This could lead to a development bottleneck, preventing you from moving forward until the rest of the system is ready.

To solve such a problem, one practical solution is to use libraries like Mockito. These tools allow you to create a mock version of your teammate’s class or method, enabling you to continue writing and running tests without delay. As explained earlier, Mockito generates fake implementations that simulate the behavior of the real components. This makes it possible to isolate and verify your own code independently.

Mark’s point is valid in scenarios where a developer is solely responsible for both the implementation and testing of all related methods. In such cases, using real dependencies like database fakes or stubs may be more effective. However, in collaborative environments, mocking libraries are essential tools that support parallel development.

This article surprised me with its perspective and application. As I’ve learned in class, the use of mocks allows developers to test features that haven’t been implemented yet adding a useful layer of abstraction. I believe that such libraries are not meant to stay in the codebase permanently but rather serve as temporary scaffolding—tools meant to be discarded once the full system is in place.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.