Mockito 인수 일치자(argument matchers)는 모든 파라미터가 사용되어야 합니다.
Mockito는 함수 호출을 유연하게 분리하거나 확인하기 위해 인수 일치자와 인수 저장자(argument captor)를 제공합니다.
각 Mockito.verify(), Mockito.when(), Stubber.when(), BDDMockito.given() 함수는 인수 일치자와 관계 없이 오버로딩할 수 있습니다.
하지만 만약 인수 일치자 또는 저장자가 오직 몇 개의 매개 변수를 사용한다면, 모든 매개 변수는 일치자를 가져야 합니다. 그렇지 않으면 InvalidUseOfMatchersException 예외가 발생합니다.
이 규칙은 결과적으로 stubbed/verified 된 메서드의 일부 매개 변수에 대해 ...
Mockito 객체는 초기화되어야 합니다.
@Mock, @Spy, @Captor, @InjectMocks와 같은 Mockito 어노테이션이 달린 객체는 명확하게 초기화될 필요가 있습니다.
이 작업에는 여러가지 방법이 있습니다:
셋업 함수 안에 MockitoAnnotations.openMocks(this), MockitoAnnotations.initMocks(this) 함수를 호출하세요.
테스트 클래스에 @RunWith(MockitoJUnitRunner.class) 어노테이션을 추가하세요. (JUnit 4)
테스트 클래스에 @ExtendWith(MockitoExtension.class) 어노테이션을 추가하세요. (JUnit 5 Jupiter)...
테스트는 랜덤 데이터 대신에 고정된 데이터를 사용해야 합니다.
테스트는 항상 다음을 만족해야만 합니다:
프로덕션 코드가 엣지 케이스를 포함하여 예상된 동작을 하도록 해야 합니다.
디버그하기 쉽게 해야 합니다. 즉, 이해할 수 있고 재현할 수 있어야 합니다.
테스트에 랜덤 값을 사용하는 것은 필요하지 않은 엣지 케이스를 확인하는 것입니다. 그리고 테스트 로그를 읽기 힘들게 만듭니다. 쉽게 읽기 좋은 하드코딩된 값을 사용하는 것이 더 낫습니다.
여기 테스트에서 랜덤 데이터에 대한 유효한 유즈 케이스입니다: 모든 값을 테스트하면 테스트가 비현실적으로 느려지는 경우, 랜덤을 사용하여 장기적으로 모든 값을 테스트하는 것이 최선입니다.
랜덤 값을 확실하게 기록하여 실패...
유닛 테스트는 예외를 던저야 합니다.
유닛 테스트 코드가 예외를 던질 때, 테스트는 스스로 실패합니다. 그러므로 실패를 탐지하기 위해 try-catch 문으로 테스트 코드를 감쌀 필요가 없습니다. 대신에 함수 시그니처에 예외 타입을 옮겨 간소화 할 수 있습니다.
이 규칙은 실패 assertion이 catch 블럭에 있는 경우 문제를 제기합니다.
지원하는 프레임워크:
JUnit3
JUnit4
JUnit5
Fest assert
AssertJ
규칙을 어긴 코드
@Test
public void testMethod() {
try {
// 코드...
} catch (MyException e) {
...
테스트는 지정된 소스 디렉토리에 유지되어야 합니다.
테스트 클래스를 프로덕션이 아닌 별도의 패키지로 분리하여 테스트 클래스에 의해 오염되지 않도록 하는 것이 좋습니다.
또한 코드 어셈블리에 단위 테스트를 포함하면 빌드 프로세스에 영향을 미칠 수 있습니다.
이 규칙은 테스트와 관련되지 않은 코드가 포함된 프로젝트에서 테스트 클래스가 발견될 때 문제를 발생시킵니다.
If you like SONARKUBE, don’t forget to give me a star.
원문으로 바로가기
"Lock"에 사용되는 객체는 "synchronized"되어선 안됩니다
java.util.concurrent.locks.Lock은 synchronized보다 강력하고 유동적인 형태로 locking 연산을 제공합니다
그래서 Lock에 synchronized를 사용하는 것은 매우 어리석은 일입니다
이런 객체는 tryLock()이나 unlock()같은 방식으로 잠금을 제어하는 것이 맞습니다
규칙을 어긴 코드
Lock lock = new MyLockImpl();
synchronized(lock) { // 규칙을 어긴 코드
//...
}
규칙을 준수한 해결책
Lock lock = new MyLockImpl();
lock.tryLock();
//...
같이보면 좋은 자료
...
정적 메서드만 있는 클래스를 인스턴스화해선 안 됩니다
정적 메서드는 인스턴스 없이 액세스할 수 있습니다.
따라서 정적 메서드만 있는 클래스를 인스턴스화할 이유가 없습니다.
규칙을 어긴 코드
public class TextUtils {
public static String stripHtml(String source) {
return source.replaceAll("<[^>]+>", "");
}
}
public class TextManipulator {
// ...
public void cleanText(String source) {
TextUtils textUtils = new TextUtils(); // 규칙을 ...
멍청한 문자열 작업을 수행해서는 안 됩니다
substring(0)을 사용하는 것은 멍청한 짓입니다.
결과가 요청 전의 문자열과 똑같을겁니다.
마찬가지로 substring에 String.length을 substring의 시작이나 끝에 넣는 것도 어리석은 짓입니다.
그리고 String.contains에 호출 값을 넣는 것도 말이 안되는 의미없는 행동이니 피해야합니다
규칙을 어긴 코드
String speech = "Now is the time for all good people to come to the aid of their country.";
String s1 = speech.substring(0); // 규칙을 어긴 코드. 나머지 문자열이 전체 문자...
전체 글 239개, 30 페이지