기존 테스트의 문제점
H2 데이터 베이스
현재 모든 테스트는 거의 h2가 기본이다. 근데 이걸 사용하면 중형테스트 가 된다.
그리고 중형테스트가 많으면 잘몬된 테스트이다.
레이어드 아키텍처
이녀석이 문제의 본질이다.
DB주도의 설계가 된다
직관적이고 만들기 쉽지만 DB주도의 설계가 된다.
생각해 보면 나도 DB를 먼저 생각하고, 그다음에 테이블을 짜고 개발을 하다 UseCase를 생각하고, 그러면서 다시 테이블을 다시 짜고 반복.
물론 현재 캡스톤이 인원이 나가면서 일정이 꼬이면서 이런것도 있지만. UseCase를 파악을 잘 한건 아닌것 같다.
동시작업이 불가능 하다
Repository -> Service -> Controller 순으로 개발을 하다 보니
선행이 완료되지 않으면 뒤에는 시작조차 못하는 문제가 생긴다.
도메인이 죽는다
객체가 모두 수동적으로 돌아간다. 나만해도 대부분 getter, setter를 이용해서 개발을 진행했다.
-> fatService 라고도 하는데 모든 일을 service가 다 처리한다. 딱 내이야기다.
결론은 레이어드 아키텍쳐는 절차지향적 사고를 하게 하고. 이는 Test도 Solid도 지키지 못하게 한다.
현재 내 코드를 보면 domain 이라고 패키지 폴더명은 정해놨지만 사실상 domain이 아니라 JPAEntity들만 가득하다.
앞으로의 아키텍쳐
앞으로 도메인에는 Lombok을 제외한 어노테이션을 달지 않고 만든다.
이렇게 하면 의존성이 낮아지고 따라서 테스트가 쉬워진다.
이렇게 하면 domain은 순수 자바코드로, Repository는 레포지토리로 구분이 된다.
이들을 이용해 Service를 구성하면 이제 2개(domain, repository)의 의존성을 가진다.
service 테스트시 domain 부분은 순수 자바이기 때문에 인스턴스화가 쉽고.
DB쪽은 의존을 해야하지만, 의존성 역전을 통해 해결하면 된다.
이제 컨트롤러 차례인데 아직 문제가 있다.
컨트롤러는 Service, Repository, Domain 3개에 대한 모든 의존성을 가져야 한다. -> 이는 귀찮고 힘들다.
따라서 컨트롤러도 역전을 한다.
수업시간에 의존성 역전, SOLID 아무리 들어도 언제 어떻게 적용시켜야 하는지는 몰랐는데. 내가 그걸 못지키고 있었고 생각보다 적용이 쉽다...
뒷통수가 얼얼하네...
추가적인 팁
이 부분은 강사님 개인적인 의견이고 회사, 조직, 팀, 개인 마다 모두 생각이 다르다고 한다.
-
먼저 Controller와 Repository는 잘 하지 않을려고 한다고 한다.
이유는 이 부분에 필요성을 못느껴서 그렇다는데- 컨트롤러: 서비스만 호출함 -> 스프링이 알아서 테스트
- Repository: 어차피 JPA 팀에서 알아서 함
이지만. 의견은 다를 수 있다.
- ? 커버리지가 너무 낮은데요
이에 대한 해답은 도메인이 그만큼 빈약하다 -> 서비스의 경쟁력 의심 으로 연결된다고 한다.
-
테스트 방법에 따라 중형, 소형, 대형이 나뉜다.
-
패키지 관리를 레이러로 분류하면 도메인이 안보여서 어렵다.
- 따라서 도메인에 집중해서 나눈다.
- MSA 확장성도 가질 수 있다는 장점이 있다.
-
패키지 관리 이후, 도메인끼리의 순환 참조가 일어나면 안된다
- 해악이 정설이다.
지금까지 코드가 더럽다고 느끼고 있었는데 왜 더러웠는지 잘 긁어줬다고 생각한다.
