문자열의 printf-style 포맷은 제대로 사용되어야 합니다

printf-style 포맷 문자열은 컴파일러를 통해 검증되지 않고 인터프리터를 이용하여 런타임에 해석됩니다. 따라서 오류가 생길 수 있고 잘못된 문자열이 만들어질 수 있습니다. 이 규칙은 아래와 같은 클래스들의 format(...) 메소드를 사용할 때 전달인자와 포맷을 정적으로 분석하여 검증합니다. java.util.Formatter java.lang.String java.io.PrintStream MessageFormat java.io.PrintWriter 더불어 아래와 같은 클래스들의 printf(...) 메소드를 사용할 때도 이 규칙이 사용됩니다. java.io.PrintSt...

더보기

테스트는 안정적이어야 합니다.

안정적이지 않은 테스트는 어떠한 코드 수정없이 때때로 성공하고 실패하는 테스트입니다. 분명히 개발자가 실패한 테스트를 다시 실행해야 할 때 개발 속도가 느려집니다. 그러나 진짜 문제는 완벽하게 이 테스트를 믿을 수 없다는 것이고 많은 다른 이유로 테스트는 실패할 것입니다. 그리고 이것이 production에서 어떤 문제를 일으킬지 모릅니다. TestNG와 같은 몇가지 도구는 개발자를 자동적으로 이상한 테스트를 재시도할 수있도록 가능하게 해줍니다. 이것은 일시적인 해결책으로 괜찮을 것입니다. 그러나 이것은 정확하게 고쳐져야 합니다. 더 이상한 테스트를 추가할 수록 버그들이 production으로 도달하는 더 많...

더보기

스프링의 ModelAndViewAssert Assertions 가 다른 assertions 대신 사용되어야 합니다.

스프링 프레임워크는 더 작성하기 쉽고 간단한 단위테스트를 돕기 위한 클래스들을 함께 제공합니다. 특히, 스프링 MVC 로 구축된 애플리케이션을 테스트할 때, MVC 의 속성들을 수동으로 테스트하는 대신 스프링의 ModelAndViewAssert assertions 클래스를 사용하는 것이 더 낫습니다. 이 규칙은 수동 테스트 대신 스프링의 ModelAndViewAssert assertions 를 사용해야 할 때 문제를 제기합니다. 규칙을 어긴 코드 ModelAndView mav = getMyModelAndView(); Assert.assertEquals("register", mav.getViewName());...

더보기

Assertions은 자기 자신과 비교해서는 안됩니다.

스스로를 비교하는 Assertions은 개발자의 부주의로 인한 버그일 가능성이 높습니다. 이 규칙은 실제 식이 예상 식에 표현되는 경우 알려줍니다. 규칙을 어긴 코드 assertThat(actual).isEqualTo(actual); // 규칙을 어긴 코드 assertThat(actual).isEqualTo(expected); // 규칙을 준수한 코드 예외 유닛테스트에서 equals() 함수와 hashCode() 함수를 검사하는 경우, 자기 자신과 비교하는 것은 적절합니다. 이 규칙은 유닛테스트 이름이 equal, hash_?code, object_?method를 대소문자 구분 없이 포함한다면, is...

더보기

AssertJ 함수에서 assertion context를 설정하려면 assertion 이전에 나와야 합니다.

AssertJ에서 설명하기, 에러메세지 설정, comparator 추가는 assertion 호출 전에 끝나야 합니다. 그렇지 않으면 설정이 적용되지 않습니다. 이 규칙은 AssertJ assertion을 호출한 뒤에 다음과 같은 함수나 유사한 함수 중 하나를 호출 할 때 문제 상황을 알려줍니다. as describedAs withFailMessage overridingErrorMessage usingComparator usingElementComparator extracting filteredOn 규칙을 어긴 코드 assertThat(actual).isEqualTo(expec...

더보기

AssertJ 설정은 apply 되어야 합니다.

org.assertj.core.configuration.Configuration은 Configuration.apply() 또는 Configuration.applyAndDisplay() 함수를 호출해야지만 효과가 있습니다. 이 규칙은 적절한 apply 호출이 없는 경우 문제를 제기합니다. 규칙을 어긴 코드 Configuration configuration = new Configuration(); // 규칙을 어긴 코드, 이 설정은 apply 되지 않습니다. configuration.setComparingPrivateFields(true); Configuration configuration = new Conf...

더보기

JUnit5 테스트 클래스와 함수는 조용히 무시되어서는 안됩니다.

JUnit5은 모든 것을 public으로 했던 JUnit4 보다 클래스와 함수의 가시성에 대해 더 관대합니다. JUnit5는 default 패키지 가시성을 권장하는 경우에도 default 패키지와 public, protected 가시성을 지원하므로 코드의 가독성이 향상됩니다. 하지만 다음과 같은 경우에 대해 JUnit5는 어떤 경고도 없이 무시합니다. private 클래스와 private 함수 static 함수 TestFactory 없이 값을 반환하는 함수 규칙을 어긴 코드 import org.junit.jupiter.api.Test; class MyClassTest { @Test ...

더보기

스프링 컴포넌트는 생성자 주입을 사용해야 합니다.

스프링의 @Controller, @Service 그리고 @Repository 클래스들은 기본적으로 애플리케이션에서 클래스의 인스턴스 하나만 인스턴스화되는 싱글톤 객체입니다. 일반적으로 이러한 클래스들은 logger 와 같은 적은 수의 static 멤버 변수들을 가지지만, 모든 non-static 멤벼 변수들은 스프링에 의해 관리되어야 하고 또한 필드 주입 대신 생성자 주입을 통해 주입되어야 합니다. 이 룰은 스프링 컴포넌트에서 non-static 멤버 변수가 Injection 어노테이션을 가지는 경우 문제를 제기합니다. 규칙을 어긴 코드 @Controller public class HelloWorld { ...

더보기