내가 참여했던 프로젝트 가운데 가장 크게 실패한 프로젝트에서 우리는 유닛 테스트를 사용하고 있었다. 적어도 나는 그렇다고 생각했다. 그 프로젝트에서 나는 대금 지불에 관련된 응용 프로그램을 작성하는 프로그래머 그룹을 이끌고 있었다. 우리는 완전히 테스트 주도 개발 방식으로 코딩했다. 테스트를 먼저 작성하고, 그 다음에 코드를 작성하고, 테스트가 실패하는 것을 보고, 테스트가 통과하게 만들고, 리팩터링하고, 그리고 이를 계속 반복했다.
프로젝트가 시작되고 몇 달간은 괜찮았다. 모든 것이 잘 진행되고 있었고 코드가 제대로 작동한다는...
더보기
이 책의 이벤트
해외주문/바로드림/제휴사주문/업체배송건의 경우 1+1 증정상품이 발송되지 않습니다.-
![개발자 매거진 <리드잇zine> 4호([교보단독 사은품] 개발자 매거진 <리드잇zine> 4호 )](http://image.kyobobook.co.kr//ink/images/prom/2022/book/220421_readit/bnJ_03.jpg)
[교보단독 사은품] 개발자 매거진 <리드잇zine> ..2022.05.10 ~ 2022.06.30 -
MANNING, O'REILLY, PACKT, WILE..2016.03.07 ~ 2022.12.31
| ISBN | 9788991268852(8991268854) |
|---|---|
| 쪽수 | 328쪽 |
| 크기 | 188 * 240 * 30 mm /636g 판형알림 |
| 이 책의 원서/번역서 | (The)art of unit testing with examples in .NET / Osherove, Roy |
책소개
이 책이 속한 분야
이 책의 설명
예제를 통해 단위 테스트를 배운다!
『NET 예제로 배우는 단위 테스트』는 .NET 환경의 개발자들이 단위 테스트를 할 때 알아야 할 모든 것을 다룬다. 단위 테스트부터 통합 테스트까지, 필요한 도구와 테스트 작성/관리 방법에 관한 모든 노하우를 일목요연하게 설명한다. 또한, 실전에서 단위 테스트를 도입하며 겪게 되는 문제와 이를 해결하는 방법 그리고 조직을 어떻게 설득하고 변화시킬 수 있는지를 알려준다. 이 책을 통해 읽기 쉽고 신뢰할 수 있는 단위 테스트를 만들게 되어, 디버깅과 통합에 드는 시간을 크게 줄일 수 있다.
목차
옮긴이의 글
추천의 글
지은이의 글
감사의 글
이 책에 관해
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 수용 테스트
찾아보기
추천의 글
지은이의 글
감사의 글
이 책에 관해
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 수용 테스트
찾아보기
책 속으로
출판사 서평
팀에서 단위 테스트를 도입하려고 준비 중이거나, 이미 도입했지만 단위 테스트 때문에 코드가 더 복잡해지고 있다면?
이 책은 단위 테스트를 할 때 알아야 할 모든 것을 알아본다.
단위 테스트부터 통합 테스트까지, 필요한 도구와 테스트 작성/관리 방법에 관한 모든 노하우를 일목요연하게 설명한다. 또한, 실전에서 단위 테스트를 도입하며 겪게 되는 문제와 이를 해결하는 방법 그리고 조직을 어떻게 설득하고 변화시킬 수 있는지를 알려준다. .NET 예제 코드를 기반으로 설명하고 있긴 하지만, .NET이 아닌 환경이라 하더라도 이 책에 ... 더보기
이 책은 단위 테스트를 할 때 알아야 할 모든 것을 알아본다.
단위 테스트부터 통합 테스트까지, 필요한 도구와 테스트 작성/관리 방법에 관한 모든 노하우를 일목요연하게 설명한다. 또한, 실전에서 단위 테스트를 도입하며 겪게 되는 문제와 이를 해결하는 방법 그리고 조직을 어떻게 설득하고 변화시킬 수 있는지를 알려준다. .NET 예제 코드를 기반으로 설명하고 있긴 하지만, .NET이 아닌 환경이라 하더라도 이 책에 ... 더보기
Klover 리뷰 (0)
북로그 리뷰 (0) 쓰러가기
북로그 리뷰는 본인 인증 후 작성 가능합니다.
책이나 타인에 대해 근거 없이 비방을 하거나 타인의 명예를 훼손할 수 있는 내용은 비공개 처리 될 수 있습니다.
※ 북로그 리뷰 리워드 제공 2021. 4. 1 종료
책이나 타인에 대해 근거 없이 비방을 하거나 타인의 명예를 훼손할 수 있는 내용은 비공개 처리 될 수 있습니다.
※ 북로그 리뷰 리워드 제공 2021. 4. 1 종료
문장수집 (0) 문장수집 쓰기 나의 독서기록 보기
※구매 후 문장수집 작성 시, 리워드를 제공합니다.
안내
교환/반품/품절안내
※ 상품 설명에 반품/교환 관련한 안내가 있는 경우 그 내용을 우선으로 합니다. (업체 사정에 따라 달라질 수 있습니다.)
| 반품/교환방법 | 마이룸 > 주문관리 > 주문/배송내역 > 주문조회 > 반품/교환신청 , [1:1상담>반품/교환/환불] 또는 고객센터 (1544-1900) ※ 오픈마켓, 해외배송주문, 기프트 주문시 [1:1상담>반품/교환/환불] 또는 고객센터 (1544-1900) |
|---|---|
| 반품/교환가능 기간 | 변심반품의 경우 수령 후 7일 이내, 상품의 결함 및 계약내용과 다를 경우 문제점 발견 후 30일 이내 |
| 반품/교환비용 | 변심 혹은 구매착오로 인한 반품/교환은 반송료 고객 부담 |
| 반품/교환 불가 사유 |
|
| 상품 품절 | 공급사(출판사) 재고 사정에 의해 품절/지연될 수 있으며, 품절 시 관련 사항에 대해서는 이메일과 문자로 안내드리겠습니다. |
| 소비자 피해보상 환불지연에 따른 배상 |
|
기프트 BEST
![[동원] 동원샘물 웨이크업뷰티 500ml*20병](http://image.kyobobook.co.kr/newimages/giftshop_new/goods/400/1764/S1641424942887.jpg)
![[1+1] 푹신푹신 유해물질 걱정없는 무소음 슬리퍼](http://image.kyobobook.co.kr/newimages/giftshop_new/goods/400/1073/hot1651221757378.jpg)
![[한정수량] 알루미늄 높이 각도조절 노트북 받침대](http://image.kyobobook.co.kr/newimages/giftshop_new/goods/400/1396/hot1651107871317.jpg)
LG U+ 구매안전서비스
▶서비스 가입 확인
고객님은 안전거래를 위해 현금 등으로 결제시 저희 쇼핑몰에서 가입한 LG유플러스의 구매안전서비스를 이용하실 수 있습니다.
정보보호관리체계
ISMS 인증획득
ISMS 인증획득
[인증범위] 온라인 교보문고 서비스 운영
[유효기간] 2020.11.04. ~ 2023.11.03.
바로가기
북소믈리에 한마디!