Day 10. 단위 테스트

테스트는 왜 필요할까?

• 빠른 피드백

• 자동화

• 안정감

단위 테스트

• 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트

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

테스트 케이스 세분화하기

• 해피 케이스

• 예외 케이스

• 경계값 테스트

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

테스트하기 어려운 영역

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

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

순수 함수

• 같은 입력에는 항상 같은 결과

• 외부 세상과 단절된 형태

• 테스트하기 쉬운 코드

Day 11. TDD | 테스트는 [ ] 다

TDD: Test Driven Development

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

• 테스트와 상호작용하며 발전하는 구현부

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

• 애자일 성명서 : http://agilemanifesto.org/

테스트는 [ ] 다

• [ ]는 강의에서

  😀

• 우리는 항상 팀으로 일한다

DisplayName을 섬세하게

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

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

BDD 스타일로 작성하기

• TDD에서 파생된 개발 방법

   

• Given : 시나리오 진행에 필요한 모든 준비 과정 (객체, 값, 상태 등)

• When : 시나리오 행동 진행

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

Day 12. 테스트 코드 적용 미션

 https://github.com/japygo/readable-code/commits/mission7-1/

회고

• 이름 짓기처럼 DisplayName을 짓는 것도 역시나 고민되고 어렵다.

• 테스트 코드를 굳이 작성해야하나 싶은 테스트를 작성해야 하는지 의문이다.

• 테스트 커버리지 보다는 다양한 예외 케이스들을 제대로 했는지가 중요한 것 같다.

Day 13. Spring & JPA 기반 테스트: Persistence Layer

레이어드 아키텍처(Layered Architecture)와 테스트

• 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트

Library vs Framework

• Library: 내 코드가 주체

• Framework: 이미 동작할 수 있는 환경이 있어 내 코드가 수동적

Persistence Layer

• Data Access의 역할

• 비즈니스 가공 로직이 포함되어서는 안 된다. Data에 대한 CRUD에만 집중한 레이어

Day 14. Spring & JPA 기반 테스트: Business Layer

Business Layer

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

• Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)을 통해 비즈니스 로직을 전개시킨다.

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

회고

• 테스트 코드 강의 역시 상상 속의 있던 유니콘을 만나는 기분이었다.

• 중요한 걸 알지만 현업에서 만나볼 수 없어서 감이 전혀 오지 않았는데 어떤 느낌인지 알 수 있었다.

• 열심히 해서 다양한 테스트 케이스를 만나 볼 수 있으면 좋겠다.

출처

• https://inf.run/zgJk5

• https://inf.run/kHiWM