회원관리 예제

참고 강의:https://www.inflearn.com/roadmaps/373

비즈니스 요구 사항 정리

데이터: 회원ID, 이름

기능: 회원 등록, 조회

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

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

Untitled

  • 위 서비스는 안드로이드의 유스케이스로 생각하는게 편할것으로 보임

도메인과 리포지토리

  • Optional - java8에 생김, 일반적으로 null 대신 Optional 로 데이터를 감싸서 사용 한다.
  • 리포지토리를 사용함으로써 구체적인 데이터 저장소를 정하지 않아도(정해지지 않은경우 보다 쉬운 방식을 통해 미리 개발이 가능함) 구현체를 변경함으로써 추 후 요구사항의 변경이나 데이터 저장소 변경등의 대응에 용이하도록 한다.

리포지토리 테스트 케이스 작성

  • 개발한 기능의 동작이 정상적인지 검증하기 위해 테스트 케이스를 작성한다.
    • 자바의 main 메서드를 통해서 실행하거나, 웹 애플리케이션의 컨트롤러를 통해 해당 기능을 실행하는 방법은 시간이 오래걸리며, 반복 실행, 여러 테스트를 한번에 실행하기에 어렵다
    • 위와같은 문제를 해결하기 위해자바는 Junit이라는 프레임웨크를 통해 테스트를 한다.
  • 관행적으로 테스트코드 파일의 이름은 테스트하고자하는 파일에 접미사로 Test를 붙인다.
    • ex) MemoryMemberRepository → MemoryMemberRepositoryTest
  • @Test 어노테이션을 통해 실행한다.
  • org.junit.jupiter.api.Assertions 혹은 org.assertj.core.api.Assertions.*assertThat 를 통해 데이터를 검증한다.*
  • 모든 테스트는 순서에 상관없이 개별적으로 검증이 가능해야한다.
  • @afterEach
    • 테스트 동작(@Test를 사용한 메서드)이 끝난후의 추가 동작
  • 실개발 전 검증할 수 있는 테스트 코드를 먼저 작성하는 개발을 테스트 주도개발(TDD) 라고한다.

서비스 개발

  • 서비스는 비즈니스 처리를 하기에 네이밍도 그에 따라간다
  • 객체가 null이 예상되는 경우 Optional 로 객체를 감싸서 사용하며, ifPresent 와 같은 optional이 지원하는 메서드를 통해 보다 쉽게 데이터를 처리할 수 있다.

서비스 테스트

  • cmd + shift + t 를 통해 테스트 코드의 틀을 만들 수 있다.
  • 테스트코드의 메서드들(테스트 항목)의 네이밍은 상황에 따라 한글로 작성해도 무관하다.
  • 테스트 내용을 given, when, then 으로 보통 나누어서 작성한다.
  • 테스트는 정상적인 흐름을 보는것도 중요하지만 예외상황을 보는것이 더 중요하다.
    • ex) 중복이름을 허용하지않는 회원가입에서 중복이름확인
  • @BeforeEach 를 통해 테스트 전 동작을 설정할 수 있다.