린네의 여행과 개발 일기장

Junit5 확장 모델 살펴보기Junit5 확장 모델은 Extension API라는 단일 개념으로 설명할 수 있다. Extension자체는 내부에 필드나 메서드가 없는 인터페이스인 마커인터페이스일 뿐으로, 해당 인터페이스를 구현하는 클래스에 특별한 의미나 기능을 부여하기 위해 사용한다. 마커 인터페이스 (태그 인터페이스, 토큰 인터페이스)마커 인터페이스는 구현 메서드가 따로 없는 인터페이스로, 해당 인터페이스를 구현하는 클래스에 특별한 의미나 기능을 부여하기 위해 사용한다. 대표적인 사례로는 Serailizable과 Cloneable인터페이스가 있다.  public interface MyMarkerInterface { // No methods }  테스트가 생애 주기를 타는 중에 사전에 정의한 확장 지점..

들어가기전에책에는 빌드 도구로 Gradle 뿐만 아니라 Maven,  IDE는 Eclipse 및 NetBeans 등이 추가로 기술되어 있었지만 책이 집필된 시점과 현재를 비교했을 때 사용률이 월등히 다르기도하고 내가 Gradle, Intellij, Jenkins를 실무에서 쓰고 있기 때문에 나머지 내용은 스킵했다.  이번 장에선 Junit5의 사용법보다는, 각 build Tool 과 IDE를 쓰면 얻을 수 있는 장점정도를 간략하게 정리하려고 한다.  GradleGradle은 프로젝트 설정 파일을 Groovy(그루비:JVM에서 실행될 수 있고 자바 언어와 호환 가능한 객체 지향 프로그래밍 언어)를 기반으로한 DSL로 작성한다. 여기서 DSL이란 Domain Specific language의 준말이다. 번역..

개발환경IDE :  intelliJ FrameWork : springboot 3.xLaunguage : java 17TestTool : Junit5    예제 소스 링크 모의 객체 프레임워크 사용해 보기이전 게시글에서 모의 객체를 밑바닥부터 구현했다. 프레임워크를 사용하면 프로젝트에서 이렇게 모의 객체를 하나하나 새로 생성할 필요 없이 더 쉽게 만들 수 있다. 일반적으로 많이 사용하는 테스트를 위한 프레임워크는 EasyMock, JMock, Mockito 에 대해 간략히 정리하려고 한다.   EasyMockEasyMock은 모의 객체를 사용하기 위한 유용한 클래스를 제공하는 오픈 소스 프레임워크다. 이전 게시글에서 작성한 예제를 EasyMock 프레임워크를 사용해서 리팩터링 해보자. 책에서는 maven ..

간단한 스텁과 모의 객체  리뷰Stub은 특정 상황에서 "결과만" 중요할 때 사용 →  Stub은 메서드가 무엇을 반환하는지에만 집중Mock은 "행위"가 중요할 때 사용 → 특정 메서드가 호출되었는지, 호출 횟수는 몇 번인지 등을 검증할 때 사용스텁을 활용하면 소스코드를 웹 서버, 파일 시스템, 데이터베이스 등의 환경에서 격리하여 단위 테스트를 수행할 수 있다. 그러나 메서드 호출을 다른 클래스로부터 격리하는 것과 같은 세밀한 격리를 위한 테스트는 모의객체(Mock)을 활용하여 효과적으로 수행할 수 있다. 즉, 각 메서드별로 개별적인 단위 테스트를 만들어 개발하는 것이 가능해진다.   모의 객체란?메서드에 집중하는 테스트를 만들 수 있다 → 대상 메서드가 다른 객체를 호출해서 발생하는 부수 효과가 생길일..

스텁(Stub)과 모의 객체(Mock)의 필요성애플리케이션을 개발하다 보면 몇몇 코드 혹은 클래스들은 필수불가결하게 다른 클래스 혹은 특정환경에 의존한다.  특정 런타임 환경에 의존하는 애플리케이션을 위한 단위 테스트를 작성하는 것은 매우 어렵다. 테스트는 안정적이어야 하며 반복적으로 수행하더라도 같은 결과가 나와야 하기 때문이다. 예를 들어, 작성중인 애플리케이션이 타사에서 제공하는 웹 서버에 HTTP통신을 해야 하는 경우, 개발 환경에서는 그런 서버 통신을 하는 것이 사실상 불가능하다. ( 이것은 생각보다 실무에서 빈번하게 발생하는 문제이기도 하다. 개발 환경에 필요한 필수적인 인프라 스트럭처가 구체화되지 않았는데 개발자는 기능 구현을 할 수 있어야 한다. 😳 ) 그러므로 실제 장비 지원 없이도 소..

테스트 커버리지 측정하기 이상적으로는 테스트가 애플리케이션 코드의 100%를 커버하는 것이 좋다. 테스트 커버리지는 그 자체로 코드의 품질을 어느 정도 보증한다. 하지만 절대적이지는 않다. 높은 테스트커버리지가 테스트의 질을 완전히 보장하지는 않기 때문이다. 훌륭한 개발자는 테스트를 실행하여 얻어 낸 기계적인 백분율 수치 이상을 볼 수 있어야 한다.  테스트 커버리지란?테스트 커버리지를 계산하는 데 다양한 지표가 활용될 수 있다. 가장 기본적인 지표는 테스트 묶음을 실행하는 동안 호출되는 애플리케이션의 메서드나 코드 줄의 수를 가지고 나타낸 백분율이다. 혹은 테스트가 호출하는 메서드를 추적해서 집계할 수 있다.  메서드가 어떻게 구현되어 있는지 자세히 알고 있다면 단위 테스트를 작성할 수 있다. 테스트 ..

단위테스트를 하는 이유단위 테스트의 핵심 목표는 애플리케이션이 예상대로 작동하는지 확인하고 사전에 버그를 찾아내는 것이다.단위 테스트가 가지는 장점은 다음과 같다. 장점 기능 테스트만 수행했을 때보다 테스트 커버리지를 높일 수 있다 → 기능 테스트로는 수행하기 어렵거나 불가능한 오류 조건에 대해서도 쉽게 테스트할 수 있다. 팀 생산성이 향상된다 → 다른 컴포넌트가 준비될 때까지 기다리지 않고도 질적으로 우수한 코드를 전달할 수 있다. 기능 테스트는 어느 정도 준비가 되어야 실행 가능한 것과 대비된다 소스를 리팩터링 하거나 변경할 때 개발자에게 확신을 준다 → 어디에 문제가 생기는지 쉽게 알 수 있고 애플리케이션을 일일이 디버깅하지 않아도 된다애플리케이션 기능 구현에 도움을 준다 → 단위 테스트가 너무 길..

Junit4에서 Junit5로 전환하기Junit5는 새로운 아키텍처를 적용한 새로운 패러다임으로  Junit Vintage 테스트 엔진을 활용하여 Junit4에서 Junit5로 전환할 수 있다.Junit Jupiter와 관련한 모든 클래스와 애노테이션은 org.junit.jupiter패키지에서 확인할 수 있고, org.junit 패키지에 Junit4와 관련한 모든 클래스와 애노테이션이 있으므로 클래스 패스에 Junit 5 Jupiter와 Junit4가 모두 존재하더라도 충돌이 발생하지 않는다. ( 예를 들면, Junit4의 @Test 애노테이션은 org.junit.Test에 속해 있고 Junit5의 @Test 애노테이션은 org.junit.jupiter.api.Test에 속해 있어 충돌이 발생하지 않고 ..

소프트웨어 아키텍처의 개념과 중요성 소프트웨어 아키텍처란 소프트웨어 시스템의 기본 구조를 말한다. Junit 5의 아키텍처 또한 Junit4의 단점을 극복하기 위해 만들어졌다. 아키텍처가 전체 시스템에 미치는 중대한 영향을 이해하기 위해 간단한 두 가지 이야기를 소개한다. ( 책 리뷰하면서 핵심만 추리는게 좋다고 생각했는데 찰떡인 비유라 글을 남겨 놓고 싶어서 포함하게 되었다. Junit5의 구조 내용은 하단에 기재했으니 참고 바란다. )  첫 번째 이야기 : 전화번호부전화번호부를 만들어 출간하는 두 회사가 있다.   A, B회사 모두 비슷한 규격과 가격을 가진 전화번호부를 출간했다. 고객들은 두 제품을 모두 같은 가격에 구매 해서 사용했기 때문에 어떤 전화번호부가 더 좋은지에 대해 알 수 없었다. 그러..

개발환경IDE :  intelliJ FrameWork : springboot 3.xLaunguage : java 17TestTool : Junit5   예제 소스 링크   HamcrestMatcher 사용하기Hamcrest 라이브러리는 테스트 프레임워크는 아니지만, 간명한 매치 규칙을 선언하는데 도움을 준다. 매치 규칙은 다양한 상황에 쓰일 수 있지만 특히 단위 테스트에서 유용하게 쓰일 수 있다. 매처(Matcher)는 제약(constraint) 혹은 술어(predicate)로 표현되는데 이것을 사용하여 테스트 메서드 안에 있는 복잡한 단언문을 간명하게 처리할 수 있다. 아래는 중복 조건을 검사하는 단언문을 assertThat을 통해 처리하는 예제이다. @Test @DisplayName("Ham..