[TIL] 스프링 테스트(BDD), 도메인 주도 개발(DDD)

✍ 이 글은 제가 오늘 공부하거나 코딩하며 배우거나 느꼈던 것들을 적는 글이므로,
해라체를 사용하는 것을 이해해주시면 감사하겠습니다.

 

스프링 테스트 - 행동 기반 개발 (BDD)

요즘 열심히 야매 BDD를 하는 방법을 익히고 있다. 이제는 스프링에서 테스트가 어떻게 돌아가는지를 대충 알 것 같다.

테스트는 중요하다는 것을 많이 느끼고 있다. 테스트가 중요한 이유 2가지:

1. 코드를 작성해보고 입출력을 직접하는 것이 아니라 테스트를 자동화해서 코딩 시간을 단축시킨다.
2. 내 코드가 원하는대로 작동이 됨을 증명하는 수단으로써 이용할 수 있어서 안심이 된다.

위는 테스트에 대한 내용이라면, BDD는 요구사항에 대해서 중요하다.
백문이 불여일견이다. 다음은 내가 작성한 BDD 코드이다.

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class PostRepositoryTest extends TestSettings {

  @Autowired
  private PostRepository postRepository;

  private List<Post> postList;

  @BeforeAll
  public void beforeAll() {
    postList = PostTestFactory.createTestPostList();
    postRepository.saveAll(postList);
  }

  @DisplayName("페이지를 설정해서 PostList를 가져올 수 있다.")
  @ValueSource(ints = {1, 3, 5, 7, 10})
  @ParameterizedTest
  void shouldSuccessToGetPostList(int size) {
    // given
    Pageable pageable = Pageable.ofSize(size);

    // when
    Page<Post> response = postRepository.findAllByOrderByCreatedAtDesc(pageable);

    // then
    int expected = postList.size() / size;
    if (postList.size() % size > 0) expected++;
    assertEquals(expected, response.getTotalPages());
  }
}

위 메소드의 요구사항은 대충 "사용자는 페이지 크기(size)가 주어지면 그 페이지 만큼의 글(Post)을 얻어올 수 있어야 한다." 정도가 되겠다. 이 요구사항을 그대로 구현해 놓은 코드가 되시겠다.(아닌가?)
사실 위 코드는 주석에 주목해야 된다. 주석이 세 개 있을 것이다.

• given : 테스트에 필요한 준비 작업을 수행한다.
• when : 테스트 진행 작업을 수행한다.
• then : 테스트가 완료 된 후의 결과 상태를 확인하는 작업을 수행한다.

given으로 준비를 하고(위 코드에서는 ParameterizedTest 때문에 saveAll이 반복 수행되는 문제 때문에 given에 넣을 내용을 BeforeAll 메소드에 넣었다.), when으로 수행을 하고, then으로 결과를 도출하는 식으로 가는 것이다.

 

처음 테스트 코드를 봤을 때, 어떻게 코드를 짤지 정말정말 막막했다. 그래서 여러 책을 사서 보거나, 구글링을 하거나 해도 손이 안가고, 필요성을 느끼지 못했다. 하지만 BDD를 만나고 내인생이 달라졌다(서울xxx대학에 다니고~). 테스트하는 그 자체의 방법론을 정해놓은거다. 위키피디아를 보니 내용과 예제가 더 있었다(영어라서 생략한다). 자세한건 위키피디아링크

 

도메인 주도 개발 (DDD)

오후에 코딩한다고 책을 보겠다는 다짐이 깨질 무렵, 밤늦게 부랴부랴 5년 전에(...) 샀던 DDD 책을 펼쳐보았다. 읽어야지 읽어야지 한게 5년이 지났다ㅋㅋ

 

대충 내용을 보아하니... 기본적으로 스프링에서 다루는 컨트롤러-서비스-DAO의 흐름은 지켜지는 방법론이었다.
그리고 이 도메인이란 친구는...... 데이터에 의미를 두었다 정도? 인 것 같다.

 

보통 스프링 개발을 할 때, 엔티티는 DTO 하나면 충분하다고 보았다.. 그런데 DDD에서는 다른 부분이 있었다. 엔티티는 테이블 모델로써의 객체와, 변하지 않는 데이터를 가지고 있는 객체 두가지를 가지고 있었다.

• Entity : 테이블 모델
• Value Object(VO) : 변하지 않는(불변=Getter밖에 없는) 객체

불변 객체가 중요함은 뭐... 개발하다보면 알게 되긴 한다. 나도 모르게 사이드 이펙트를 일으키게 될 수 있는 위험이 언제나 도사리고 있다는 것을.....(넘모 무섭다)

 

VO는 스프링을 배울 때 잠깐 스쳐지나가는 용어로 어렴풋이는 알았는데, Aggregate라는 용어는 처음 알게 되었다. 영어 뜻 그대로 객체 종합선물세트다. 여러 Entity랑 VO랑 합친거다. 합치다보니 CRUD할 때 문제가 많이 생기니까 그걸 해결하려는 내용이 책의 거의 반(...)이었다. 대충 훑어보기만 했다. ㅎㅎ

 

아, 또 중요한건 레이어를 4개로 나누었다는 것이었다. 프레젠테이션-애플리케이션-도메인-인프라스트럭쳐로 나누었다.
스프링의 3개 레이어랑 다른 점이 있다면? 컨트롤러에서도 DAO를 사용하는 자유로움이 있다 정도? 직접 코딩해봐야겠다~