우아한 테크 캠프 PRO 2기 - 3주차 인수 테스트 주도 개발 후기

ATDD

3주차가 끝나버렸다.

3주차는 지하철 관리 프로그램을 ATDD 기반으로 개발하는 것이 목표였다!

ATDD자체는 어려운 개념이 아니였다.

그냥 TDD앞에 인수 테스트라는 전구간 테스트를 먼저 작성해두고 그 아래에서 TDD를 진행하면 된다. 인수 테스트를 한 번 작성해두면, 단위 테스트 처럼 자주 바뀔 일이 없고, 지금 개발하려고하는 내용의 방향과 목표를 확실하게 잡아주는 역할을 하기 때문에 TDD할 때 가장 많이 고민하게 되는 "뭘 테스트해야하지?"라는 고민을 많이 해결할 수 있어서 개발자가 인수 테스트를 작성하는 수고스러움에 비해 더 많은 장점이 있는 설계 방법이라고 생각되었다.

앞으로는 나도 ATDD 기반으로 개발을 할 수 있도록 해야겠다.

 

JPA

3주차는 지하철 관리 프로그램을 개발하였는데, JPA를 아주 복잡한 실무와 같은 예제에서 다뤄보는 정말 좋은 미션이었다.

지하철은 노선, 역, 구간이라는 도메인이 존재하였고 이 도메인들의 관계를 정의하고 도메인 모델 패턴으로 개발하였다. 이번 경험으로 배운 두 가지가 있다.

도메인 관계

1. 도메인을 바라보는 관점에 따라 엔티티 관계가 달라질 수 있다.

도메인 지식이 얕았던 개발 초기 단계에서는 노선이 역과 구간을 포함하고 있고, 역은 노선 두개를 포함하고 노선은 역 두개를 포함하는 관계로 생각하였다.

그래서 나는 역구간(StationSection)이라는 중간 매핑 테이블을 두고 역과 구간의 다대다 관계를 풀었다.

StationSection은 역, 구간, 역타입(상행인지 하행인지)로 구성되어 하나의 역구간을 정의하였다. 하지만 이 복잡한 설계가 후에 구간 추가, 구간 제거 기능에서 엄청난 복잡도를 발생시킨다는 것을 안것은 이틀의 삽질 후였다..ㅠ 구간을 추가하고 제거할때 마다 신경써야하는 연관관계들이 너무 많았기 때문이다.

결국 복잡도를 낮추기 위해 역은 하행구간을 참조하고 구간은 하행역을 참조하는 일대일관계로 변경하였다. 다대다 관계에서 일대일 관계로 복잡도를 낮추니 구간 추가, 제거 기능도 정말 심플하게 해결되는 경험을 할 수 있었다.

2. 영속성 전이를 함부로하면 안되는 이유(도메인 생명주기)

또한 영속성 전이를 함부로하면 안되는 이유도 경험할 수 있었다.

StationSection은 부모가 Station, Section 이렇게 두 개이다. 그런데 양쪽 부모에서 persist에 대해 영속성 전이를 하고 있다면 어떻게 될까? StationSection이 DELETE되지 않는 문제가 발생한다.

A Station을 제거하여 관련된 StationSection을 영속성 전이에 의해 제거하려고 시도하여도 Section에서 다시 persist를 영속성 전이하고 있기 때문에 JPA는 아무일도 하지 않게 되는것이다. 그럼 A Station를 제거하려고 할 때, StationSection에서 fk로 참조하고 있어 제거가 되지 않는 오류가 발생한다.

그래서 영속성 전이는 정말 깊게 생각해야할 것 같다. 생명주기가 Station과 Section은 생명주기가 다르기 때문에 같은 애그리거트가 아니여서 영속성전이는 하면 안된다.