TEST CODE (5) 썸네일형 리스트형 [Junit] Spring boot 에서 @ControllerAdvice 를 테스트하는 방법 새로 작업한 매니저 사이트에 예외처리를 구성하던 중 ControllerAdvice 를 사용하게 되었습니다. ControllerAdvice 를 테스트하기 어려운 어려운 이유는 단순히 Junit 에서 제공하는 excpeted 를 사용하여 테스트할 수 없기 때문입니다. Junit 에서 제공하는 @Test 의 expected 는 테스트하고자하는 서비스가 예외를 던졌을 때 던져진 예외가 어떤 Class 인지를 확인하기 위한 용도로 사용됩니다. 예를 들어, 아래와 같은 Login 시 조회된 결과가 존재하지 않을 때 NotExistUserException 을 던지는 Service 가 존재한다고 가정합니다. public List login(LoginVO.Login params){ List users = loginMap.. [JUnit]같은 타입인 여러개의 Mock 객체를 @InjectMock 으로 주입 시 파라미터를 제대로 인식하지 못하는 문제 해결 Reflection 을 이용하여 2개의 Mapper 을 동적으로 호출하기 위한 Util 을 만들기 위해 다음과 같이 Object 타입의 클래스를 2개 주입받아 초기화되는 로직을 작성하였습니다. private Object firstMapper; private Object secondMapper; public ReflectionUtils(Object firstMapper, Object secondMapper) { this.firstMapper = firstMapper; this.secondMapper = secondMapper; } 이를 테스트 하기 위해 다음과 같이 Mapper 를 @Mock 으로 생성하여 @InjectMock 으로 주입하고자 했습니다. @RunWith(MockitoJUnitRunner.c.. [JUnit] Test code 작성시 DI(Dependencies Inject) 를 적용하는 방법 Spring boot 에서 테스트 코드를 작성할 때, 고민되는 것 중 하나가 의존성 문제 해결입니다. 한 Service 가 다른 Service 를 의존하여 실행되거나, Controller 가 Service 를 의존하거나, Mybatis 를 사용하는 경우 Service 에서 Mapper 를 의존하는 경우가 대부분입니다. 이럴 때, 어떤 의존성을 가지냐와 서로가 어떻게 실행될 것인지에 대해서 의존성을 달리 주입할 필요가 있습니다. DI 와 IOC 에 관해서 궁금하신분은 아래 velog를 참고 부탁드립니다. 직관적으로 설명이 잘되어있습니다. IoC? DIP? IoC Container? DI? DI Framework? 도대체 그게 뭔데? Mapper Spring boot 에서 RDBS 를 사용하여 MVC 구조에.. [Junit] JunitSoftAssertion 으로 중복 검증 문제 해결하기 JUnitSoftAssertions 라이브러리 TDD 에 대한 강의를 들었을 때, 테스트 코드를 검증 시 한 메서드에 한 가지의 검증을 해야한다는 규칙이 존재하였습니다. 한가지의 규칙만 존재해야하는 이유는, 만약 한 테스트 메서드 내에 3가지의 검증이 존재한다면 첫 번째의 검증이 실패한 경우 두번째와 세번째 테스트에 대해서 검증을 진행할 수 없기 때문입니다. 만약 간단한 프로젝트나 테스트를 구성하고 있는 경우에는 크게 문제가 되지 않을 수 있지만, 테스트 코드의 양이 방대하다면 이러한 문제는 크게 야기될 수 있습니다. 그렇기 떄문에 이러한 검증 문제로 인하여 한 테스트 메서드 내에는 하나의 검증만 진행해야 한다는 규칙이 존재합니다. 하지만, 같은 테스트 코드이지만 검증해야되는 부분만 다르기 때문에 중복된.. [Junit] Test Code 와 TDD 프로그래밍에는 정답이 없습니다. 더 나은 방법이 있다면 언제든 공유 부탁드립니다. Next Step 에서 제공하는 TDD-클린코드 교육 내용 기반으로 작성하였습니다. TEST 코드를 작성해야하는 이유 개발자는 대부분의 시간을 디버깅하는 시간에 투자합니다. 사람이 많아지면 많아질 수록, 기능이 많아지면 많아질 수록 테스트해야되는 코드느 방대해지고, 연관성도 많아지게 됩니다. 작은 하나의 기능의 추가로 인해 전체의 테스트를 다시 해봐야 한다는 것은 엄청난 비용 손해입니다. 하지만, 잘 짜여진 테스트 코드만 있다면 한번만 실행 후 마음 편하게 추가할 수 있습니다. 테스트 코드의 가장 필요한 이유 중 하나는 리펙토링입니다. 리펙토링의 중요한 이유는 다들 알고 있을 것이다. 그 당시에 아무리 좋은 디자인 패턴을 .. 이전 1 다음
