전체 글
[TDD] 테스트 가능한 설계
테스트 어려운 코드 모든 코드를 테스트할 수 있는 것은 아니다. 개발을 진행하다 보면 테스트하기 어려운 코드를 만나게 된다. 이를 살펴보고 이를 어떻게 테스트 가능한 코드로 변경하는 지 파악한다. 하드 코딩된 경로 Path path = Paths.get("D:\\\\data\\\\pay\\\\cp0001.csv) 하드 코딩된 경로뿐만 아니라 하드코딩된 IP 주소, 포트 번호도 테스트를 어렵게 만든다. 의존 객체를 직접 생성 private PayInfoDao payInfoDao = new PayInfoDao(); 테스트를 어렵게 만드는 또 다른요인은 의존 대상을 직접 생성하고 있다는 점이다. 해당 코드를 테스트 하려면 PatInfoDao가 올바르게 동작하는데 필요한 모든 환경을 구성해야한다. DB를 준비해..
[TDD] 대역
외부 요인은 테스트 작성을 어렵게 만들 뿐만 아인라 테스트 결과도 예측할 수 없게 만든다. Double 영어로 된 테스트 관련 글을 읽으면 test double이란 표현이 자주 나오는데 여기서 double은 본 장에서 설명하는 대역에 해당한다. 즉, test double은 테스트에서 진짜 대신 사용할 대역을 의미한다. 대역의 종류 대역종류 설명 대역종류 설명 스텁(Stub) 구현을 단순한 것으로 대체한다. 테스트에 맞게 단순히 원하는 동작을 수행한다. 가짜(Fake) 제품에는 적합하지 않지만, 실제 동작하는 구현을 제공한다. DB대신에 메모리를 이용해서 구현한 것과 같다. 스파이(Spy) 호출된 내역을 기록한다. 기록한 내용은 테스트 결과를 검증할 때 사용한다. 스텁이기도 하다. 모의(Mock) 기대한대..
[TDD] 테스트 코드의 구성
이번 주차 블로그 글은 GDSC에서 제가 직접한 글을 첨부하도록 하겠습니다. [TDD] 5. 테스트 코드의 구성 작성자 : 한규범 기능에서의 상황 주어진 상황에 따라 기능 실행 결과는 달라진다. 이는 테스트 코드 구조에도 영향을 주는데 이에 관한 내용을 이어서 살표보자. 상황 찾기 노련한 개발자는 어 gdsc-mju.tistory.com Reference. 테스트 주도 개발 시작하기 - YES24 TDD(Test-Driven Development)는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그다음에 구현한다. 구현 코드가 없는데 어떻게 테스트할 수 있을까? 여기 www.yes24.com
[TDD] JUnit5 기초
Junit5 모듈 구성 Junit5는 크게 세 개의 요소로 구성되어 있다. JUnit 플랫폼: 테스팅 프레임워크를 구동하기 위한 런처와 테스트 엔진을 위한 API를 제공한다. JUnit 주피터(Jupiter): JUnit5를 위한 테스트 API와 실행 엔진을 제공한다. JUnit 빈티지(Vintage): Junit 3과 4로 작성된 테스트를 Junit5 플랫폼에서 실행하기 위한 모듈을 제공한다. Junit5 는 테스트를 위한 API로 주피터 API를 제공한다. @Test 애노테이션과 테스트 메서드 JUnit 모듈을 설정했다면 JUnit을 이용해서 테스트 코드를 작성하고 실행할 수 있다. Junit의 Assertions 클래스는 assertEquals() 메서드와 같이 값을 검증하기 위한 목적의 다양한 정..
[TDD] 기능 명세 ∙ 설계
기능 명세 개발자는 코드를 작성하고 빌드하여 이를 사용자가 사용할 수 있게 배포한다. 설계는 기능 명세로부터 시작한다. 스토리보드를 포함한 다양한 형태의 요구사항 문서를 이용해서 기능 명세를 구체화한다. 기능 명세를 구체화하는 동안 입력과 결과를 도출하고 이렇게 도출한 기능 명세를 코드에 반영한다. 기능 명세의 입력과 결과를 코드에 반영하는 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정된다. 설계 과정을 지원하는 TDD TDD에서 가장 중요한 것을 테스트 코드를 먼저 작성한다는 점이다. 리턴 타입과 파라미터 타입에 대해서 고민은 곧 설계 과정이다. 타입의 이름을 정의하고 타입이 제공할 기능을 결정하는 것은 기본 적인 설계 행위이다. TDD 자체가 설계는 아니지만, TDD를 하다 보면 테스트 코드..