1/5 TIL 단위 테스트 스타일

테스트의 3가지 종류

• 출력 기반 - 가장 좋음
• 상태 기반 - 그 다음 안 좋음. 고전파가 선호
• 통신 기반 - 가장 안 좋음 . 런던파가 선호

상태 기반 테스트는 안정성을 위해 더 신중해야 한다. 유지보수가 쉽지 않다.

통신 기반 테스트도 안정성에 신중. 목도 공간을 많이 차지해 가독성이 안 좋다.
캡슐화를 잘하면 통신 기반도 리팩터링 안정성을 많이 지킬수 있다.

유지보수성 지표

테스트를 이해하기 얼마나 어려운가?(테스트 크기)
테스트를 실행하기 얼마나 어려운가?(프로세스 외부 의존성의 크기)

함수형 프로그래밍

외부로의 부작용, 숨은 매개변수가 없어야 한다. 테스트 용이성을 상당히 높힌다.
의존성이 시그니처에 없더라도, 불변이라면 숨은 매개변수가 아니다.

비즈니스 로직과 부작용을 분리하는 것이 목표다. (완전한 제거는 불가능하므로 목표가 아니다.)

메서드가 함수인지 확인하는 방법 : 메서드의 호출 대신 값으로 바꿨을 때 전체 동작이 변하지 않는가?

함수형 아키텍처

부작용을 비즈니스 연산의 가장자리로 밀어내 분리를 이루는데 도움이 된다.
함수형 코어와 가변 셸, 두가지 범주로 나눈다.
코어는 결정을 내림.   가변 셸은 입력 데이터를 코어에 공급하고, 코어의 결정을 부작용으로 변환함

육각형 아키텍처는 도메인 계층의 부작용까지는 인정한다.

함수형 아키텍처는 성능을 트레이드 오프하게 될 수도 있다.

모든 코드베이스를 함수형 아키텍처로 전환할 수는 없다. 

객체지향과 함수형

객체지향은 캡슐화, 함수형은 불변성

객체지향 프로그래밍은 작동 부분을 캡슐화해 코드를 이해하게 한다.
함수형 프로그래밍은 작동부분을 최소화해 코드를 이해하게 한다.

---

느낀점

예제가 잘 나와있어 좋았다. 다시 봐도 좋을 것 같다. 대략 아래와 같은 흐름이였다.

비즈니스 로직 분리를 위해 인터페이스를 둔다. -> 테스트시 인터페이스를 목으로 대체할 수 있다.
함수형 아키텍처를 위해 코어가 '액션'을 반환하게 만든다. ->셸이 그 액션으로 부작용을 수행한다.