1. 오늘 겪은 문제
1. jest 시작!
2. 의존성 주입, 생성자 주입
3. layered architecture의 밖에 있는 코드들에 대하여
2. 해본 시도
- jest를 사용하기 위한 시동을 거는 중이다. 현재 기본적인 단위 테스트하는 방법들에 대해 배웠고, 데이터 베이스를 직접 사용한다면 테스트시 비용이 상당하기 때문에 가상객체인 mock를 사용하는 mocking과 mocking 사용을 위한 의존성주입 그중에서도 생성자 주입을 시도해보았다.
- 미들웨어나, 유틸리티를 위해 따로 구현해 놓은 코드들은 보통 우리가 의도한 레이어드 패턴 밖에 위치하기 마련이다. 이럴 때, 해당 코드들과 레이어드 패턴간의 관계를 어떻게 설정 해야할 지가 고민이었는데, 때로는 2번의 내용처럼 의존성을 주입하는 것이 답이 될 수 있겠다는 생각을 했다.
3. 해결 방법
- mocking을 사용하기 위해서는 항상 같은 데이터 베이스에 직접연결 되어 있으면 가상 객체를 갑자기 사용하기가 어렵다. 그래서 해당 프로젝트의 이식성을 높히기 위해서 의존성주입을 하는데, 일전의 바로 repository 계층에서 바로 db와 연결되어 있던 것을 생성자의 constructor에서 해당 객체를 상속받아 사용하게 함으로 의존성관리 중간다리를 거치게 하여 이식성을 높였다.
- 미들웨어에서 직접 접근이라기 보다는 다른 계층을 통해서 우회적으로 접근하는 방법을 사용하는게 좋아보인다.
4. 새롭게 알게 된 점
- jest에 대해 알아가는 중이다. 테스트 코드를 작성하고 테스트를 작성하는 것이 내 코드의 신뢰도를 높일 수 있게한다는 점이 멋있다고 생각한다.
- 의존성 주입에 대해 알게 되었다. 직접 접근이 아닌 가운데 의존성 관리자를 만들어서 어느 곳에 의존할 것인지 지정할 수 있게 만들면, 마치 원하는 부품을 어디에나 바로 끼워 맞춰볼 수 있는 것처럼 동작하게 할 수 있다는 점이 매력적이었다.
5. 오늘 더 효율적으로 일할 수 있었을 것 같은 방법은?
- 작은 목표를 세워 달성하고 해당 작업을 여러번 그리고 많이 반복하자.
기여하는 개발자