다음은 일반적으로 인기있는 7가지 Unit Test 명명 규칙이다. 1. MethodName_StateUnderTest_ExpectedBehavior 예제: isAdult_AgeLessThan18_False withdrawMoney_InvalidAccount_ExceptionThrown admitStudent_MissingMandatoryFields_FailToAdmit 2. MethodName_ExpectedBehavior_StateUndertest 예제: isAdult_False_AgeLessThan18 withdrawMoney_ExceptionThrown_InvalidAccount admitStudent_FailToAdmit_MissingMandatoryFields 3. test[Feature be..

단위 테스트 JPAQueryFactory에 대해 mocking하기 ● 단위테스트할 함수 @Service @RequiredArgsConstructor @Transactional public class QueryFactoryTestService { private final JPAQueryFactory queryFactory; public boolean queryFactoryTest(int companyId) { return getFetchFirstCompany(companyId) != null; } private Company getFetchFirstCompany(int companyId) { return queryFactory .select(company) .from(company) .innerJoin(a..

● Mockito로 테스트코드를 작성하는 이유 @SpringBootTest 로 테스트코드를 작성하다보며 시간이 지날수록 프로젝트의 덩치가 커지면서 테스트코드를 실행하는데 굉장히 많은 시간이 걸리며 빌드시에도 많은 시간이 소요된다. 따라서 단위 테스트단위로 코드 작성시에는 mockito를 이용하여 테스트코드를 짜는것이 유용하다고 판단된다. @RunWith(MockitoJUnitRunner.class) @ExtendWith(MockitoExtension.class) 모두 Mockito의 Mock 객체를 사용하기 위한 Annotation이다 @RunWith는 junit4 @ExtendWith 는 junit5 사용시 정의하면 된다. ● Mockito를 이용한 예제 import java.util.Optional;..

● @SpringBootTest 및 test Slices(Auto-configuration Annotations) @SpringBootTest는 Spring Main Application(@SpringBootApplication)을 실행할때와 동일한 모든 Bean을 스캔하여 mock bean을 생성합니다. 통합테스트 슬라이스테스트(단위테스트) 어노테이션 @SpringBootTest @DataCassandraTest @DataJdbcTest @DataJpaTest @DataLdapTest @DataMongoTest @DataNeo4jTest @DataR2dbcTest @DataRedisTest @JdbcTest @JooqTest @JsonTest @RestClientTest @WebFluxTest @Web..

개요 테스트코드의 중요성은 해당 블로그를 읽는 분이라면 모두 알고 있을 것이다. 나도 잘 알고 있지만, 정확한 사용법을 몰라 매번 @SpringBootTest 통합테스트로만 테스트코드를 작성하였다. 이렇게만 작성하면, 테스트코드 속도가 느려지면서 테스트 코드를 사용하지 않게 될 것이다. 그렇기 때문에 상황에 맞는 최소한의 사이즈로 테스트를 하는게 좋다고 생각한다. 해당 포스팅에서 테스트 코드 작성법과 JUnit5에 추가된 내용들을 정리해보려한다! ( 테스트코드 작성방법은 뭔가 매번 까먹었다... ) 1. 통합 테스트 - @SpringBootTest 모든 빈을 등록하여 테스트를 진행한다. 그렇기 때문에 애플리케이션 규모가 크면 테스트가 많이 느려진다. ( 현업에서 테스트 코드를 돌려보셨다면 공감할거에요ㅠㅠ..

작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야한다. 코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야 한다. 이것이 테스트 주도 개발(TDD, Test Driven Development)에 기반을 둔 단위 테스트 전략의 핵심이다. TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다. 단위 테스트는 종종 잘 선별한 후 한쪽에 치워 놓고 나중에 반영하려는 코드가 될 수 있는데, 단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다. 따라서 TDD를 채택하면 소프트웨어 설계는 달라지고, 아마 훨씬 더 좋은 설계의 코드가 될 것이다. TDD의 주된 이익 단위 테스트를 사후에 작성하..

단위 테스트, 혹은 여느 테스트 코드를 작성하는 일은 상당한 투자와 비용이 드는 작업이다. 하지만 테스트는 프로덕 코드의 결함을 최소화하고 리팩토링으로 프로덕 시스템을 깔끔하게 유지시켜준다. 그렇지만 역시 지속적인 비용을 의미하는 것은 부정할 수 없다. 시스템이 변경됨에 따라 테스트 코드도 다시 들여다보아야한다. 때때로 변경 사항들을 생겨나고 그 결과로 수많은 테스트 케이스가 깨져 테스트 코드를 수정해야 한다. 그렇다면 만약 테스크 코드가 굉장히 복잡하고 지저분하다면 어떻게 될까? 새로운 변경사항이 생겨날 때마다 테스트 코드를 수정하는 일은 더욱 더 힘든 일이 될 것이다. 그래서 이번 포스팅에서는 테스트 코드를 리팩토링하여 유지보수가 쉬운 테스트 코드를 만드는 것을 간단하게 소개할 것이다. 이번 포스팅의..

이번 포스팅에서는 목(Mock) 객체를 사용하여 테스트하기 힘든, 혹은 외부환경과 의존성을 끊는 테스트를 하기 위한 방법을 간단하게 다루어 볼 것이다. 여기서 다루는 목(Mock)객체는 정말 단순한 수준의 예제이다. 결과적으로 이번 포스팅의 목적은 목객체는 무엇이고 왜 사용하는 지에 대한 내용이 될 것 같다. 지금 진행할 예제는 크게 코드 내용 자체를 알필요?는 없을 것 같다. 이 말은 우리가 개발하며 테스트를 작성할 때, 코드의 내용을 몰라도 된다는 말이 아니다. 테스트 작성은 당연히 코드의 내용을 빠삭히 알고 작성해야 하는 테스크이기 때문이다. 필자가 말하는 "알 필요는 없다"라는 것은 이번 포스팅은 독자들과 같이 애플리케이션을 개발하며 테스트를 작성하는 포스팅이 아니고 어느 순간에 목객체를 사용해야..

우리가 직접 작성한 코드라고 하더라도 단순히 메서드, 클래스 코드를 보면서 숨어 있는 버그를 찾아내는 것은 거의 불가능하다. 물론 코드를 살펴보는 것도 하나의 버그를 찾아내는 행위이긴 하다. 하지만 효율적인 단위 테스트를 통해 숨어있는 버그를 찾아내는 것이 훨씬 더 효율적인 방안일 듯하다. 그렇다면 테스트를 수행하는 것 만큼 중요한 것은 무엇일까? 아니, 올바르고 더 효율적인 테스트를 수행하기 위해 받침이 되는 행위가 무엇일까? 바로 테스트 케이스! 무엇을 테스트 해야할까를 고민하는 것은 아주 중요하고 여기서 그치는 것이 아니라 정말 중요한 테스트 케이스를 찾아 테스트에 적용해야한다. Right-BICEP는 우리에게 무엇을 테스트할지에 대해 쉽게 선별하게 한다. Right : 결과가 올바른가? B : 경..

이번 포스팅에서 다루어볼 예제는 JUnit 3단계 준비,실행,단언 단계중 "단언"의 몇 가지 예제를 다루어볼 것이다. JUnit에 내장된 단언 이외에 햄크레스트(Hamcrest) 라이브러리를 활용한 단언 몇가지도 다루어볼 것이다. JUnit Assert JUnit에서 assert는 테스트에 넣을 수 있는 정적 메서드 호출이다. 각 Assert 구문은 어떤 조건이 참인지 검증하는 방법이다. 단언한 조건이 참이 아니면 테스트는 그 자리에서 멈추고 실패한다. JUnit은 크게 두 가지 Assert 스타일을 제공한다. 전통적인 스타일의 Assert는 JUnit의 원래 버전에 포함되어 있으며, 새롭고 좀 더 표현력이 좋은 햄크레스트라고 알려진 Assert 구문도 있다. 두 가지 Assert 스타일은 각자 다른 환..