추가 적립 안내

예제를 통해 단위 테스트를 배운다!

『NET 예제로 배우는 단위 테스트』는 .NET 환경의 개발자들이 단위 테스트를 할 때 알아야 할 모든 것을 다룬다. 단위 테스트부터 통합 테스트까지, 필요한 도구와 테스트 작성/관리 방법에 관한 모든 노하우를 일목요연하게 설명한다. 또한, 실전에서 단위 테스트를 도입하며 겪게 되는 문제와 이를 해결하는 방법 그리고 조직을 어떻게 설득하고 변화시킬 수 있는지를 알려준다. 이 책을 통해 읽기 쉽고 신뢰할 수 있는 단위 테스트를 만들게 되어, 디버깅과 통합에 드는 시간을 크게 줄일 수 있다.

팀에서 단위 테스트를 도입하려고 준비 중이거나, 이미 도입했지만 단위 테스트 때문에 코드가 더 복잡해지고 있다면?

이 책은 단위 테스트를 할 때 알아야 할 모든 것을 알아본다.
단위 테스트부터 통합 테스트까지, 필요한 도구와 테스트 작성/관리 방법에 관한 모든 노하우를 일목요연하게 설명한다. 또한, 실전에서 단위 테스트를 도입하며 겪게 되는 문제와 이를 해결하는 방법 그리고 조직을 어떻게 설득하고 변화시킬 수 있는지를 알려준다. .NET 예제 코드를 기반으로 설명하고 있긴 하지만, .NET이 아닌 환경이라 하더라도 이 책에 소개된 기법들을 어렵지 않게 적용할 수 있을 것이다.
이 책과 함께, 읽기 쉽고 신뢰할 수 있는 단위 테스트가 디버깅·통합 단계를 어떻게 바꿔 놓는지 경험해 보자.

- NUnit, Rhino Mock, Typemock 등의 사용법
- 목(mock)과 스텁(stub) 그리고 자동화된 프레임워크
- 읽기 쉬운 단위 테스트 작성 노하우
- 테스트를 자동화 빌드에 통합하는 기법
- 단위 테스트 도입시 겪는 문제와 해결책
- 기존 코드에 단위 테스트 적용하기
- 단위 테스트를 위한 툴 소개

옮긴이의 글
추천의 글
지은이의 글
감사의 글
이 책에 관해

1부 시작

1장 단위 테스트의 기본
1.1 단위 테스트 - 일반적인 정의
1.1.1 ‘좋은’ 단위 테스트를 작성하는 일이 왜 중요할까
1.1.2 우리는 모두 단위 테스트를 작성해 보았다. (어느 정도)
1.2 좋은 단위 테스트의 속성
1.3 통합 테스트
1.3.1 자동화된 단위 테스트에 비할 때 통합 테스트의 단점
1.4 좋은 단위 테스트란 무엇인가
1.5 간단한 단위 테스트의 예
1.6 테스트 주도 개발
1.7 요약

2장 첫 단위 테스트
2.1 단위 테스트용 프레임워크
2.1.1 단위 테스트 프레임워크가 제공하는 것들
2.1.2 xUnit 프레임워크
2.2 LogAn 프로젝트 소개
2.3 NUnit 시작
2.3.1 NUnit 설치
2.3.2 솔루션 열기
2.3.3. 코드에서 NUnit 애트리뷰트 사용
2.4 첫 테스트 작성
2.4.1 Assert 클래스
2.4.2 NUnit으로 첫 테스트 실행
2.4.3 코드 수정과 테스트 통과
2.4.4 붉은색에서 녹색으로
2.5 NUnit에서 제공하는 애트리뷰트
2.5.1 설정과 해체
2.5.2 기대하는 예외 검사
2.5.3 테스트 무시
2.5.4 테스트 카테고리 설정
2.6 상태 간접 테스트
2.7 요약

2부 핵심 테크닉

