간편결제, 신용카드 청구할인
인터파크 롯데카드 5% (18,810원)
(최대할인 10만원 / 전월실적 40만원)
북피니언 롯데카드 30% (13,860원)
(최대할인 3만원 / 3만원 이상 결제)
NH쇼핑&인터파크카드 20% (15,840원)
(최대할인 4만원 / 2만원 이상 결제)
Close

NET 예제로 배우는 단위 테스트

원제 : (The)art of unit testing with examples in .NET
소득공제

2013년 9월 9일 이후 누적수치입니다.

판매지수 47
?
판매지수란?
사이트의 판매량에 기반하여 판매량 추이를 반영한 인터파크 도서에서의 독립적인 판매 지수입니다. 현재 가장 잘 팔리는 상품에 가중치를 두었기 때문에 실제 누적 판매량과는 다소 차이가 있을 수 있습니다. 판매량 외에도 다양한 가중치로 구성되어 최근의 이슈도서 확인시 유용할 수 있습니다. 해당 지수는 매일 갱신됩니다.
Close
공유하기
정가

22,000원

  • 19,800 (10%할인)

    1,100P (5%적립)

할인혜택
적립혜택
  • I-Point 적립은 마이페이지에서 직접 구매확정하신 경우만 적립 됩니다.
추가혜택
배송정보
  • 8/17(수) 이내 발송 예정  (서울시 강남구 삼성로 512)
  • 무료배송
주문수량
감소 증가
  • 이벤트/기획전

  • 연관도서(104)

  • 상품권

AD

책소개

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

『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)을 사용하든 간에 어떻게 하면 유닛 테스트를 더 관리하기 쉽고, 읽기 쉽고, 신뢰할 수 있게 작성할지 설명한다. 유닛 테스트의 기본적인 내용을 설명하고 통합 테스트가 무엇인지도 소개한다. 또한 이 책에서는 실전에서 바로 사용할 수 있는 유닛 테스트 작성 및 관리 방법에 관한 모든 노하우를 공개한다.

- 지은이의 글에서

저자소개

로이 오셔로브 [저] 신작알림 SMS신청
생년월일 -

해당작가에 대한 소개가 없습니다.

송인철, 황인석 [역] 신작알림 SMS신청
생년월일 -

해당작가에 대한 소개가 없습니다.

이 상품의 시리즈

(총 115권 / 현재구매 가능도서 105권)

선택한 상품 북카트담기
펼쳐보기

컴퓨터/인터넷 분야에서 많은 회원이 구매한 책

    리뷰

    8.0 (총 0건)

    구매 후 리뷰 작성 시, 북피니언 지수 최대 600점

    리뷰쓰기

    기대평

    작성시 유의사항

    평점
    0/200자
    등록하기

    기대평

    8.0

    판매자정보

    • 인터파크도서에 등록된 오픈마켓 상품은 그 내용과 책임이 모두 판매자에게 있으며, 인터파크도서는 해당 상품과 내용에 대해 책임지지 않습니다.

    상호

    (주)교보문고

    대표자명

    안병현

    사업자등록번호

    102-81-11670

    연락처

    1544-1900

    전자우편주소

    callcenter@kyobobook.co.kr

    통신판매업신고번호

    01-0653

    영업소재지

    서울특별시 종로구 종로 1(종로1가,교보빌딩)

    교환/환불

    반품/교환 방법

    ‘마이페이지 > 취소/반품/교환/환불’ 에서 신청 또는 1:1 문의 게시판 및 고객센터(1577-2555)에서 신청 가능

    반품/교환가능 기간

    변심 반품의 경우 출고완료 후 6일(영업일 기준) 이내까지만 가능
    단, 상품의 결함 및 계약내용과 다를 경우 문제점 발견 후 30일 이내

    반품/교환 비용

    변심 혹은 구매착오로 인한 반품/교환은 반송료 고객 부담
    상품이나 서비스 자체의 하자로 인한 교환/반품은 반송료 판매자 부담

    반품/교환 불가 사유

    ·소비자의 책임 있는 사유로 상품 등이 손실 또는 훼손된 경우
    (단지 확인을 위한 포장 훼손은 제외)

    ·소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우
    예) 화장품, 식품, 가전제품(악세서리 포함) 등

    ·복제가 가능한 상품 등의 포장을 훼손한 경우
    예) 음반/DVD/비디오, 소프트웨어, 만화책, 잡지, 영상 화보집

    ·시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우

    ·전자상거래 등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에 해당되는 경우

    상품 품절

    공급사(출판사) 재고 사정에 의해 품절/지연될 수 있음

    소비자 피해보상
    환불지연에 따른 배상

    ·상품의 불량에 의한 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은 소비자분쟁해결 기준 (공정거래위원회 고시)에 준하여 처리됨

    ·대금 환불 및 환불지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의 소비자 보호에 관한 법률에 따라 처리함

    (주) 인터파크 안전결제시스템 (에스크로) 안내

    (주)인터파크의 모든 상품은 판매자 및 결제 수단의 구분없이 회원님들의 구매안전을 위해 안전결제 시스템을 도입하여 서비스하고 있습니다.
    결제대금 예치업 등록 : 02-006-00064 서비스 가입사실 확인

    배송안내

    • 교보문고 상품은 택배로 배송되며, 출고완료 1~2일내 상품을 받아 보실 수 있습니다.

    • 출고가능 시간이 서로 다른 상품을 함께 주문할 경우 출고가능 시간이 가장 긴 상품을 기준으로 배송됩니다.

    • 군부대, 교도소 등 특정기관은 우체국 택배만 배송가능합니다.

    • 배송비는 업체 배송비 정책에 따릅니다.

    • - 도서 구매 시, 1만 원 이상 무료, 1만원 미만 2천 원 - 상품별 배송비가 있는 경우, 상품별 배송비 정책 적용