지난 주에는 MVC, API, Restful 에 대한 공부를 해봤다.
이번주에는 MVC에서 Controller와 서비스, 리포지토리와 그들의 관계에 대한 이야기를 할 것이며 TDD에 대한 이야기를 다룰 예정이다.
1. 컨트롤러, 서비스, 리포지토리의 역할
컨트롤러
웹 MVC에서 언급한 Controller와 동일하다. 지난주 WIL에서 컨트롤러를 '사용자의 응답을 바탕으로 비즈니스 로직을 담당하는 역할이다. 사용자의 입력으로 데이터가 업데이트 되면 이를 처리한 후 업데이트된 모델을 뷰로 전달하는 역할을 한다.'라고 언급했다. 컨트롤러는 실제 사용자의 요청이 들어오면 적절하게 이를 처리하거나 처리할 수 있는 로직을 호출한다. 이때 호출되는 로직이 서비스이다.
컨트롤러가 하는일에 대한 예시를 들어보자.
어떤 프로그램에서 A,B,C 3가지의 서비스가 필요하다고 하자. 이 경우 3기능을 한 클래스에 몰아넣는 것이 아니라 요청에 따라 받은 요청이 A요청이면 A 컨트롤러를, B면 B컨트롤러를 호출하고 이에 맞는 로직을 처리한다.
서비스
실제 핵심 비즈니스 로직이 구현되는 클래스이다. 컨트롤러가 클라이언트에게 요청을 받으면 클라이언트가 제공한 파라미터와 함께 로직 처리를 위해 서비스를 호출한다. 서비스는 관련 요청을 처리하기 위해 데이터베이스(리포지토리)에 접근하기도 하며 비즈니스 로직에 따라 알맞게 데이터를 가공하고 이를 다시 컨트롤러에게 넘긴다.
회원 가입을 할때 중복회원 방지하며 회원 가입을 한다고 하자. 컨트롤러는 해당 요청을 확인하여 회원 가입 로직을 구현한 서비스를 호출한다. 해당 서비스는 중복회원을 방지하기 위해 회원 가입하려는 회원이 이미 가입했는지를 리포지토리에서 같은 이름을 조회해 확인하고, 없으면 리포지토리에 새로운 회원을 등록한다.
도메인
비즈니스 도메인의 객체를 의미한다. 가령 회원이 무언가를 주문하고 쿠폰에 따라 할인하는 프로그램이라면 이 프로젝트의 도메인은 '회원', '주문', '쿠폰'등을 의미한다. 이들은 데이터베이스에 저장하고 관리된다.
리포지토리
도메인 객체를 DB에 저장하고 관리하기 위해 데이터베이스에 접근하는 부분을 의미한다. 데이터베이스에 정보를 '저장'하거나 특정 조건에 따라 '조회'할 수 있고 삭제나 수정에 대한 기능과 같은 DB 접근 기능을 제공한다.
서비스나 다른 클래스에게 데이터와 관련된 요청을 받고 처리한다.
이들의 관계
정리하자면 사용자에게 요청을 받은 컨트롤러가 이 로직을 처리하기 위한 서비스를 호출하고 서비스는 리포지토리에서 적절한 정보를 가져온다. 리포지토리는 DB나 지정된 저장소에서 결과를 서비스에게 제공하고 서비스는 이를 바탕으 비즈니스 로직을 처리한 후 결과 데이터를 컨트롤러에게 넘기는 것이다.
2. TDD란? 하는 이유는?
TDD란?
소프트웨어 개발 방법론 중 하나로 Test Driven Development의 약자이며 테스트 주도 개발을 의미한다.
즉, 개발을 시작할때 실제 코드를 먼저 작성하는 것이 아닌, 테스트 코드를 먼저 작성하는 것부터 개발을 시작하는 것을 의미한다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스로 짧은 주기를 가진만큼 일정한 사이클을 갖는데 이 사이클을 'Red - Green 사이클'이라고 한다.
레드 그린 사이클
- Red : 항상 실패하는 테스트를 먼저 작성한다. (테스트 케이스 위주로)
- Green : 테스트가 통과하는 프로덕션 코드를 작성한다.
- Refactor : 테스트가 통과하면 프로덕션 코드를 refactoring.
우선, 어떤 기능을 만들기 위해서, 그 기능이 실패하는 테스트 코드를 작성한다.
Red 단계에선 실제 기능을 추가해주지 않고 테스트 케이스 가령 1과 2를 더하면 3이 나오는지 확인하는 코드들을 작성해준다. 이 때 실제 기능은 작성되어있지 않으므로, 테스트가 당연히 실패할 것이다.
이어서 Green 단계에서 해당 테스트를 통과하기 위한 적절한 기능 코드를 추가하고 Blue에서 리팩토링을 하는 것이다.
Red 단계에서 테스트 케이스를 작성할때는 Edge Case 위주로 생각해서 작성해주자.
if (a>=10) 에 대해 이야기를 하고 있으면, 9,10,11을 위주로 나올 결과를 확인해주자는 의미이다.
또한, 실패하는 경우에 대한 케이스도 꼭 작성해야한다. 가령 VIP에게 1000원을 할인해준다고 가정하고 이 기능을 만들때 우리는 VIP가 아닌 일반회원에게는 할인을 해주면 안된다. 따라서, 일반회원이 할인을 요구할 때 할인금액이 0원인 케이스까지 만들어야한다.
*단위 테스트란?
TDD의 첫번째 단계인 기능 단위 테스트 코드를 작성하는 것으로 테스트 코드를 먼저 작성할 필요가 없다는 점, 리펙토링이 포함되지 않는다는 점에서 TDD와 다름.
단순 테스트 코드 작성하는 것만을 의미함
*TDD를 하는 이유?
개발 과정에서 기능을 만들고 기능 단위로 테스트를 진행한 이후에 추후에 이를 통합해서 시스템 단위의 테스트를 진행해야한다.
TDD를 하면 다음과 같은 장점을 얻을 수 있다.
- 개발 단계 초기에 문제 발견해 빠른 피드백이 가능하다.
짧은 주기의 개발방법으로 기능 단위로 테스트를 진행하기에 전체 시스템 단위로 넘어가 테스트를 진행하기 전에 문제를 발견하고 해결할 수 있다.
- 불확실성이 감소한다.
내가 작성한 코드가 내손을 떠나 전체 시스템 단위의 테스트가 진행되는 과정에서 이미 기능에 대한 검증을 끝내기에 불확실성을 감소하고 전체 단위의 테스트를 진행할 수 있다.
또한 새 기능이 추가 되었을때 기존의 기능이 잘 작동하는지 확인할 수 있다. 기존 기능에 대한 테스트 코드를 만들어 놓고 해당 코드가 잘 돌아가는지 확인화면 가능하기 때문이다.
- 테스트 자체가 시스템에 대한 실제 문서 역할.
테스트 과정에서 작성한 테스트케이스, 테스트 코드 히스토리가 다 기록에 남는다. 이 자체가 하나의 문서가 되어 과거의 나와 기획자가 어떤 마인드로 기능을 추가했는지 기능을 뺐는지를 기억할 수 있다.
Tip : 테스트 코드 작성 프레임 워크
JUnit - Java
지난 주에는 MVC, API, Restful 에 대한 공부를 해봤다.
이번주에는 MVC에서 Controller와 서비스, 리포지토리와 그들의 관계에 대한 이야기를 할 것이며 TDD에 대한 이야기를 다룰 예정이다.
1. 컨트롤러, 서비스, 리포지토리의 역할
컨트롤러
웹 MVC에서 언급한 Controller와 동일하다. 지난주 WIL에서 컨트롤러를 '사용자의 응답을 바탕으로 비즈니스 로직을 담당하는 역할이다. 사용자의 입력으로 데이터가 업데이트 되면 이를 처리한 후 업데이트된 모델을 뷰로 전달하는 역할을 한다.'라고 언급했다. 컨트롤러는 실제 사용자의 요청이 들어오면 적절하게 이를 처리하거나 처리할 수 있는 로직을 호출한다. 이때 호출되는 로직이 서비스이다.
컨트롤러가 하는일에 대한 예시를 들어보자.
어떤 프로그램에서 A,B,C 3가지의 서비스가 필요하다고 하자. 이 경우 3기능을 한 클래스에 몰아넣는 것이 아니라 요청에 따라 받은 요청이 A요청이면 A 컨트롤러를, B면 B컨트롤러를 호출하고 이에 맞는 로직을 처리한다.
서비스
실제 핵심 비즈니스 로직이 구현되는 클래스이다. 컨트롤러가 클라이언트에게 요청을 받으면 클라이언트가 제공한 파라미터와 함께 로직 처리를 위해 서비스를 호출한다. 서비스는 관련 요청을 처리하기 위해 데이터베이스(리포지토리)에 접근하기도 하며 비즈니스 로직에 따라 알맞게 데이터를 가공하고 이를 다시 컨트롤러에게 넘긴다.
회원 가입을 할때 중복회원 방지하며 회원 가입을 한다고 하자. 컨트롤러는 해당 요청을 확인하여 회원 가입 로직을 구현한 서비스를 호출한다. 해당 서비스는 중복회원을 방지하기 위해 회원 가입하려는 회원이 이미 가입했는지를 리포지토리에서 같은 이름을 조회해 확인하고, 없으면 리포지토리에 새로운 회원을 등록한다.
도메인
비즈니스 도메인의 객체를 의미한다. 가령 회원이 무언가를 주문하고 쿠폰에 따라 할인하는 프로그램이라면 이 프로젝트의 도메인은 '회원', '주문', '쿠폰'등을 의미한다. 이들은 데이터베이스에 저장하고 관리된다.
리포지토리
도메인 객체를 DB에 저장하고 관리하기 위해 데이터베이스에 접근하는 부분을 의미한다. 데이터베이스에 정보를 '저장'하거나 특정 조건에 따라 '조회'할 수 있고 삭제나 수정에 대한 기능과 같은 DB 접근 기능을 제공한다.
서비스나 다른 클래스에게 데이터와 관련된 요청을 받고 처리한다.
이들의 관계
정리하자면 사용자에게 요청을 받은 컨트롤러가 이 로직을 처리하기 위한 서비스를 호출하고 서비스는 리포지토리에서 적절한 정보를 가져온다. 리포지토리는 DB나 지정된 저장소에서 결과를 서비스에게 제공하고 서비스는 이를 바탕으 비즈니스 로직을 처리한 후 결과 데이터를 컨트롤러에게 넘기는 것이다.
2. TDD란? 하는 이유는?
TDD란?
소프트웨어 개발 방법론 중 하나로 Test Driven Development의 약자이며 테스트 주도 개발을 의미한다.
즉, 개발을 시작할때 실제 코드를 먼저 작성하는 것이 아닌, 테스트 코드를 먼저 작성하는 것부터 개발을 시작하는 것을 의미한다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스로 짧은 주기를 가진만큼 일정한 사이클을 갖는데 이 사이클을 'Red - Green 사이클'이라고 한다.
레드 그린 사이클
- Red : 항상 실패하는 테스트를 먼저 작성한다. (테스트 케이스 위주로)
- Green : 테스트가 통과하는 프로덕션 코드를 작성한다.
- Refactor : 테스트가 통과하면 프로덕션 코드를 refactoring.
우선, 어떤 기능을 만들기 위해서, 그 기능이 실패하는 테스트 코드를 작성한다.
Red 단계에선 실제 기능을 추가해주지 않고 테스트 케이스 가령 1과 2를 더하면 3이 나오는지 확인하는 코드들을 작성해준다. 이 때 실제 기능은 작성되어있지 않으므로, 테스트가 당연히 실패할 것이다.
이어서 Green 단계에서 해당 테스트를 통과하기 위한 적절한 기능 코드를 추가하고 Blue에서 리팩토링을 하는 것이다.
Red 단계에서 테스트 케이스를 작성할때는 Edge Case 위주로 생각해서 작성해주자.
if (a>=10) 에 대해 이야기를 하고 있으면, 9,10,11을 위주로 나올 결과를 확인해주자는 의미이다.
또한, 실패하는 경우에 대한 케이스도 꼭 작성해야한다. 가령 VIP에게 1000원을 할인해준다고 가정하고 이 기능을 만들때 우리는 VIP가 아닌 일반회원에게는 할인을 해주면 안된다. 따라서, 일반회원이 할인을 요구할 때 할인금액이 0원인 케이스까지 만들어야한다.
*단위 테스트란?
TDD의 첫번째 단계인 기능 단위 테스트 코드를 작성하는 것으로 테스트 코드를 먼저 작성할 필요가 없다는 점, 리펙토링이 포함되지 않는다는 점에서 TDD와 다름.
단순 테스트 코드 작성하는 것만을 의미함
*TDD를 하는 이유?
개발 과정에서 기능을 만들고 기능 단위로 테스트를 진행한 이후에 추후에 이를 통합해서 시스템 단위의 테스트를 진행해야한다.
TDD를 하면 다음과 같은 장점을 얻을 수 있다.
- 개발 단계 초기에 문제 발견해 빠른 피드백이 가능하다.
짧은 주기의 개발방법으로 기능 단위로 테스트를 진행하기에 전체 시스템 단위로 넘어가 테스트를 진행하기 전에 문제를 발견하고 해결할 수 있다.
- 불확실성이 감소한다.
내가 작성한 코드가 내손을 떠나 전체 시스템 단위의 테스트가 진행되는 과정에서 이미 기능에 대한 검증을 끝내기에 불확실성을 감소하고 전체 단위의 테스트를 진행할 수 있다.
또한 새 기능이 추가 되었을때 기존의 기능이 잘 작동하는지 확인할 수 있다. 기존 기능에 대한 테스트 코드를 만들어 놓고 해당 코드가 잘 돌아가는지 확인화면 가능하기 때문이다.
- 테스트 자체가 시스템에 대한 실제 문서 역할.
테스트 과정에서 작성한 테스트케이스, 테스트 코드 히스토리가 다 기록에 남는다. 이 자체가 하나의 문서가 되어 과거의 나와 기획자가 어떤 마인드로 기능을 추가했는지 기능을 뺐는지를 기억할 수 있다.
Tip : 테스트 코드 작성 프레임 워크
JUnit - Java
