Overview 팀에서 초기부터 Junit5를 적용하다보니, MockitoExtension을 제대로 제공받지(?) 못했다. 그래서 오픈소스로 공개되어 있던 것 중에 하나를 그냥 복사해서 프로젝트내에 class를 두고 사용했다. 그러다가 최근에 SpringBoot에서 Junit5를 지원1 해주는 김에 SpringBoot로 의존성 관리하도록 바꿨다. 그랬더니 자연스럽게 Mockito 버전도 올라가고, MockitoExtension이 제공되고… 더 보기 »Mockito에서 Multi-Stubbing 적용하기
테스트를 작성하려고 했더니, 아래와 같은 오류가 발생했다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
java.lang.IllegalStateException: Failed to load ApplicationContext at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:125) at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:108) at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:118) at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83) at org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener.prepareTestInstance(SpringBootDependencyInjectionTestExecutionListener.java:43) at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:246) at org.springframework.test.context.junit.jupiter.SpringExtension.postProcessTestInstance(SpringExtension.java:97) at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeTestInstancePostProcessors$5(ClassBasedTestDescriptor.java:337) at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.executeAndMaskThrowable(ClassBasedTestDescriptor.java:342) at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeTestInstancePostProcessors$6(ClassBasedTestDescriptor.java:337) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:313) Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'io.github.freeism.service.FooService' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {} at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1662) at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1221) at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1175) at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:857) at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:760) ... 82 more |
처음에는 왜 Bean을 인식하지 못하는지, 해당 Bean의 선언과 Configuration에서 Bean Scan Scope를 확인했는데 모두 정상이었다. 나중에 알게된 사실1 인데, 같이 일하는 사람과 서로 테스트의 방식이 달랐던 것이다. 평상시에 내가 제일 즐겨하는 controller… 더 보기 »@SpringBootTest + mockMvc vs @WebMvcTest
그동안에 테스트를 진행할 때, 테스트의 분기와는 관계가 없는 어쩌면 자연스럽게 처리되어야 하는 Stub에 대해서는 @BeforeEach문에 적는 경우가 많았다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@ExtendWith(MockitoExtension.class) class FooServiceTest { @Mock private FooRepository fooRepository; @BeforeEach void beforeEach() { givenActionFooEntitySaved(); } private void givenActionFooEntitySaved() { when(fooRepository.save(ArgumentMatchers.any(FooEntity.class))).thenAnswer(invocation -> invocation.getArgument(0)); } } |
Spring Context를 사용하지 않는 이상, @Autowired된 Bean들은 모두 Mock으로 생성을 해야 되는데, 테스트의 흐름과 관계없이 그냥 자연스럽게 되는 경우 (위의 케이스의… 더 보기 »Mockito UnnecessaryStubbingException
시작 JUnit5에서 개인적으로 가장 많이 활용하고 있는 기능은 @Nested 이다. 예전 포스트라서 약간 view가 깨지는 부분도 있지만 이런 테스트케이스는 어떨까?(또는 옛날사이트)에서도 많이 고민했던 부분을 JUnit5에서 공식적으로 해결해주었다. 소스 코드 간단한 분기문이 있는 코드를 만들어본다. 실제 서비스에서는 훨씬 복잡한 코드가… 더 보기 »JUnit5 @Nested, @DisplayName 활용
예전에 PowerMock사용법(final class의 테스트)라는 제목으로 블로깅을 한 적 있다. 그게 2011년 7월이니까 근 6년 가까이 PowerMock을 사용할 일이 생기지 않았다. 단순히 SpringRunner나 Mockito만으로도 충분한 테스트를 만들 수 있었다. 그런데 최근에 작업중인 프로젝트에서 시간에 의존하는 테스트가 존재했다. 그래서 평소에는 Ignore시키고 있다가… 더 보기 »PowerMock 예제
예전부터 한글로 테스트코드를 작성하는 것에 대한 얘기를 많이 들었습니다. 사실 저는 한글로 코드를 짜는 것에 대해서 거부했었던 사람중에 하나입니다. (심지어 주석마저도 영어로 쓰자…라는 주의였…) 그러다가 갑자기 뽐뿌가 와서 한글로 한 번 변환해 봤습니다. 생각보다 나쁘지 않다는 느낌이 들었습니다. 처음에는 조금… 더 보기 »내가 만드는 테스트코드 그리고 한글코드
이클립스를 새로 설치하거나 하면, 꼭 한번씩은 하는 설정들인데.. 내가 정리하기도 귀찮고해서-ㅅ- 다른 분이 잘 정리해놓은 것 링크를 걸어둔다. http://blog.benelog.net/2688165
때론 너무 당연한 얘기임에도 불구하고, 권위자가 얘기하면 크게 와닿는 경우가 있다. 이 글이 그렇다. http://martinfowler.com/bliki/TestCoverage.html 요약하면, 테스트 커버리지는… 단순히 테스트 되지 않은 영역을 탐지하는데 사용할 뿐이지, 테스트 커버리지 자체가 코드의 품질을 나타내주지 않는다는 것. 그리고 개발자가 커버리지를 올리기 위해서 노력하는… 더 보기 »테스트 커버리지에 대한 단평
테스트 케이스가 뭔지도 모르던 신입사원이 이제 TDD 신봉자가 되어 버렸다. 오늘 코드 중에 오류가 있어서 테스트 케이스를 봤는데, if ( A == X ) … else if ( B == Y || C == Z) … else … 위와 같은… 더 보기 »테스트 케이스 만들면서 주절주절