3장 스텁을 이용한 의존성 분리
3.1 스텁 개요
3.2 LogAn의 파일시스템 의존성 파악
3.3 LogAnalyzer를 더 쉽게 테스트
3.4 우리 설계를 좀더 테스트가 용이하도록 리팩터링
3.4.1 하부 구현을 교체할 수 있도록 인터페이스를 추출
3.4.2 테스트 대상 클래스에 스텁 구현 주입
3.4.3 생성자 레벨에서 인터페이스 받기 (생성자 주입)
3.4.4 프로퍼티 get 또는 set을 이용하여 인터페이스 받기
3.4.5 메서드 호출 직전에 스텁 얻어내기
3.5 리팩터링 기법의 다양한 변형
3.5.1 추출 및 재정의를 사용하여 스텁 결과를 생성
3.6 캡슐화 문제의 극복
3.6.1 internal 및 [InternalsVisibleTo]의 사용
3.6.2 [Conditional] 애트리뷰트의 사용
3.6.3 조건부 컴파일에 #if 및 #endif 사용
3.7 요약

4장 목 객체를 이용한 상호 작용 테스트
4.1 상태 기반 테스트 대 상호작용 테스트
4.2 목과 스텁의 차이점
4.3 간단히 수작업으로 만드는 목 예제
4.4 목과 스텁을 함께 사용하기
4.5 테스트당 하나의 목
4.6 스텁 사슬 : 목이나 다른 스텁을 만들어 내는 스텁
4.7 수작업으로 만든 목과 스텁의 문제점
4.8 요약

5장 격리(목 객체) 프레임워크
5.1 격리 프레임워크를 쓰는 이유
5.2 페이크 객체의 동적 생성
5.2.1 여러분의 테스트에 Rhino Mocks를 도입하기
5.2.2 직접 작성한 목 객체를 동적 객체로 대체하기
5.3 엄격한 목 대 엄격하지 않은 목
5.3.1 엄격한 목
5.3.2 엄격하지 않은 목
5.4 페이크 객체에서 반환 값 받기
5.5 격리 프레임워크를 이용한 지능적인 스텁 생성
5.5.1 Rhino Mocks를 이용한 스텁 생성
5.5.2 동적 스텁 및 목을 함께 사용하기
5.6 목과 스텁에 대한 매개변수 제약
5.6.1 문자열 제약을 가진 매개변수를 확인하기
5.6.2 제약 사항을 이용한 매개변수 객체의 프로퍼티 확인
5.6.3 매개변수 검증을 위한 콜백 실행하기
5.7 이벤트 관련 활동에 대한 테스트
5.7.1 이벤트가 구독되는지 테스트하기
5.7.2 목 및 스텁에서 이벤트를 발생시키기
5.7.3 이벤트가 발생했는지 테스트하기
5.8 격리를 위한 준비-작용-assert 문법
5.9 오늘날의 .NET용 격리 프레임워크
5.9.1 NUnit.Mocks
5.9.2 NMock
5.9.3 NMock2
5.9.4 Typemock Isolator
5.9.5 Rhino Mocks
5.9.6 Moq
5.10 격리 프레임워크의 장점
5.11 격리 프레임워크를 사용할 때 조심해야 할 함정
5.11.1 가독성이 형편없는 테스트 코드
5.11.2 잘못된 것을 확인하는 일
5.11.3 테스트당 둘 이상의 목을 사용하는 일
5.11.4 테스트를 필요 이상으로 구체화하는 일
5.12 요약

3부 테스트 코드 작성

6장 테스트 계층화 및 조직화
6.1 자동화된 빌드에서 자동화된 테스트 실행
6.1.1 자동화된 빌드 해부
6.1.2 빌드 촉발 및 계속적인 통합
6.1.3 자동화된 빌드의 종류
6.2 속도와 종류에 따라 테스트 계획 세우기
6.2.1 단위 테스트와 통합 테스트 분리하게 만드는 인적 요소
6.2.2 안전 녹색 지대
6.3 테스트를 소스 컨트롤의 일부로 만들기
6.4 테스트 클래스와 테스트 대상 코드 대응시키기
6.4.1 테스트를 프로젝트에 대응시키기
6.4.2 테스트를 클래스에 대응시키기
6.4.3 테스트를 특정 메서드에 대응시키기
6.5 응용 프로그램을 위한 테스트 API 만들기
6.5.1 테스트 클래스 상속 패턴
6.5.2 유틸리티 클래스와 메서드 생성
6.5.3 여러분의 API를 개발자들에게 알리기
6.6 요약

