About validation methods in JUnit

The other day, when I tried using JUnit 5 late, assertThat was gone. It seems that the policy is "use assertions that users like."

So, about the verification method used in JUnit Let's consider the usage candidates including the ones that have been used so far. org.junit.Assert.assertEquals Traditional method. I was taken care of when I was a new employee. It's not used much now because it has assertThat (should).

@Test
public void test01() {
    int sum = add(30, 70);
    assertEquals(100, sum);
}
Expected value and measured value are difficult to understand
According to Javadoc, the left is the expected value and the right is the measured value, but I often forget it.
When developing a team, some people write it in reverse, which can cause confusion later.
Some people may say "it doesn't matter which one", but the error message in which the expected value and the measured value are reversed is personally unpleasant.

java.lang.AssertionError: expected:<0> but was:<100>


</dd>
 <dt> Only match judgment can be supported </ dt>
 The <dd> method name is equals, so it's only natural. <br> In cases other than match judgment, assertTrue, which will be described later, should be used. </ dd> </ dl>

 org.junit.Assert.assertTrue
 A traditional method like assertEquals. This was also taken care of when I was a new employee.
 Since boolean is taken as an argument, it is common to pass a comparison expression or a judgment method that returns boolean for verification.

```java
@Test
public void test02() {
    int sum = add(30, 70);
    assertTrue(sum > 50);
}
Error message is hard to understand I don't get a message like
.
If you want to use JUnit with CI, this is the option you don't want to take.

org.junit.Assert.assertThat Introduced from JUnit 4. It was mainstream in JUnit 4. Validate by passing the measured value as the first argument and org.hamcrest.Matcher as the second argument. Be careful because the measured and expected values are the opposite of assert Equals.

Almost all verifications should be possible with this assertThat, as a wealth of Matchers are provided. The following article was very easy to understand about how to use Matcher, so I will introduce it.

■ How to use the method defined in Matchers of Hamcrest https://qiita.com/opengl-8080/items/e57dab6e1fa5940850a3

@Test
public void test04() {
    int sum = add(30, 70);
    assertThat(sum, is(100));
}

@Test
public void test05() {
    String userName = "Yamada Taro";
    assertThat(userName, containsString("Ta"));
}
Highly readable validation syntax It is easy to read when viewed as an English sentence, such as
assert that sum is 100. It is also possible to reverse the truth of the expected value by combining
not ().
Matcher can be customized By creating your own
Matcher, you can perform project-specific verification.
It is great that you can define the error message yourself.

org.assertj.core.api.Assertions.assertThat Personally, my favorite at the moment. I want to use this if I start implementing JUnit from now on. The big difference from JUnit's assertThat is that the argument is only the measured value, and the expected value verification after that can be done in the method chain.

@Test
public void test01() {
    String userName = "Suzuki Jiro";
    assertThat(userName).contains("Ji");
}
    
@Test
public void test02() {
    int sum = add(30, 70);
    assertThat(sum).isGreaterThan(50);
}
IDE shows candidate validation methods
Junit's assertThat specifies a static validation method as the second argument, which is surprisingly painful. Unless you use it very often, you won't remember the verification method name one by one. When using assertThat of
AssertJ, since the verification method of the instance returned by assertThat is called, the method candidates that match the type of the measured value are displayed in the IDE.
I felt very grateful when I actually used it. assertjStr.png assertjInt.png

I will introduce the verification method of AssertJ because this article was well organized and easy to understand.

■ Assert J version: List of verification methods often used in testing https://qiita.com/naotawool/items/6512ecbe2fd006dacfd2

com.google.truth.Truth.assertThat An assertion library provided by Google. It's officially touted, but it's very similar to AssertJ, with a flowing interface for assertions. If it is similar to this, I think AssertJ is fine, but Truth provides a named method that names the measured value, and it seems that it can be reflected in the error message. There seems to be other unique elements, but they have not been investigated ... I will take a chance somewhere and compare it with AssertJ.

@Test
public void test01() {
    String userName = "Suzuki Jiro";
    assertThat(userName).named("userName").contains("Ji");
}

@Test
public void test02() {
    int sum = add(30, 70);
    assertThat(sum).named("sum").isEqualTo(100);
}

at the end

So, for the time being, I'm going to use AssertJ's assertThat as the validation method. AssertJ also has a library called AssertJ-DB for DB testing, so I would like to try this as well in the future.

Recommended Posts