JUnit Basics — Use JUnit basics to structure tests (intro)

Imagine finishing a large Java project, running it, and discovering that something broke—but you have no idea where the problem started. Before automated testing frameworks existed, developers relied on manually running their programs, inspecting output with their eyes, and inserting System.out.println() statements everywhere to check values. This was slow, unreliable, and easy to forget. The need for a better approach led to the creation of unit testing—a method where small, individual pieces of code are tested automatically by other code.

The story of JUnit is closely tied to the rise of test-driven development (TDD) and the broader movement toward writing cleaner, more reliable software. Kent Beck, a software engineer known for pioneering extreme programming, created SUnit for the Smalltalk language in the late 1990s. He then partnered with Erich Gamma to adapt the concept for Java during a transatlantic flight, and JUnit was born. Today, JUnit is the most widely used testing framework in the Java ecosystem.

The central question JUnit answers is straightforward: how can we verify that our code does what we expect, quickly and automatically, every single time we make a change? Instead of manually checking your program's output, you write small test methods that run themselves and report pass or fail. This lesson introduces the core building blocks of JUnit so you can start structuring your own tests.

Before writing your first test, you need to understand the key ideas that make JUnit work. A unit test is a small piece of code that checks whether a specific method or function behaves correctly. The word "unit" refers to the smallest testable part of your program—usually a single method. JUnit provides a structured way to write, organize, and run these tests so you don't have to do it by hand.

The diagram below shows the structure of a typical JUnit 5 test class and how its parts connect. Pay attention to how the annotations, test methods, and assertions work together in a clear, repeatable pattern.

Notice the pattern: JUnit runs @BeforeEach before every single test method, executes the @Test method, and then runs @AfterEach afterward. This means each test starts with a clean slate, so one test cannot accidentally affect another. This isolation is one of the most important ideas in unit testing—each test should be independent and repeatable.

Understanding the test lifecycle helps you predict exactly when each part of your test class runs. JUnit 5 follows a strict sequence for every test method it discovers. Think of it as a recipe that JUnit repeats for each test: set up, test, tear down.

The Execution Order

1. @BeforeAll — Runs once before all tests in the class (must be static). Use it for expensive setup like opening a database connection.
2. @BeforeEach — Runs before each individual test method. Use it to create fresh objects so tests don't share state.
3. @Test — The actual test method. Contains assertions that check expected vs. actual values.
4. @AfterEach — Runs after each test method. Use it to release resources or reset variables.
5. @AfterAll — Runs once after all tests finish (must be static). Use it for final cleanup.

Common Assertion Methods

Assertions are the heart of every test. They are the lines of code that actually check whether your program produced the right result. JUnit 5 provides several assertion methods in the Assertions class. Each one compares an expected value (what you think should happen) against an actual value (what really happened when your code ran).

Professional developers follow a pattern called Arrange-Act-Assert (AAA) to keep every test method clean and readable. This pattern divides each test into three distinct sections. First, you arrange the objects and data you need. Next, you act by calling the method you want to test. Finally, you assert that the result matches your expectation.

Following the AAA pattern makes your tests self-documenting. Anyone reading your test can quickly see what setup is needed, what action is being tested, and what result is expected. If a test fails, the pattern makes it easy to identify whether the problem is in the setup, the method call, or the expectation itself.

Let's walk through a complete example. Suppose you have a simple Calculator class with an add() method and a divide() method. We will write a JUnit 5 test class that verifies both methods work correctly, including handling edge cases like division by zero.

Writing tests is only helpful if you write them well. Poorly structured tests can be confusing, fragile, or even give you false confidence. The table below compares best practices with common mistakes that new testers often make.

The JUnit basics you've learned here are just the starting point. As your projects grow larger, you'll encounter more sophisticated testing techniques that build on these foundations. Understanding where basic JUnit fits in the bigger picture will help you appreciate why mastering the fundamentals matters.

As you move forward, you'll discover that the Arrange-Act-Assert pattern and the annotation-based lifecycle you learned today carry over directly to these advanced techniques. Parameterized tests still use assertions; mock objects still follow the AAA pattern; nested tests still use @BeforeEach. Mastering the basics now gives you a solid foundation for everything that comes next.