2. - 테스트 자동화 전문가는 하루아침에 되는게 아니다. 1. 테스트 자동화의 어려움. - 기술이 많이 필요하고 잘 알려지지 않은 데다 쓸 만한 도구도 별로 없다.
3. 테스트하기 쉬운것-> 어려운것 1. 간단한 엔티티 객체 - 의존관계 없는간단한 비지니스클래스 - 의존관계 있는복잡한 비지니스클래스 2. 상태 없는 서비스 객체 - 개별 컴포넌트를 통한 컴포넌트 테스트 - 전체비지니스로직레이어를 통한 레이어 테스트
4. 3. 상태가 다양한 서비스 객체 - 고객 테스트를 통한 서비스 퍼사드와 피하 테스트 - 상태가 다양한 컴포넌트를 통한 컴포넌트 테스트 4. '테스트하기 힘든' 코드 - 노출된 사용자 인터페이스 로직을대충 만든 다이얼로그 - 데이터베이스로직 - 다중 쓰레드소프트 웨어
6. 아이러니 -> 많은 개발팀이 기존의 레거시 프로그램에 테스트를 도입하면서 테스트에 발을 담그기시작한다
7. 알다시피 -> 레거시 소프트웨어 테스트에 실패하고 이로 인해 테스트 주도 개발을 포함한 자동화에 별로 좋지 않은 생각을 갖게 된다.
8. 어떻게 하면 되나? -> 2가지만 기억하라 1. 비슷한 일을 해본 사람을 고용해 도움을 청하고 2. 마이클 페더스의환상적인 책을 읽어 보아라
9. 자동 테스트를 유지 보수하기 좋게 만드는 길잡이 매슬로우의욕구 계층 이론 1. 생리적 욕구: 먹을 것, 마실 것, 쉴 곳, 성적 만족, 그리고 다른 신체적인 요구들. 2. 안전 욕구: 안전과 육체적 및 감정적인 해로움으로 부터의보호욕구. 3. 사회적(소속) 욕구: 애정, 소속감, 받아들여짐, 우정 4. 자존(존경) 욕구: 자기존중, 자율성, 성취감 등과 같은 내적인 자존요인과 지위, 인정, 관심과 같은 외부적인 존경요인. 5. 자아실현 욕구: 성장, 잠재력 달성, 자기 충족성; 자신이 될 수 있는 것이 되고자 하는 욕구
10. 주요 경로 코드 실행 - SUT의 API를 호출하는 간단한 왕복 테스트 형태로 단순 성공 테스트를 자동화 해야 한다. - SUT를 실행전SUT를 테스트 전 상태로 초기화해 테스트 픽스처를 설치한다. - SUT가 에러 없이 샐행 한다면 테스트는 통과!
11. 2. 주요 경로의 직접 출력값검증 - SUT 응답에 대한 단언 메소드를호출한다. - SUT의 다른 메소드를 호출하거나 SUT의 테스트 후 상태를 얻을수 있고 이런 값들에 대해서도 단언 메소드를호출할수 있다.
12. 3. 대안 경로 검증 - SUT 메소드에다양한 인자를 넣어본다. - SUT 테스트 이전 상태를 다양하게 해본다. ( 시작 상태를 다르게 초기화 한다. ) - 테스트 스텁을 통해 SUT의 간접 입력을 제어해 본다. 테스트 스텁? 특정 시스템 컴포넌트의 개발이 완료되지 않은 상황에서도 필요한 시험을 진행하기 위해 생성된 더미 컴포넌트(dummy component). 단지 기능(function) 또는 프로시저 헤더 등의 코드 루틴만 갖고 내부 프로세싱은 제한적으로 존재하거나 존재하지 않는 것이 일반적이다.
13. 4. 간접 출력 동작 검증 - 여전히 잘 되는지 알 수는 없다. - 테스트 스텁과그의 친구들을 통해 SUT로 나가는 메소드 호출을 가로챌수 있다. - 친구들 : 모의 객체 (Mock Object)나 테스트 스파이
14. 5. 테스트 실행, 유지 보수 최적화 - 테스트 실행을 빠르게 만들기 : 테스트 픽스쳐재사용이나 간접출력 검증에서 사용했던 기법을 기반으로해서가짜 객체로 의존 컴포넌트를 바꾸기 등등 - 테스트를 이해하고 유지 보수하기 쉽게 만들기 : 인라인 자주 쓰이는 로직을 테스트 유틸리티 메소드 안에 리팩토링하면애매한 테스트를 이해하기 쉽게 만들고, 테스트 코드 중복을 제거할수 있다 - 누락된 버그에 대한 위험 줄이기 : 테스트 로직의 복잡함을 캡슐화해서 거짓음성의 위험을 줄일수 있다. (거짓음성false negative) 실제로는 참(true)인 것이 거짓(false)으로 잘못 판정되는 검사 결과의 오류