"You Don't Know Java" 💘 The Philosophy of Unit Test Naming

Chuck1sn — Mon, 17 Feb 2025 08:43:23 +0000

The Design Philosophy of Unit Testing

Programs are written primarily for humans to read, and only incidentally for machines to execute.

Programs must be written for people to read, and only incidentally for machines to execute.

The first step in writing code is naming, and the same applies to unit tests.

WWW

How can you make the names of your unit tests understandable? You need to reflect three elements in the naming, abbreviated as the WWW principle.

What are you testing? (what)
Under what conditions are you testing? (when)
What behavior do you expect? (want)

Let's take a look at a unit test example from the MJGA scaffolding.

  @Test
  void createVerifyGetSubjectJwt_givenUserIdentify_shouldReturnTrueAndGetExpectIdentify() {
    String jwt = cookieJwt.createJwt("1");
    assertThat(cookieJwt.verifyToken(jwt)).isTrue();
    assertThat(cookieJwt.getSubject(jwt)).isEqualTo("1");
  }

Breaking down the name into three parts:

createVerifyGetSubjectJwt reflects the object being tested.
givenUserIdentify indicates the condition under which the test is conducted.
shouldReturnTrueAndGetExpectIdentify describes the expected behavior.

This is a good name—one that a business person can understand.

AAA

The first hurdle is over; now let's implement the test logic. In fact, with the WWW naming design, the logic implementation already has a clear path. Like naming, test logic also has principles to follow, commonly known as the AAA principle.

Arrange
Act
Assert

Let's continue with a test case from the MJGA scaffolding:

@Test
  @WithMockUser
  void signIn_givenValidHttpRequest_shouldSucceedWith200() throws Exception {
    String stubUsername = "test_04cb017e1fe6";
    String stubPassword = "test_567472858b8c";
    SignInDto signInDto = new SignInDto();
    signInDto.setUsername(stubUsername);
    signInDto.setPassword(stubPassword);
    when(signService.signIn(signInDto)).thenReturn(1L);

    mockMvc
        .perform(
            post("/auth/sign-in")
                .contentType(MediaType.APPLICATION_JSON)
                .content(
                    """
                {
                  "username": "test_04cb017e1fe6",
                  "password": "test_567472858b8c"
                }
                 """)
                .with(csrf()))
        .andExpect(status().isOk());
  }

Arrange

This is the preparation phase of the test. In this phase, you need to construct some code that provides context, such as inserting data, building objects, or even more complex mocks and stubs. In the example, we constructed the SignInDto object for subsequent use and assumed the return value of the signIn method—all in preparation for the subsequent test.

Act

This is the execution phase, corresponding to mockMvc.perform in the example. The API is just a bit complex here, so you can think of it as a single line of code.

Assert

You need to clearly state what result you expect. In the example, this corresponds to .andExpect(status().isOk());.

Often, you may need to write some test methods to verify whether a certain logic can run without errors, as the method itself has no return value. This is easy to solve using assertDoesNotThrow.

 // pause & resume job
    JobKey firstDataBackupJobKey = dataBackupJobKeys.iterator().next();
    assertDoesNotThrow(
        () -> {
          dataBackupScheduler.pauseJob(firstDataBackupJobKey);
          dataBackupScheduler.resumeJob(firstDataBackupJobKey);
        });

These coding philosophies are independent of the language and framework you use. Any unit test is written with this mindset. More content on unit testing will be shared in the future.

Final Words

I am Chuck1sn, a developer long committed to promoting the modern JVM ecosystem.
Your replies, likes, and bookmarks are the motivation for my continuous updates.
A simple triple action (like, comment, share) means a lot to me and is greatly appreciated!
Follow my account to receive article updates as soon as they are published.

PS: All the code examples above can be found in the Github repository. If it helps, please give it a Star—it's a great encouragement to me. Thank you!

"You Don’t Know Java" 💫 Dto, Vm, Vo, Entity, Domain, Bean, and Pojo reference Table

Chuck1sn — Wed, 14 Feb 2024 03:28:44 +0000

I have compiled a table for easy reference on Dto, Vm, Vo, Entity, Domain, Bean, and Pojo, which are commonly used concepts in object-oriented programming.

Please note that this table is not a strict convention to be followed, and in actual development, you should refer to it based on your specific needs rather than blindly applying it.

In this scaffold, I have not strictly adhered to all the concepts listed in the table but have used some of them based on the actual requirements.

You can find the scaffold at the following URLs:

Most of the time, I use entities, DTOs, and view models (VMs). When my project grows larger, I introduce domain objects and value objects (VOs).

Suffix	Definition	Purpose	Note	Three-Layer Architecture
DTO	Data Transfer Object. Usually contains only properties and getter/setter methods, no business logic.	Used to transfer data between different layers of the application	Immutable.	Service
VM	View Model. Typically represented by immutable objects such as records.	Maps data in the view and decouples the view from the model	Immutable.	Controller
Entity	Entity Object. Typically contains the properties and behavior of an entity, but not complex business logic.	Represents entities or objects in the business domain, such as users, orders, products, etc. Part of the domain model. Typically created and managed by the data access layer.	Has an independent lifecycle.	DAO
Vo	Value Object. An immutable object whose value does not change after creation. It does not contain business logic or complex computations.	A standalone class that does not directly depend on business logic or the data access layer. Typically created and managed by the domain model or service layer to represent simple values.	Does not have an independent lifecycle. Requires defining the equals method.	Service
DO (Domain Object)	Domain Model. Typically holds multiple class members such as entities, value objects, etc., that constitute the business aspects of the domain, and includes complex methods implementing business logic.	Used to represent the business concepts and rules of a specific domain, encapsulating the business logic and behavior of the application.	Has an independent lifecycle. The lifecycle of the value objects it holds depends on the domain model.	Service

Name	Definition	Purpose
Bean	Follows specific rules. Must have a no-arg constructor and properties accessed using getter and setter methods.	Suitable for transferring data between different layers or encapsulating business-agnostic functionality such as objects managed by the Spring container.
Pojo	Plain Old Java Object, with no specific restrictions.	Suitable for various scenarios, especially those related to business, such as mapping database entities.

By the way, as a side note, if this table or scaffold is helpful to you, you may consider giving me a star. It would be a great encouragement for me. Thank you for your generosity!

DEV Community: Chuck1sn