회원 도메인 실행과 테스트

회원 도메인 실행과 테스트

이번 시간에는 우리가 만든 회원 도메인이 정상적으로 동작하는지 테스트를 만들어 볼게요.

클래스 다이어그램을 보면, 빠짐없이 다 개발이 됐고, 그 다음에는

이 그림을 만들 거에요. 그러니까 회원 서비스가 실제로 런타임에 동작을 하면, 클라이언트는 MemberServiceImpl 이라는 회원 서비스를 사용하게 되고,

회원 서비스는 메모리 회원 저장소, 우리가 new 해가지고 MemoryMemberRepository 넣었었죠.

그래서 실제 인스턴스 간의 참조 그림은 이렇게 된다고 이해하시면 됩니다.

그래서 클래스 다이어그램은 정적인 거구요. 객체 다이어그램은 동적인 거에요. 왜냐면, 객체 다이어그램은 new로 생성 해가지고 실제 코드에 들어가 봐야 알 수 있잖아요.

---

이제 실제 동작하는지 실행하고 테스트를 해보겠습니다.

먼저, hello.core 에다가 MemberApp 이라는 클래스를 만들 거에요. 그리고 나서, psvm 하고 enter 치면,

main 메서드가 완성됩니다. main 메서드에서 테스트를 진행하는 거에요.

먼저, 멤버 서비스를 만들어요.

그리고 멤버 서비스를 만드는데 new 해서 MemberServiceImpl을 선택 해줬죠. 그 다음에 member를 join 해보겠습니다.

Member를 이렇게 생성하는데, 이렇게 하고 cmd + option + v 하면, 반환값을 반환해줍니다.

그리고 join 하면 회원가입이 되야 되겠죠. id 1옆에 붙은 L은 Long 타입이어서 꼭 붙여야합니다. 안 쓰면 컴파일 오류납니다.

그래서 id가 1이고, 이름은 "memberA"이면서, 등급은 VIP 인 사람이 회원가입이 제대로 되었는지 확인하면 되겠죠.

이렇게 해서 우리가 가입한 member랑 findMember랑 똑같으면, 테스트 성공입니다. 여기서는 단순하게 찍어볼게요.

soutv 하고 enter 하면,

변수를 위에 거에서 선택할 수 있습니다.

member를 선택해서,

이렇게 하면, 애플리케이션이 제대로 개발되는지 확인해볼 수 있겠죠.

돌려보면,

이렇게 나왔습니다. 잘 나온 걸 볼 수 있습니다.

우리가 적은 이 코드는

정말 순수한 자바 코드예요. 지금 어디에도 스프링 관련된 게 전혀 없죠.

순수한 자바 코드에서 자바 메서드를 실행을 한 거고, 스프링 관련된 코드가 1도 없습니다. 그래서 진짜 순수한 자바로만 이거를 개발한 거에요.

자 그런데 애플리케이션 로직으로 이렇게 메인 메서드로 테스트 하는 거는 한계가 있습니다. 좋은 방법이 아니죠. 계속 눈으로 확인할 수는 없습니다.

그래서 JUnit 이라는 테스트 프레임워크를 쓸 겁니다. 기본으로 세팅이 다 되어 있구요.

보통 테스트 하려는 패키지와 똑같은 이름의 패키지를 놓는데, 우리는 member에 관한 테스트를 할거니까, member 패키지를 test 아래에 만들어줘야 합니다.

나중에 빌드해서 나가면, main에 대한 코드만 나가고, test 폴더에 대한 코드는 운영환경에서 배포가 안됩니다. 빌드 될 때 빠집니다.

이제 여기에다가 MemberServiceTest 라는 테스트 클래스를 만들겠습니다.

그 다음에 @Test 해서, junit의 test가 import 되어야 합니다.

먼저, join 부터 테스트하겠습니다. 그 전에 given, when, then 문법을 쓸 건데,

given은 뭐냐면, 이러한 환경, 즉 이러한 데이터가 주어졌을 때를 말하고, when은 이걸 검증한다 라는 거고, then은 검증한 결과가 어떻게 나오는지 확인하는 검증부입니다.

given 에서 이러한 회원이 주어진다는 것이고, 이제 when에서 MemberService의 join을 호출해야하므로, MemberService 필드를 만들어줘야 합니다.

이렇게 하고, then에서 검증 결과를 볼 건데요. 검증은

org.assertj.core.api.Assertions를 쓰면 됩니다.

이렇게 하고 테스트를 돌려서, 내가 join 한 거랑 찾은 거랑 똑같으면, 테스트에서 데이터를 넣고 빼는 게 성공한 겁니다.

성공했습니다. 만약에 findMember에 들어가는 id를 2L로 바꾸면,

오류가 나죠. main 메서드로 테스트 했을 때처럼, 우리가 눈으로 직접 콘솔을 보면서 출력된 결과를 보면서 검증하는 게 아니죠. 그리고 오류가 나서 테스트가 실패하면, 빨리 다른 코드를 추가해서 테스트 실패 원인도 빨리 캐치가 가능합니다.

---

그런데 이 회원 도메인의 설계상의 문제점이 있습니다.

이 코드의 설계상 문제는 뭘까요?

만약 이 회원 도메인은 다른 저장소로 변경할 때 OCP 원칙을 잘 준수할까요? 그리고 얘가 DIP를 잘 지키고 있을까요?

결국 의존 관계가 이 MemberService가 MemberRepository의 인터페이스 뿐만 아니라, 구현체까지 모두 의존하는 문제가 있습니다.

MemberServiceImpl에 가보면,

MemberServiceImpl는 분명히 MemberRepository에 의존을 하죠. 문제는 오른쪽이에요. 인터페이스를 의존하는 동시에 구현체를 의존하고 있어요. 할당하는 동시에 구현체를 의존하는 거죠.

그래서 MemberServiceImpl은 인터페이스랑 구현체 둘 다 의존하고 있는 거에요. 나중에 변경했을때 문제가 됩니다. OCP와 DIP를 둘 다 위반하고 있는거에요.

---

자 이렇게 해서 일단 회원 가입 테스트까지는 해봤구요.

다음 시간에는 주문과 할인 도메인을 설계해보겠습니다.