7장 좋은 테스트의 특징
7.1 신뢰할 수 있는 테스트 작성하기
7.1.1 언제 테스트를 제거하거나 수정할지 결정하기
7.1.2 테스트에서 로직을 피하기
7.1.3 한 가지만 테스트하기
7.1.4 쉽게 실행할 수 있게 하기
7.1.5 코드 커버리지 확보하기
7.2 관리하기 쉬운 테스트 작성하기
7.2.1 private이나 protected 메서드 테스트하기
7.2.2 중복 제거하기
7.2.3 관리 용이한 방식으로 설정 메서드 사용하기
7.2.4 테스트 격리 실시하기
7.2.5 다중 assert 피하기
7.2.6 동일한 객체의 여러 측면을 테스트하는 일을 피하기
7.3 읽기 쉬운 테스트 작성하기
7.3.1 단위 테스트 이름 짓기
7.3.2 변수 이름 짓기 규칙
7.3.3 의미 있는 assert 수행하기
7.3.4 assert와 동작을 분리하기
7.3.5 설정과 해체
7.4 요약

4부 설계 및 공정

8장 단위 테스트의 조직 내 통합
8.1 변화를 주도하는 사람이 되기 위한 절차
8.1.1 어려운 질문에 대한 대답을 미리 준비하라
8.1.2 내부 사람부터 확신시켜라 - 옹호론자와 반대론자
8.1.3 가능성 높은 시작 지점을 파악하라
8.2 성공에 이르는 길
8.2.1 게릴라식 추진 (상향식)
8.2.2 관리자를 확신시키기 (하향식)
8.2.3 외부 옹호론자를 확보하기
8.2.4 일의 진행 상황을 공개하기
8.2.5 구체적인 목표를 지향하기
8.2.6 장애물이 있을 수도 있음을 깨닫기
8.3 실패에 이르는 길
8.3.1 추진력 부족
8.3.2 행정적인 지원 부족
8.3.3 좋지 못한 구현과 첫 인상
8.3.4 팀 차원의 지원 부족
8.4 난해한 질문과 그에 대한 답변
8.4.1 이 작업을 추가하는 데 얼마나 시간이 필요한가요
8.4.2 이것을 도입하면 제 QA 업무가 필요없어지지 않나요
8.4.3 이것이 실제로 돌아간다고 어떻게 알 수 있나요
8.4.4 단위 테스트가 도움이 된다는 증거가 있나요
8.4.5 왜 아직도 QA 부서에서 버그가 발견되나요
8.4.6 테스트를 만들지 않은 코드가 매우 많은데, 어디서 시작해야 하나요
8.4.7 여러 언어를 사용하는데, 단위 테스트를 적용 가능한가요
8.4.8 소프트웨어와 하드웨어를 함께 개발하는 경우에는 어떻게 해야 하나요
8.4.9 테스트 자체에 버그가 없다고 확신할 수 있나요
8.4.10 디버거에 따르면 제 코드가 문제없다고 나오는데, 왜 테스트가 필요하죠
8.4.11 반드시 TDD 방식으로 코딩해야 하나요
8.5 요약

9장 레거시 코드 다루기
9.1 어디부터 테스트를 추가해 나갈 것인가
9.2 전략의 선택
9.2.1 쉬운 것을 먼저 하는 전략의 장단점
9.2.2 어려운 것을 먼저 하는 전략의 장단점
9.3 리팩터링에 앞서 통합 테스트 작성하기
9.4 레거시 코드 단위 테스팅을 위한 중요한 툴
9.4.1 Typemock Isolator를 이용하여 의존성을 쉽게 격리하기
9.4.2 Depender를 이용해 테스트 용이성 문제를 찾아보기
9.4.3 Java 레거시 코드에 대하여 JMockit 사용하기
9.4.4 Java 코드 리팩터링 작업에 Vise 사용하기
9.4.5 리팩터링에 앞서 FitNesse를 이용해 수용 테스트 해보기
9.4.6 마이클 페더스가 저술한 레거시 코드에 관한 책을 읽어 보기
9.4.7 NDepend를 이용해서 제품 코드 조사하기
9.4.8 ReSharper를 이용해 제품 코드 탐색 및 리팩터링하기
9.4.9 Simian을 이용해 중복 코드 (및 버그) 탐지하기
9.4.10 Typemock Racer를 이용해 스레드 문제 찾아내기
9.5 요약

