회원 클래스

• id , name 변수 선언
• get, set 메소드 선언

회원 리포지토리 인터페이스

• save() : 저장
• findById() : 아이디를 이용해 회원 찾기
• findByName() : 이름을 이용해 회원 찾기
• findAll() : 모든 회원 리스트로

회원 리포지토리 메모리 구현체

• Sequence : 0,1,2 key 값을 생성해주는 것
• Optional : 반환값이 null인 경우를 대비해 Optional로 감싸준다
• findByName() : 람다를 통해 다 돌면서 이름이 같은 경우를 찾으면 반환 , 결과가 null이면 알아서 Optional로 감싸서 반환해줌

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

개발한 기능을 실행해서 테스트 할 때 자바의 main 메서드를 통해서 실행하거나, 웹 애플리케이션의 컨트롤러를 통해 해당 기능을 실행한다. 이런 방법은 준비하고 실행하는데 오래 걸리며 , 반복 실행하기 어렵고 여러 테스트를 한번에 하기 어렵다는 단점이 있다 자바는 JUnit이라는 프레임워크로 테스트를 실행해서 이러한 문제를 해결한다

• @AterEach : 한번에 여러 테스트 실행하면 메모리 DB에 직전 테스트의 결과가 남을 수 있다 이전 테스트 때문에 다음 테스트가 실패할 가능성이 있기 때문에 @AfterEach를 사용하면 각 테스트가 종료될 때 마다 이 기능을 실행한다. 여기서는 메모리 DB에 저장된 데이터를 삭제한다
• 테스트는 각각 독립적으로 실행되어야 하고, 순서에 의존관계가 있는 것은 좋은 테스트가 아니다
  -> 순서대로 테스트 실행 안됨 !!!!
  

회원 서비스 개발

• 회원 가입 메소드
• 회원 가입시 중복체크 메소드
• 회원 조회 메소드

회원 서비스 테스트

기존에는 회원 서비스가 메모리 회원 리포지토리를 직접 생성하게 했다

• 회원 리포지토리의 코드가 회원 서비스 코드를 DI 가능하게 변경한다.

DI(Dependency Injection) 란 ?

개발을 하다보면 코드에 의존성이 생기기 마련이다. 그렇다면 의존성은 무엇이고 왜 생겨나는 걸까?

• Programmer 클래스에서 startProgramming 함수가 호출되기 위해서는 coffe 클래스를 필요로 한다. 이것을 Programmer 클래스는 coffe클래스의 의존성을 가진다 라고 한다.

DI(의존성 주입)를 해야 하는 이유

• Unit Test가 용이해진다
• 코드이 재활용성을 높여준다
• 객체 간의 의존성을 줄이거나 없앨 수 있다
• 객체 간의 결합도를 낮추면서 유연한 코드를 작성할 수 있다.

DI 를 사용하지 않으면 Coffee 클래스의 상속을 받은 Cappuccino나 Americano클래스를 사용해야 한다면 위와 같이 직접 수정해야 한다.
Ex) Coffee 클래스를 사용하는 클래스가 1억개라면 1억번 수정해야 한다.

의존성 주입을 이용하면 직접 클래스를 생성하는 것이 아닌, 주입해줌으로써 객체 간의 결합도를 줄이고 좀 더 유연한 코드를 작성할 수 있어 한 클래스를 수정하였을 때, 다른 클래스도 수정해야하는 상황을 막을 수 있다 !

정리

• DI, 의존성 주입은 필요한 객체를 직접 생성하는 것이 아닌 외부로 부터 필요한 객체를 받아 사용하는 것이다
• 이를 통해 객체간의 결합도를 줄이고 코드의 재활용성을 높여준다

회원 서비스 테스트

• @BeforeEach : 각 테스트 실행 전 호출, 테스트가 서로 영향이 없도록 항상 새로운 객체를 생성하고 의존관계도 새로 맺어준다