비즈니스 요구사항 정리
- 컨트롤러: 웹 MVC의 컨트롤러 역할
- 서비스: 비즈니스 도메인 객체를 가지고 핵심 비즈니스 로직 구현, 예) 회원 중복 가입 X
- 리포지토리: 데이터베이스에 접근, 도메인 객체를 DB에 저장하고 관리
- 도메인: 비즈니스 도메인 객체, 예) 회원, 주문, 쿠폰 등등 주로 데이터베이스에 저장하고 관리됨
* Optional
: findbyId, findbyname 했을 때 없으면 null을 반환한다. (요즘은 null을 처리하는 방법에서 null을 그대로 반환하는 방법 대신, optional로 감싸서 반환하는 방법을 많이 선호한다.)
* sequence
: 0, 1, 2 이렇게 키 값을 형성해주는 아이.
회원 리포지토리 테스트 케이스 작성
개발한 기능을 실행해서 테스트할 때 자바의 main 메서드를 통해서 실행하거나, 웹 애플리케이션의 컨트롤러를 통해서 해당 기능을 실행한다. 이러한 방법은 준비하고 실행하는데 오래 걸리고, 반복 실행하기 어렵고 여러 테스트를 한 번에 실행하기 어렵다는 단점이 있다. 자바는 JUnit이라는 프레임워크로 테스트를 실행해서 이러한 문제를 해결한다.
✔︎ 테스트 케이스 작성할 때
- 패키지는 같은 이름으로 만들고, 테스트 클래스 이름의 관례는
클래스 이름Test
이렇게 만든다. - !!! 테스트 케이스 짤 때 순서에 의존해서 짜면 안 된다!!!
- 테스트 순서 보장 안된다. 따라서 모든 테스트는 순서 상관없이, 의존관계없이 메소드 별로 다 따로 동작하도록 메소드 짜야함.
- 그러기 위해선 하나의 테스트가 끝날 때마다 저장소나 공용 데이터들을 깔끔하게 지워줘야 한다.
- 클래스에서 command + shift + t 해주면 테스트 껍데기를 자동으로 만들어 준다. (패키지도 똑같이 만들어줌)
✔︎ 개발을 끝낸 다음에 테스트를 작성할 수 있지만, 테스트 클래스를 먼저 작성 한 다음에 개발할 수 있다.(순서 뒤집기)
틀을 먼저 만든다고 생각하면 된다. 이게 테스트 주도 개발(TDD)이다. 테스트 먼저 만들고 구현 케이스 만들어서 돌려보는 것이다.
자세한 내용 클릭☞ TDD(테스트 주도 개발)
✔︎ 테스트 코드 없이 개발하는 것은 거의 불가능(소스코드 베이스가 몇 만 라인 이렇게 넘어가면). 따라서 테스트 관련 공부해야 한다.
회원 서비스 개발
- 회원 서비스는 회원 리포지토리랑 도메인을 활용해서 실제 비즈니스 로직을 작성하는 것.
- 서비스 클래스는 네이밍이 비즈니스에 가깝고 또 그렇게 써야 한다. 왜냐하면 기획자랑 이야기할 때 서비스는 비즈니스에 의존적으로 설계를 하기 때문이다. ( repository는 서비스보다는 단순히 기계적으로 개발스럽게 용어 선택한다. )
회원 서비스 테스트
✔︎ 테스트는 메소드 이름을 한글로 해줘도 된다. 한글로도 많이 적는다.(영어권 사람들과 일하는 거 아니면)
✔︎ 테스트가 길 때는 아래처럼 주석을 달아주면 도움 많이 된다. (상황에 따라 안 맞기도 하지만 이렇게 하면서 바꿔나가는 것을 추천)
- given: 상황 주어지면
- when: 이걸로 실행했을 때 (뭘 검증할 거냐)
- then: 이렇게 결과 나와야 해 (검증하기)
✔︎ 테스트는 정상 플로우도 중요하지만, 예외 플로우가 훨씬 중요하다.
✔︎ @AfterEach : 한번에 여러 테스트를 실행하면 메모리 DB에 직전 테스트의 결과가 남을 수 있다. 이렇게 되면 다음 이전 테스트 때문에 다음 테스트가 실패할 가능성이 있다. @AfterEach 를 사용하면 각 테스트가 종료될 때 마다 이 기능을 실행한다. 여기서는 메모리 DB에 저장된 데이터를 삭제한다.
✔︎ @BeforeEach : 각 테스트 실행 전에 호출된다. 테스트가 서로 영향이 없도록 항상 새로운 객체를 생성하고, 의존 관계도 새로 맺어준다.
class MemberServiceTest {
MemberService memberService;
MemoryMemberRepository memberRepository;
@BeforeEach
public void beforeEach() {
// new로 다른 객체 repository생성되면 혹시라도 다른 인스턴스이기 때문에 내용 달라지거나 할 수 있다.
// 같은 Repository로 테스트 하는 게 맞는건데, 다른 repository를 이용하고 있는 것임
// 따라서 같은 인스턴스 쓰도록 만들어야한다.
// 외부에서 넣어주도록 바꿔주기 ! 직접 new해서 생성하는 것이 아니고 !!!
// @BeforeEach로 동작하기 전에 넣어준다.
// 이렇게 하면 테스트 하기 전에 각각 생성해준다.
// MemoryMemberRepository를 만들고 위에 넣어놓고 MemberService에 넣어준다.(서비스파일에 있는거)
// 그럼 같은 MemoryMemberRepository를 사용하게 되는 것
// 이렇게하면 MemberService입장에서 직접 new하지 않고 외부에서 MemoryMemberRepository를 넣어준다.
// 이런것을 DI라고 한다.
memberRepository = new MemoryMemberRepository();
memberService = new MemberService(memberRepository);
}
참조
이 게시물은 인프런 > 김영한님의 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술의 강의를 토대로 작성한 게시물입니다.
'Web > Spring' 카테고리의 다른 글
스프링 DB 접근 기술 (0) | 2021.07.25 |
---|---|
스프링 빈과 의존관계 / 웹 MVC 개발 (0) | 2021.07.25 |
스프링 웹 개발 기초(정적 컨텐츠, MVC와 템플릿 엔진, API) (0) | 2021.07.24 |
스프링 프로젝트 환경설정 (0) | 2021.07.20 |
Application Scope (0) | 2021.06.24 |