이펙티브 테스팅 챕터 2#
Abstraction#
- 요구사항 기반으로 테스트코드 만들면 아주좋음, 그게 명세기반테스트임
- 도메인이 강력하고 요구사항이 복잡할수록, 명세기반테스트로 검증하기 좋고 검증해야함
- 명세기반 테스트를 위한 7단계 접근법
- 버그는 경계를 좋아한다. 엣지케이스라고도 하는데, 이 엣지케이스를 찾는게 가장 중요하고 어려운 일
- 무엇을 테스트해야하는지 결정잘해
- 무엇은 테스트하면 안되는지(의미가 없는 쓸데없는 테스트인지) 결정 잘하기
인트로#
- 소프트웨어에서 가장 중요한거 : 요구사항 충족
- 비지니스가 복잡하고 고도화될수록, 비지니스 요구사항을 잘 충족하는지 검사해야한다
- (내생각) 도메인이 고도화될수록 » 도메인 로직 위주로 테스트하기 쉽도록 단위테스트를 만들면 아주 좋겠죠?
- 명세 기반 테스트의 정의
- 명세기반 테스트란 : 유저스토리(from 에자일), 유스 케이스(Of UML) 를 테스트의 입력으로 사용한다.
- (내생각) 좀더 쉽게 현실적으로 기획서같은데 적혀있는 요구사항 베이스로 코드를 짠다고 보면 좋을듯
- 명기태와 함께해서 좋은곳
- 새로운 기능을 개발할때 명기태가 좋다
- (내생각) 안전모드/테스트모드 or 수정모드/리팩토링 모드 » 이거 내용 클린아키텍쳐에 나오는 내용인데 클린아키텍쳐랑 연계해서 보면 더 좋을듯?
- 그러니까 논리는 : 소프트웨어에서 젤루 중요한게 요구사항 충족이고 » 명세기반테스트는 요구사항에서 테스트를 도출(테스트항목을 도출하고,요구사항이 테스트의 입력이 되는)한다 » 그래서 소프트웨어의 기능추가개발시 명기태가 아주 좋은 친구이다
명세기반 테스트 하는법(How To)#
1. 요구사항 이해하기 : 뭘 만들어달란건지 파악하자
2. 프로그램 탐색하기 : 구현해도 되고, 당신이 만든 코드가 아닌 다른사람의 코드라면, 돌려보면서 가지고놀면서 친해져야함. 키워드는 "이해"
3. 구획식별하기 : 입력은 뭐가 들어오는지, 출력은 뭐가 들어오는지 식별
4. 경계 분석하기 : 버그가 존재할수 있는 바운더리 꼼꼼히 체크하기
5. 테스트케이스 고민하기 : 아이디어를 구현하고, 경계에 있는 엣지케이스들을 테스트케이스로 만들어라
6. 테스트코드 작성하기 : 테스트코드 만들어줘
7. 강화하기
실전에서 써먹는 명세테스트(현업에서의) » 솔직히 먼말인지 모르겠음;;;#
2.4.1 프로세스는 연속적이 아니라 반복적이어야 한다#
2.4.2 명세 테스트는 어느 정도로 수행해야 하는가?#
2.4.3 구획인가, 경계인가? 그것은 중요하지 않다!#
2.4.4 접점과 거점으로도 충분하지만 내점과 외점도 얼마든지 추가하자#
2.4.5 이해를 높이기 위해 입력을 변경해서 사용하자#
2.4.6 조합의 수가 폭발적으로 증가한다면 실용적이어야 한다#
2.4.7 무엇을 입력할지 모르겠다면 간단한 입력을 넣어보자#
2.4.8 관심 없는 입력에 대해 합리적인 값을 선택하자#
2.4.9 널과 예외 케이스는 의미가 있을 때만 사용하자#
2.4.10 테스트가 동일한 스켈레톤을 갖는 경우 매개변수화 테스트를 사용하자#
2.4.11 요구사항은 잘게 쪼갤 수 있다#
2.4.12 이것은 클래스와 상태에 어떻게 동작하는가?#
2.4.13 경험과 창의성의 역할#