의존성과 테스트

• 사용자가 로그인할때마다 로그인한 시간 기록
• 그런대 의존성이 숨겨져 있다.
• 외부에서 이메소드가 클락을 사용하는지 모르기 때문
• 어떤값이 들어가야되

• 이런식으로 외부에 주입시키면
• 테스트가 편해진다.
• 의존성은 드러내면 좋다.

• userService login 마찬가지로테스트하기 힘들어짐
• 의존성 주입은 이런식으로 모든 문제를 해결하기 어렵다
• 그래서 의존성 역전 !

• 이런식으로 의존성 역전

• 이런식으로 fake 사용해서 일관된 테스트 완성
• 이런식으로 Port-adapter 패턴 갈아 끼울수 있어 쉽게쉽게
• 단순히 추상하만 하라는것은 아니지만 다른 뜻도 많으니 생각해두자

TestAbility

• 호출자는 모르는 Input정보
• 그래서 코드를 타고가서 알아본다
• 객체지향의 캡슐화가 깨진다.
• 테스트 코드작성시 편리때문에 이런식으로 사용했는데 고쳐야겠다

• PowerMock을 이용해 스태틱 메서드 검증

• 하드코딩이 된 경우
• 고정된 파일에 지나치게 의존하고 있다

• webclient , restTemplate 직접사용해 서비스 테스트하기 힘든 경우다
• 복잡한 클래스 stub할생각은 너무 머리아프다

실기전 탐색

Builder

• 객체 생성이 다양해지는 문제를 해결하기 위해 마련된
• 유동적인 해결책!
• 생성자가 너무 많으면 실수할수 있어
• 메서드단에서 빌더 어노테이션 쓰면 좋을거 같다.
• 허나 단점 ! 필드가 하나 빠져도 생성되서 실수가 될 수 있다

• 테스트에 필요한 파라미터만 지정해줘서 테스트 가독성이 좋아 짐
• 테스트 객체의 구조적인 변화로부터 테스트를 다시 보호한다?

• 모두가 수정되서 Pr에 영향이 있으니 build 패턴이 좀더 효율적이다
• 허나 저렇게컴파일러가 캐치해주니 오히려 코드 안정성이 더좋은거 같은데.

entity

• 영속성 도메인 객체라 설명되있어서 Jpa랑 연관이 없다는건 아님

• 비즈니스에서 어떤문제를 해결하기 위해 만들어진 모델
• 비즈니스 로직도 들고있고 식별가능 생명주기도 갖는다
• 도메인 객체랑 혼용되는 개념?

• 디비 영역에서 쓰이던 용어
• 어떤 유무형 객체를 표현하기 위해 사용한 용어

• 객체지향 부분과 데이터베이스 부분에서 문제를 해결하기 위해

• 같은 고민 을했고 둘다 엔티티라는 용어를 사용함

• 객체지향에선 클래스로 표현되고 디비에선 테이블로 표현되서

• 둘 사이의 간극이 일어났따.

• 실세계에선 둘이 협업을 해야되기때문에

• DB 엔티티값을 도메인 엔티티로 옴겨야되기때문에

• 그게 영속성 객체로 Jpa라 보면된다 .

• 그래서 Jpa를 통해 이렇게 작성한다

• User는 디비 엔티티다 라고 이런식.

• 근데 이걸 합치냐마냐는 호불호 문제 이고 정답이 없는 문제
• 강의하는 사람은 웬만하면 분리하는걸 좋아함
• 왜냐하면 합쳐서쓰면 JPA RDB에 종속됨

• 테스트 할때 중복 최대한 줄이려했는대 이런 것도 괜찮은건가