이번주 학습 내용

각 컨트롤러, 서비스, DAO 부분에서 테스트 하는 방법을 공부했다.

Persistence Layer

Persistence Layer란, CRUD 가 일어나는, DataBase 를 통해 값을 저장하거나, 읽어오는 부분의 역할에 대한 테스트 이다.

간단한 조건을 통해 (Where 구문이 포함된) 데이터를 조회하게 될 때, 내가 의도한 조건으로 필터링 된 데이터가 잘 도착하는지 검사할 떄나,

데이터를 저장하거나, 수정하는 로직의 경우, 어떤 부분을 어떤 방법으로 수정하는지와, 수정된 값이 내가 의도한 대로 잘 작동하는지 확인을 하기 위한 테스트이다.

위 테스트는 비지니스에 대한 로직이 포함되어서는 안되며, CRUD 쿼리 자체를 검증하는 부분이라고 봐야한다.

Business Layer

Business Layer 에서는 실제 우리 도메인에서 가진 서비스단에서 수행되는 Business 로직에 대해서 검증하며, Persistence Layer 의 테스트를 포함해 작성하는 것이 좋다.

성공 케이스인 A 메소드를 수행해 저장된 값이 1 > 2로 변경되는 부분에 대해서도 당연히 테스트가 진행되어야 하지만, A메소드 수행 도중 예외 상황을 만났을 때, 어떤 메시지를 가진 예외가 발생하는지 까지 테스트에 포함되어야 한다.

그리고, 비즈니스 로직을 수행하다가 실패할 경우, 한 단위의 트랜잭션에 포함 시켜, 수행 이전 상태로 돌아가도록 설정해야 한다.

추가적으로, 서비스에 대한 설계가 이루어 질때, 항상 요구사항을 정리 후, 테스트 부터 작성하고 예외의 경우는 무엇이 있으며, 해당 상황의 경계값 테스트를 통해 로직에 기반한 테스트를 하지 않도록 가장 주의해서 작성해야 하는 부분이라고 생각한다.

Presentation Layer

Presentation Layer 에서는 외부 세계로 부터 데이터를 받아오는 Controller 에 대한 테스트를 주로 담고 있으며, 요청되는 파라미터 값에 대한 큰 기준의 유효성 체크 (빈 값이 들어오면 안되는 값) 등에 대한 검증을 할 수 있으며, Controller 계층은 Service 와 의존관계를 거의 항상 맺고있기 때문에, 외부에서 넘어오는 값에 대해 검증을 위해서, 하위 계층에서 일어나는 일들을 Mocking 처리하고, 하위 계층에서 일어날 Business 로직에 대해서는 위 Business Layer 와 Persistence Layer 에서 검증할 수 있도록 한다.

위 상황에서 보면, Presentation Layer 와 Business Layer 에서 각각 유효성 체크를 하고 있는 것을 한 곳으로 묶는게 어떨지에 대한 생각이 들 수 있다.

하지만, VO 단위에서 예외로 생각되는 부분과 내가 작성한 비지니스 로직에서 생각되는 예외를 분리해 처리함으로 서, 좀더 명확한 Exception Message 를 가진 상세한 예외를 처리할 수 있으며, 동일한 메소드가 재사용 되기 위해서는 VO에서는 특정 비지니스 로직에 종속되지 않은 범용적 예외 상황에 대해서만 처리 되도록 작성해야 하며,

이를 항상 염두에 두고 한 설계를 하도록 하자!

좋았던점 (Liked)

이전에 테스트를 설계하면서 테스트가 어렵다 생각하고, TDD방식을 지키며 하지 못했던 내 사고의 방식이 어떤식으로 변경되어야 하는지 조금은 알아가고 있는 것 같다.

아쉬웠던 점 (Lacked)

이번주도, 신경쓸 시간이 많이 없어 미션이 아직 밀려 있는 부분이 있다. Day 18 미션은 적어도 월요일까지 스스로라도 완료할 예정이다..

배운 점 (Learned)

어느정도 범위까지 테스트가 작성되어야 하는지, 내가 작성하면서느낀 테스트의 필요성을 이미 강의에서 설명해주고 계서서 많은 도움이 됬다.

앞으로 바라는 점(Longed for)

다음주 금요일 이전까지 남은 강의와 미션들을 전부 마무리 해보면서 비록 진도표 대로 따라가진 못했지만, 내 스스로라도 마무리 할 수 있도록 마무리하겠다!