세번째 발자국 👣

테스트는 왜 필요할까?

-테스트를 통해 얻고자 하는것

• 빠른 피드백

• 자동화

• 안정감

단위테스트

작은 코드단위를 독립적으로 검증하는 테스트

검증속도가 빠르고, 안정적이다

테스트 케이스 세분화하기

해피케이스

예외케이스

경계값 테스트 ( 범위(이상,이하,초과,미만)구간 날짜 등)

테스트하기 어려운 영역을 분리하기

테스트하기 어려운 영역

-> 관측할 때마다 다른 값에 의존하는 코드

• 현재날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등

   

-> 외부세계에 영향을 주는 코드

• 표준 출력, 메시지 발송 , 데이터베이스에 기록하기 등

TDD : Test Driven Development

프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현과정을 주도하도록 하는 방법론

레드: 실패하는 테스트 작성 -> 그린: 최소한의 코딩 -> 리팩터: 구현코드 개선 테스트 통과유지

클라이언트 관점에서의 피드백을 주는 Test Driven

테스트는 []다

프로덕선 기능을 설명하는 테스트 코드 문서

DisplayName을 섬세하게

-명사의 나열보다 문장으로

-테스트 행위에 대한 결과까지 기술하기

-도메인 용어를 사용하여 한층 추상화된 내용을 담기

-테스트 현상을 중점으로 기술하지 말것

BDD 스타일로 작성하기

-TDD에서 파생된 개발 방법

-함수 단위의 테스트 보다 시나리오에 기반한 테스트케이스자체에 집중

-개발자가 아닌 사람이 봐도 이해할수 있을 정도의 추상화 수준을 권장

Given / When / Then

• Given : 시나리오 진행에 필요한 모든 준비 과정

• When : 시나리오 행동 진행

• Then : 시나리오 진행에 대한 결과 명시, 검증

Layerd Architecture와 테스트

Layerd Architecture -> 관심사의 분리

Persistence Layer

Data에 대한 CRUD에만 집중한 레이어

• Data Access의 역할

• 비지니스 가공 로직이 포함 되어서는 안된다.

Business Layer

• 비즈니스 로직을 구현하는 역할

• Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)를 통해

  비즈니스 로직을 전개시킨다.

• 트랜잭션을 보장해야한다.

테스트 코드 작성하기 미션 회고

이렇게 하는 것이 맞는지 계속 의문이 들었다. DisplayName을 짓는 것도 어렵고 쉽지 않았다. 예외 케이스를 생각하는게 쉽지않았다.