홈

org.junit.Assert.assertEquals, org.junit.Assert.assertSame와 같은 표준 assertion 라이브러리 함수는 첫번째 인자에 예상되는 값을 넣고 두번째 인자에 실제 값을 넣을 것이라고 기대합니다. AssertJ에서는 다른 방식으로 동작합니다. org.assertj.core.api.Assertions.assertThat의 첫번째 인자는 실제 값이며 두번째 인자는 예상되는 값을 넣습니다. 인자에 값이 바뀌는 경우 테스트는 성공과 실패에 대해 동일한 결과를 갖지만, 에러메세지는 혼란을 줄 수 있습니다. 이 규칙은 Assertion 라이브러리 함수에 대한 실제 값 인수가 하드...

인프라 이슈로 테스트가 실패할 때 일시적으로 무시하는 것을 원할 수도 있습니다. 그러나 왜 이 테스트가 무시되었는지 어떤 표기가 없다면, 이 테스트는 재활성화될 것입니다. 이러한 테스트는 프로젝트에 대한 배경 지식 없이는 설명하기 어렵고 프로젝트를 오염시키게 될 것 입니다. 이 규칙은 각 무시된 테스트가 왜 무시되었는지 어떤 코멘트도 없는 경우 문제를 제기합니다. Junit4애서는 @Ignore 어노테이션을 타겟으로 합니다. Junit5에서는 @Disabled 어노테이션을 타겟으로 합니다. 테스트를 스킵하기 위해 assumeTrue(false) 또는 assumeFalse(true)를 사용하는 경우...

일반적인 모범 사례는 오직 한가지의 이유로 실패하는 하나의 논리적 개념을 타겟팅하는 테스트 함수를 작성하는 것입니다. 하나의 개념을 테스트하기 위해 하나 이상의 assertion을 가지는게 타당할 수 있지만, 너무 많은 assertion을 갖는 것은 테스트가 너무 복잡해졌다는 신호이므로 여러 개로 리팩터링해야 합니다. 이 규칙은 테스트 함수가 지정된 assertion 개수보다 더 많이 포함하고 있을 때 알려줍니다. 규칙을 어긴 코드 파라미터가 2 입니다. @Test void test() { // 이 함수를 리팩터링 해보세요. assertEquals(1, f(1)); assertEquals(2...

예외를 테스트하는 AssertJ 함수(assertThatCode(), assertThatExceptionOfType(), …)와는 달리, assertThatThrownBy() 함수는 단독으로 사용할 수 있으며, 코드에서 예외를 발생시키지 않으면 실패합니다. 그러나 오직 예외가 발생한 것을 테스트하는 것만으로는 이것이 예상된 것이라고 보장하는데 부족하며, 예외 타입을 또는 내용 추가로 테스트해야만 합니다. 이 규칙은 assertThatThrownBy가 예외를 추가로 테스트하지 않고 사용되었을 때 문제를 제기합니다. 규칙을 어긴 코드 assertThatThrownBy(() -> shouldThrow());...

JUnit의 assertTrue(), assertFalse()로 동등성 또는 null인지 테스트하는 것은 해당 전용 assertion으로 간소화되어야만 합니다. 규칙을 어긴 코드 Assert.assertTrue(a.equals(b)); Assert.assertTrue(a == b); Assert.assertTrue(a == null); Assert.assertTrue(a != null); Assert.assertFalse(a.equals(b)); 규칙을 준수한 코드 Assert.assertEquals(a, b); Assert.assertSame(a, b); Assert.assertNull(a); Asser...

런타임 예외를 발생시키는 코드를 검증할 때, 모범 사례는 어떤 함수 호출이 예외를 일으키는지 명백하게 예상하기 위해서, 여러 개의 함수 호출을 테스트 코드 안에 넣는 것을 피하는 것입니다. 이 방법은 테스트의 명확성을 높이고 다른 함수가 실제로 예외를 발생시킬 때 부정확한 테스트를 방지합니다. 규칙을 어긴 코드 @Test public void testToString() { // get() 또는 toString()이 예외를 발생시킬 것이라고 생각합니까? org.junit.Assert.assertThrows(IndexOutOfBoundsException.class, () -> get().toS...

중첩된 if/else 문이 중괄호 없이 작성되면 dangling else 문제가 발생합니다. 이런 경우, else가 가장 가까운 if와 연결되지만 사용사례가 불분명해지고 어쩔 때는 그냥 사용자가 들여쓰기가 잘못한 것일 수도 있습니다. 이 규칙은 중괄호가 없이 중첩된 if 문이 있어서 이해하기 어려운 else문법이 사용될 때 알림이 울립니다. 중괄호를 추가하는 것이 일반적으로 코드를 더 명확하게 만드는 방법입니다. (규칙 {rule:java:S121} 참조) 그리고 dangling else 상황에서도 코드의 의도를 더 명확하게 만듭니다. 규칙을 어긴 코드 if (a) if (b) d++; else ...

두 메소드가 동일한 방법으로 구현되는 경우, 실수인지 의도한 것인지 알 수 없습니다. 중복한게 의도한 것이라면, 둘 중 하나의 구현체가 다른 구현체를 호출하는 방식으로 구현되어야 합니다. 숫자나 문자 리터럴은 고려되지 않습니다. 규칙을 어긴 코드 private final static String CODE = "bounteous"; public String calculateCode() { doTheThing(); return CODE; } public String getName() { // 규칙을 어긴 코드 doTheThing(); return CODE; } 규칙을 준수한 해결책 priv...