홈

접을 수 있는 if문은 합치는 것이 가독성을 올려줍니다 규칙을 어긴 코드 if (file != null) { if (file.isFile() || file.isDirectory()) { /* ... */ } } 규칙을 준수한 해결책 if (file != null && isFileOrDirectory(file)) { /* ... */ } private static boolean isFileOrDirectory(File file) { return file.isFile() || file.isDirectory(); } If you like SONARKUBE, don’t...

JUnit5 문서에 언급돼있듯, JUnit4와 JUnit5를 같이 사용하는 것은 가능합니다. JUnit은 JUnit Vintage 테스트 엔진을 통해 완만한 마이그레이션 경로를 제공하며, JUnit Platform 인프라를 사용하여 JUnit3 및 JUnit4 기반의 기존 테스트를 실행할 수 있습니다. JUnit Jupiter와 관련된 모든 클래스와 어노테이션 명세가 새로운 “org.junit.jupiter” 기본 패키지에 존재하기 때문입니다. classpath에 JUnit4와 JUnit Jupiter가 동시에 있는 것은 어떠한 충돌도 일으키지 않습니다. 하지만 두 시스템을 관리하는 것은 일시적인 해결책...

네이밍 컨벤션을 공유하는 것은 팀이 효율적으로 작업할 수 있도록 합니다. 이 규칙은 테스트 함수 이름이 제공되는 정규식에 맞지 않는 경우 문제를 제기합니다. 규칙을 어긴 코드 기본 정규식: ^test[A-Z][a-zA-Z0-9]*$ @Test public void foo() { // 규칙을 어긴 코드 //... } 규칙을 준수한 해결책 @Test public void testFoo() { // ... } If you like SONARKUBE, don’t forget to give me a star. 원문으로 바로가기

assertion에 boolean 값이나 null 값 자체를 사용할 이유가 없습니다. 이것들을 사용하는 대신에 assertEquals, assertNotEquals, assertTrue, assertFalse, assertNull, assertNotNull, assertNotNull 또는 유사한 함수를 사용하세요.(또는 Fest 프레임워크를 사용할 때 isNull 등을 사용하세요.) 동등성과 관련이 없는 assertion(예: assertNull)과 함께 사용하는 것은 버그일 가능성이 높습니다. 지원되는 프레임워크: JUnit3 JUnit4 JUnit5 Fest assert 규칙을 어긴 코드...

JUnit, FEST, AssertJ에 메세지를 추가하는 것은 미래 생산성을 위한 투자입니다. 지금은 몇초를 걸쳐 메세지를 작성하지만 테스트가 실패하고 문제를 빠르게 진단할 필요할 때 많은 시간을 절약할 수 있습니다. 또는 테스트를 관리할 필요가 있거나 assertion 메세지는 일종의 가이드 문서로 동작합니다. 규칙을 어긴 코드 assertEquals(4, list.size()); // 규칙을 어긴 코드 try { fail(); // 규칙을 어긴 코드 } catch (Exception e) { assertThat(list.get(0)).isEqualTo("pear"); // 규칙을 어긴 ...

어떤 수학적인 연산은 결과 값이 너무 명확해서 수행할 필요가 없습니다. 예를들어 어떤 값에 mod 1 연산을 해도 값은 항상 0이 반환되므로, 이런 계산은 멍청한 행동입니다. 또한 부동 소수가 아닌 값을 부동 소수값으로 바꾸고 Math.round를 한다거나 Math.ceil, Math.floor 같은 연산을 하는 것은 매우 어리석습니다. 왜냐면 원래 값과 똑같을 것이기 때문입니다 더불어 상수 값에 다음 연산을 하는 것도 어리석은 행동입니다 Math.abs, Math.ceil, Math.floor, Math.rint, Math.round. 그리고 다음과 같은 특정 연산에 특정 값을 사용하는 것도 어리석은 행동입니다...

일반적으로 Exception을 로깅한 다음 다시 throw하면 애플리케이션에 동일한 Exception을 여러번 로깅하는 길고 긴 로그가 생겨납니다. 멀티 스레드를 사용하는 응용 프로그램에서 이러한 유형의 로그 디버깅은 최악입니다. 왜냐면 다른 스레드에 있는 메시지가 Exception의 반복된 로깅과 throw에 뒤엉키기 때문입니다. Exceptions은 로그 처리되거나 rethrow 둘 중 하나만 되어야지 둘 다 되어선 안됩니다 규칙을 어긴 코드 catch (SQLException e) { ... LOGGER.log(Level.ERROR, contextInfo, e); throw new MySQLE...

Exception을 이용해 catch한 다음 instanceof를 이용해 분기하는 대신, 정의된 타입을 이용해 catch하는 것이 좋습니다. 규칙을 어긴 코드 try { /* ... */ } catch (Exception e) { if(e instanceof IOException) { /* ... */ } // 규칙을 어긴 코드 if(e instanceof NullPointerException{ /* ... */ } // 규칙을 어긴 코드 } 규칙을 준수한 해결책 try { /* ... */ } catch (IOException e) { /* ... */ } ...