부록 A 설계와 테스트 용이성
A.1 설계할 때 테스트 용이성에 대해 왜 신경 써야 하는가
A.2 테스트 용이성을 위한 설계 목표
A.3 테스트 용이성을 위한 설계의 장단점
A.4 테스트 용이성을 위한 설계의 대안
A.5 요약

부록 B 추가 툴과 프레임워크
B.1 격리 프레임워크
B.2 테스트 프레임워크
B.3 IoC 컨테이너
B.4 데이터베이스 테스트
B.5 웹 테스트
B.6 UI 테스트
B.7 스레드 관련 테스트
B.8 수용 테스트

찾아보기

내가 참여했던 프로젝트 가운데 가장 크게 실패한 프로젝트에서 우리는 유닛 테스트를 사용하고 있었다. 적어도 나는 그렇다고 생각했다. 그 프로젝트에서 나는 대금 지불에 관련된 응용 프로그램을 작성하는 프로그래머 그룹을 이끌고 있었다. 우리는 완전히 테스트 주도 개발 방식으로 코딩했다. 테스트를 먼저 작성하고, 그 다음에 코드를 작성하고, 테스트가 실패하는 것을 보고, 테스트가 통과하게 만들고, 리팩터링하고, 그리고 이를 계속 반복했다.
프로젝트가 시작되고 몇 달간은 괜찮았다. 모든 것이 잘 진행되고 있었고 코드가 제대로 작동한다는 것을 보여 주는 테스트들도 갖추고 있었다. 하지만 시간이 흐르면서 요구사항이 변경되기 시작하였다. 우리는 새로운 요구사항에 맞게 코드를 수정해야 했고 그렇게 하자 테스트가 실패했기 때문에 테스트를 수정해야 했다. 코드는 잘 돌아갔지만 작성된 테스트가 굉장히 불안정했기 때문에 코드에 문제가 없었는데도 코드를 조금만 수정해도 테스트는 실패해 버렸다. 관련된 모든 유닛 테스트를 함께 수정해야 했기 때문에 클래스나 메서드를 수정하는 일은 매우 두려운 일이 되었다.
업친 데 덥친 격으로 어떤 테스트들은 쓸모없어졌다. 그 이유는 테스트를 작성한 사람이 프로젝트에서 나가는 바람에 테스트를 어떻게 수정해야 할지, 그리고 테스트가 무엇을 테스트하고 있는지 아는 사람이 아무도 없었기 때문이다. 유닛 테스트의 이름이 충분히 명확하지 않았고 테스트들은 서로 의존하고 있었다. 6개월도 채 되지 않아 우리는 대부분의 테스트를 버려야 했다.
작성된 테스트가 도움을 주기는커녕 상황을 더 나쁘게 만들어 버렸기 때문에 프로젝트는 비참하게 실패하고 말았다. 장기적으로 봤을 때 테스트가 주는 도움에 비해서 테스트를 관리하고 이해하는 데 더 많은 시간이 들었기 때문에 우리는 테스트의 사용을 중단할 수밖에 없었다. 나는 그 이후로 다른 프로젝트를 맡게 되었고 이번에는 유닛 테스트를 제대로 활용하여 디버깅이나 통합에 드는 시간을 크게 줄일 수 있었다. 그 이후로 몇몇 큰 성공을 거두기도 했다. 처음 실패했던 그 프로젝트 이후로 나는 유닛 테스트 작성과 관련된 비법들을 정리하기 시작했다. 그리고 이를 여러 프로젝트에서 활용했다. 프로젝트가 끝날 때마다 더 많은 비법을 얻을 수 있었다.
이 책에서는 무슨 프로그램 언어 또는 통합 개발 환경(Integrated Development Environment, IDE)을 사용하든 간에 어떻게 하면 유닛 테스트를 더 관리하기 쉽고, 읽기 쉽고, 신뢰할 수 있게 작성할지 설명한다. 유닛 테스트의 기본적인 내용을 설명하고 통합 테스트가 무엇인지도 소개한다. 또한 이 책에서는 실전에서 바로 사용할 수 있는 유닛 테스트 작성 및 관리 방법에 관한 모든 노하우를 공개한다.

- 지은이의 글에서