스프링 스터디 2주차

스프링 스터디 2주차 : 김영한 스프링 입문강의 8,9,10강

 

8강 : 비즈니스 요구사항 정리

데이터 : 회원 id,이름

기능 : 회원등록, 조회

아직 데이터 저장소 선정되지 않음(시나리오)

 

 

출처 : 김영한의 스프링 입문강의 강의안

 

일반적인 웹 애플리케이션 계층 구조

- 컨트롤러 : 웹 mvc의 컨트롤러 역할

- 서비스 : 핵심 비즈니스 로직 구현(ex.회원id 중복 금지 로직 등)

- 도메인 : 회원,주문,쿠폰 등등 주로 db에 저장되고 관리되는 비즈니스 도메인 객체

- 리포지토리 : db에 접근, 도메인 객체를 db에 저장하고 관리함

 

출처 : 김영한의 스프링 입문강의 강의안

 

클래스 의존관계

- 회원 비즈니스 로직에 회원서비스가 있고, 회원 리포지토리(회원을 저장하는 것)는 인터페이스로 구현 -> 이유 : 아직 데이터 저장소가 선정되지 않아서, 우선 인터페이스로 구현 클래스를 추후 변경할 수 있도록 설계

- 우선 구현체로는 가벼운 메모리 기반의 데이터 저장소 사용

 

 

9강 : 회원 도메인과 리포지토리 만들기

먼저 위의 위치에 domain 패키지,member클래스를 만든다

 

member클래스를 위와 같이 만들고, 회원 리포지토리(회원 객체 저장하는 저장소)를 만들러~

 

 

 

이제 구현체를 만들자

 

implements MemberRepository까지 쓰고 우클릭해서 implements method누르면 override해야하는 내용들을 위와같이 자동으로 불러와준다

 

이렇게 구현이 끝났다

-> 이게 제대로 동작하는지 어떻게 검증?

-> 테스트케이스 작성!

 

 

10강 : 회원 리포지토리 테스트케이스 작성

- java의 메인메소드를 통해 실행하거나, 웹 애플리케이션의 컨트롤러로 실행가능, 그러나 이러한 방식은 준비/실행이 오래걸리고 반복실행하기 어렵다 -> 자바는 JUnit이라는 프레임워크로 테스트를 실행한다

 

위와 같은 경로에 패키지와 테스트클래스를 만든다

 

위와 같이 코드를 입력하고 실행해보면, save가 실행된 것 확인가능(왼쪽 하단)

 

 

생성한 멤버객체와 리포지토리에서 꺼낸 result가 같다고 뜨는 모습

 

 

Assertions를 사용하면, 기대하는 객체와 실제 저장소에서 찾아낸 객체가 같다면 test passed와 함께 녹색불이 뜬다

다르면 test failed가 뜸

 

 

 

 

findByName도 위와 같이 테스트한다

 

테스트케이스의 장점은 한번에 여러개 같이 돌릴 수 있다

 

그런데 테스트 여러개 같이 돌리면 - 순서 보장 안됨 - 객체끼리 충돌해서 원치않는 결과 나올 수 있다

-> 테스트 하나 끝나고 나면 객체를 clear를 해줘야함! (테스트 순서들 사이에 의존관계 없도록)

 

MemoryMemberRepository에 위와 같은 코드를 추가한 후

 

 

테스트코드에 위 부분을 추가한다 (매 테스트가 끝날때마다 clearStrore()를 하라는 의미)