결합과 추상화

파이썬으로 살펴보는 아키텍처 패턴을 보다가 3장 부분에 종종 생각하던 부분이 있어서 정리해 봤다. 테스트에 관련한 부분이다.

추상화에 대한 이야기를 하는데, 설계를 위한 추상화다. 그리고 테스트는 그 설계를 위함이 우선이라고 한다.
그래서 첫 번째는 그냥 돌아가게 구현하고 리팩터링 하는 식으로 이어지는데,  테스트를 위해 다른 방식으로 구현하는 예시도 보여준다.

 

3.3 선택한 추상화 구현
중요 로직을 명확하게 빼서 추상화하는데 여기 예시의 구현을 간단히 정리하면
외부 상태에 대해 아무 의존성이 없는 코드의  '핵' 을 만들고 외부 세계를 표현하는 입력에 대해 핵이 출력한 걸 처리한다. 그니까 중요 비즈니스 로직을 추상화해서 따로 빼놓는다. 이렇게 예시를 직접 보니까 추상화를 하면 테스트하기가 훨씬 쉬워지는 거 같다. 사실 습관적으로 그냥 계층 분리를 계속해왔는데, 정리된 내용을 보니까 좀 더 결과를 생각하면서 추상화를 해야겠다는 생각이 들었다. 

 

e2e 테스트를 위한 의존성 주입

이 부분이 내가 작업을 하면서 고민을 했던 부분들이 있다.
단위 테스트를 진행하면서 시스템의 전체를 테스트 하게 만들기 위해서 위의 로직을 다시 수정한다
캡슐화했던 로직들을 전부 다시 sync()로 노출시키고 인자로 의존성을 주입하면서 명시적으로 의존성을 보여준다. 이렇게 하면 테스트할 때 fake를 작성해서 주입시키고 전체 로직을 테스트할 수 있게 한다.
나는 프로젝트를 하면서 고민했던 부분이었는데, api 부분을 테스트할 때 특히 그랬다. 어차피 내부의 함수는 다른 테스트에서 로직을 검사하니 api에서는 그냥 패칭이나 mock을 사용해서 로직만 테스트했다. 

이 책의 내용을 보면 api를 완전히 테스트하고 싶다면 아예 책에서 안내한것처럼  fake 객체를 줘서 하는게 맞고. 아니면 중요 로직만 테스트 하고 api함수의 자체 로직은 복잡할 게 없으니 따로 안 하는 것도 괜찮은 거 같다. 
fast-api 프로젝트를 진행하면서 api 엔드포인트는 보통 의존성 주입을 사용해서 구현했기 때문에 충분히 fake 객체를 사용한 e2e테스트가 가능한 거 같다. 

테스트라는 게 실제로 시간이 많으면 더 꼼꼼하게 작성하면 물론 좋지만 이것도 상황 봐가면서 잘 작성하려고 고민을 많이 해봐야겠다.

아 그리고 mock과 fako object 부분도 확실히 고민을 하면서 작성해야겠다. 내가 지금 패치를 막 갖다 붙이고 mock을 너무 자주 사용한다면 설계가 잘못된건 아닌지 고민도 해봐야겠다.

 

책에서 소개하는 올바른 추상화를 위한 몇 가지 질문들

• 지저분한 시스템의 상태를 표현할  수 있는 익숙한 파이썬 객체가 있는가? 그렇다면(이 파이썬 객체를 활용해) 시스템 상태를 반환하는 단일 함수를 상상해 보라
• 시스템의 구성 요소 중 어떤 부분에 선을 그을 수 있는가? 이런 (선을 통해 구분되는 각각의) 추상화 사이의 이음매를 어떻게 만들 수 있는가?
• 시스템의 여러 부분을 서로 다른 책임을 지니는 구성 요소로 나누는 합리적인 방법은 무엇일까? 명시적으로 표현해야 하는 암시적인 개념은 무엇인가?
• 어떤 의존 관계가 존재하는가? 핵심 비즈니스 로직은 무엇인가?

참고 및 출처: <파이썬으로 살펴보는 아키텍처 패턴: TDD, DDD, EDM 적용하기)> (해리 퍼시벌, 밥 그레고리 지음, 오현석 옮김,  한빛미디어 , 2021)