개발로 자기개발 개발로 자기개발

JUnit4의 경우  runner와 rule을 사용하여 테스트를 확장할 수 있었다.JUnit5 확장 모델은 Extension API라는 단일 개념으로 설명할 수 있다.Extension 자체는 내부에 필드나 메서드가 없는 인터페이스인 마커 인터페이스일 뿐이다.  마커 인터페이스?더보기태그 인터페이스 또는 토큰 인터페이스라고도 불리며 구현 메서드가 따로 없는 인터페이스로, 해당 인터페이스를 구현하는 클래스에 특별한 의미나 기능을 부여하기 위해 사용한다. 대표적인 사례로 Serializable, Cloneable 인터페이스가 있다. Serializable 인터페이스에는 구현 메서드가 없지만 해당 인터페이스를 구현하는 클래스는 직렬화 속성을 갖는다는 것을 나타낼 수 있다. * 사용 목적JUnit5 extensi..

일반적으로 모의객체를 활용한 단위 테스트는 컨테이너에서 제공하는 객체는 모의하기 어렵고, 테스트를 작성하기 복잡하다는 한계가 있다.ex) HttpConnection, HttpServletRequest, HttpSession 등 컴포넌트와 컨테이너컴포넌트는 애플리케이션 또는 애플리케이션의 일부를 말한다. 컨테이너는 컴포넌트가 실행되고 있는 격리된 공간을 말한다. 컨테이너는 생애주기, 보안, 트랜잭션 등 컴포넌트를 위한 서비스를 제공한다.ex) JSP의 컨테이너 Tomcat, Jetty 모의객체를 사용하지 않고 실제 컨테이너에서 필요한 객체와 메서드에 직접 접근하여 테스트를 배포하고 실행하는 방식을 컨테이너를 활용한 테스트라고한다. 컨테이너를 활요한 테스트 구현 전략서버측과 클라이언트측 두가지 접근 방식으로..

모의 객체를 사용하기 위한 유용한 클래스를 제공하는 오픈 소스 프레임워크- EasyMock- JMock- Mockito EasyMockmaven org.easymock easymock 5.4.0 gradletestImplementation group: 'org.easymock', name: 'easymock', version: '5.4.0'  EasyMock을 활용한 TestAccountServiceimport org.junit.jupiter.api.AfterEach;import org.junit.jupiter.api.BeforeEach;import org.junit.jupiter.api.Test;import static org.easymock.EasyMock.*;import static..

테스트를 단순하게 만들 목적으로 런타임 코드를 변경해서는 안된다는 통념이 있다. 그러나 이는 옳지않다.단위 테스트는 런타임 코드의 가장 중요한 클라이언트이며, 코드가 테스트하기에 충분히 유연하지않다면 코드를 수정하는 것은 당연하다. 다음 예제에서 문제를 찾아보자.import org.apache.commons.logging.Log;import org.apache.commons.logging.LogFactory;import java.util.PropertyResourceBundle;import java.util.ResourceBundle;public class DefaultAccountManager1 implements AccountManager { private static final Log logg..

모의객체를 사용하면 가능한 한 가장 세밀한 수준에서 테스트를 실행할 수 있다.각 메서드별로 개별적인 단위 테스트를 만들어 개발하는 것이 가능하다. 모의 객체란?모의 객체는 비즈니스 로직의 일부만을 다른 부분과 격리해 테스트하는데 적합하다. 모의 객체는 테스트 대상인 메서드가 사용하는 객체를 대체하여 테스트 대상 메서드는 다른 객체와 격리되는 효과가 생긴다. 다른 클래스나 메서드와 격리된 상태에서 테스트를 하면 큰 이점이 있다. 격리된 상태에서의 테스트는 다른 부분의 코드가 완성되는 것을 기다리지 않고 한 부분의 코드를 단위 테스트하는 데 큰 도움이 된다.모의 객체를 사용할 때의 가장 큰 장점은 메서드에 집중하는 테스트를 만들 수 있다는 것이다. 모의 객체를 사용하면 테스트 대상 메서드가 다른 객체를 호출..

애플리케이션을 개발하다보면 몇몇 코드가 다른 클래스나 외부 환경에 의존하는 경우가 있다.특정한 런타임 환경에 의존하는 애플리케이션을 위한 단위 테스트를 작성하기는 매우 어렵다. 실제로 필요한 환경을 테스트의 일부로 구성하여 테스트를 수행하는것은 효과적이나 이는 항상 가능한 방법이 아니다.실제 장비 지원 없이도 소스 코드에 대한 테스트를 지속적으로 작성하고 실행할 수 있도록 가짜 객체를 활용해야 하는데, 방법은 스텁과 모의객체를 활용하는 것 두 가지가 있다. 이번 글에서는 스텁을 활용한 방법을, 다음 글에서는 모의 객체를 활용하는 방법을 정리하고자한다. 스텁호출자를 실제 구현 코드에서부터 격리하기 위해 실제 코드 대신 런타임에 동작하는 코드를 말한다. 단순하게 만든 스텁으로 실제 코드의 복잡한 기능을 대체..

테스트 품질을 검증하기 위해 테스트 커버리지 도구를 이용하여 테스트가 커버한 코드와 커버하지 못한 코드가 얼마나 되는지 확인하고, 해당 테스트가 얼마나 유용한지 계산해보자.그리고 품질에 초점을 둔 소프트웨어 개발 프로세스인 TDD와 BDD에 대해 알아보자. 1. 테스트 커버리지 측정하기테스트 커버리지는 그 자체로 코드의 품질을 어느정도 보장한다. 하지만 높은 테스트 커버리지가 테스트의 질을 보장하지는 않는다. 훌륭한 개발자는 테스트를 실행하여 얻어 낸 기계적인 백분율 수치 이상을 볼 수 있어야 한다. 1-1. 테스트 커버리지란 ?테스트 커버리지를 계산하는 데 다양한 지표를 사용할 수 있다. 가장 기본적인 지표는 테스트 묶음을 실행하는 동안 호출되는 애플리케이션의 메서드나 코드 줄의 수를 가지고 나타낸 백..

단위 테스트를 하는 이유단위 테스트의 핵심 목표는 애플리케이션이 예상대로 작동하는지 확인하고 사전에 버그를 찾아내는 것.기능 테스트로도 작동을 확인하고 버그를 찾을 수 있지만, 단위 테스트를 수행했을 때 다음과 같은 장점이 있다. - 기능 테스트만 수행했을 때보다 테스트 커버리지를 높일 수 있다.: 단위 테스트는 기능 테스트로는 수행하기 어렵거나 불가능한 오류 조건에 대해서도 쉽게 테스트 할 수 있다. - 팀 생산성이 향상된다.: 단위 테스트를 활용하면 다른 컴포넌트가 준비될 때까지 기다리지 않고 질적으로 우수한 코드를 전달 할 수 있다.반면 기능 테스트는 테스트를 실행 하기 전에 전체 애플리케이션 혹은 상당 부분이 준비되어 있어야한다. - 회귀를 사전에 발견하여 디버깅 작업을 줄일 수 있다.: 단위 테..