섹션 0. 오리엔테이션
섹션 1. 이론 수업
테스트에 대한 개요와 개발자가 해야할 고민
•
테스트란?
◦
어떤 시스템이 동작하는지 검증하는 과정으로 하나는 사람이 확인하는 인수 테스트와 자동 테스트로 나뉜다.
•
TDD의 장단점
◦
장점1. 깨지는 테스트를 먼저 작성해야 하므로 인터페이스를 먼저 만드는 것이 강제된다.
⇒ 행동에 집중하겠다. What/Who 사이클을 고민해볼 수 있게 도와준다.
◦
장점2. 장기적인 관점에서 개발 비용 감소
•
개발자의 고민
◦
무의미한 테스트
▪
커버리지를 채우기 위한 테스트는 필요한가?
◦
느리고 쉽게 깨지는 테스트
◦
테스트가 불가한 코드
▪
의존성이 적절히 분리되지 않은 코드
테스트의 필요성과 테스트 3분류
1.
필요성
•
레거시 코드란 테스트가 없는 코드이다.
•
회귀가 발생하는 것을 두렵기 때문에 테스트가 필요하다.
•
좋은 테스트를 작성하면 좋은 아키텍처가 따라온다.
◦
SOLID와 테스트는 밀접한 관계를 갖는다.
◦
SRP: 테스트가 너무 많아져서 이게 무슨 목적의 클래스인지 알 수 없다.
◦
OCP: 테스트와 프로덕션을 나눠 작업하면 자유자재로 결합도가 낮아진다.
◦
LIP: 이상적으로 테스트는 모든 케이스를 커버하므로 서브 클래스의 치환 여부를 테스트가 판단해준다.
◦
ISP: 불필요한 의존성을 실제로 확인할 수 있다.
◦
DIP: 가짜 객체를 이용해 테스트하려면 의존성이 역전되어있어야 한다.
2.
테스트의 3분류
•
E2E, 통합, 단위의 정의는 무엇인가? 구글은 각각 대형, 중형, 소형이라고 한다.
◦
소형 - 단일 서버, 단일 프로세스, 단일 스레드, 파일 입출력 사용 x, Blocking call x
◦
중형 - 단일 서버, 멀티 프로세스, 멀티 스레드
◦
대형 - 멀티 서버
테스트에 필요한 개념
•
BDD가 테스트를 작성해야할만큼 중요한 로직을 찾는데 도움을 준다.
•
상호작용 테스트
•
상태 검증, 행위 검증
•
테스트 픽스쳐
•
비욘세 규칙
◦
유지하고 싶은 상태가 있으면 전부 테스트로 작성하라.
•
테스트는 그 자체로 정책이고 계약이다.
•
테스트 대역
◦
dummy, spy, mock, stub, fake
의존성과 Testability
•
의존성, 의존성 주입
◦
의존성 주입은 의존성을 약화시킨 것이지 없앤 것이 아니다.
◦
new가 사실상 하드 코딩이기 때문이다.
•
의존성 역전
◦
상위 모듈은 하위 모듈에 의존해서는 안 된다.
◦
추상화는 세부 사항에 의존해서는 안 된다. 세부사항이 추상화에 의존해야 한다.
•
테스트를 잘 하려면 의존성 주입과 의존성 역전을 잘 다룰 수 있어야한다.
◦
숨겨진 의존성이 테스트를 어렵게 만든다.
◦
의존성 주입과 역전을 사용해서 해결해야 한다.
•
대부분의 소프트웨어 문제는 의존성 역전으로 해결이 가능하다.
•
테스트 가능성
◦
얼마나 쉽게 input을 변경하고 output을 검증할 수 있는가?
섹션 2. 1부 실기 수업 - 어쨌든 테스트 코드
섹션 3. 방향성 탐색
레이어드 아키텍처의 문제점과 해결책
•
유사한 기능들을 같은 계츠으올 묶어 관리하는 방식의 아키텍처 구조로 쉽다.
•
단점
◦
DB 주도 설계를 유도한다. 모든 것이 영속성 계층을 토대로 만들어진다.
▪
도메인을 파악하는 것이 먼저다.
◦
도메인이 죽는다. 서비스가 모든 비즈니스 로직을 다 처리한다.
◦
동시 작업이 불가하다.
◦
섹션 4. 2부 실기 수업 - 구조적 변화를 주는 테스트 코드
패키지 구조 개선
•
연관 객체를 적절히 배분하는 것이 좋다.
•
DTO라고 DTO에 박아두지 말자.
