회원 생성하기

[Hyunstone]

• input 유효성 검사 API
  • 형식적 Validation
  • 논리적 Validation
• 아이디 중복 검사
• 리턴 값 설정
• 응답코드 설정
• Exception
• 테스트 코드 작성

[Hyunstone]

Autowired 와 private final의 차이

보통 의존성 주입 시에 주로 @Autowired 혹은 private final을 활용한다.

의존성 주입 방법은 @Autowired를 활용한 필드 주입, Setter를 활용한 메소드 주입, 생성자 주입 등이 있는데,
가장 흔히 사용되는 Autowired 주입과 생성자 주입에 대해 알아보고자 한다.

---

필드 주입(Field Injection)

사용법이 매우 간단하다. 필드에 @Autowired 어노테이션을 붙여주면 자동으로 의존성이 주입된다. 편리하기 때문에 가장 많이 접할 수 있는 방법

    @Autowired
    private HelloService helloService;

Constructor Based DI (생성자 기반 DI)

@Service
public class TestService {
  private final TestRepository testRepository;

  // 생략하고 @AllArgsConstructor 어노테이션 사용해도 된다.
  public TestService(TestRepository testRepository) {
    this.testRepository = testRepository;
  }
}

---

생성자 주입 방법은 필드 주입이나 수정자 주입과는 빈을 주입하는 순서가 다르다.
순환 참조는 생성자 주입에서만 문제가 된다. 객체 생성 시점에 빈을 주입하기 때문에 서로 참조하는 객체가 생성되지 않은 상태에서 그 빈을 참조하기 때문에 오류가 발생한다.

그렇다면 순환 참조 오류를 피하기 위해서 수정자 또는 필드 주입을 사용해야 할까? 그렇지 않다. 순환 참조가 있는 객체 설계는 잘못된 설계이기 때문에 오히려 생성자 주입을 사용하여 순환 참조되는 설계를 사전에 막아야 한다

---

생성자 주입의 장점

순환 참조를 방지할 수 있다.

• 순환 참조가 발생하는 경우 애플리케이션이 구동되지 않는다.

테스트 코드 작성이 편리하다.

• 단순 POJO를 이용한 테스트 코드를 만들 수 있다.

나쁜 냄새를 없앤다.

• 조금 더 품질 좋은 코드를 만들 수 있다.

immutable 하다.

• 실행 중에 객체가 변하는 것을 막을 수 있다.
• 필드를 final로 선언할 수 있다. 물론 런타임 환경에서 객체를 변경하는 경우가 있을까 싶지만 이로 인해 발생할 수 있는 오류를 사전에 미리 방지할 수 있다.

출처

https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection

[Hyunstone]

JUnit의 assertThat보다 assertj의 assertThat을 써야하는 이유 / 트러블 슈팅

같은 assertThat 이지만 두개의 차이가 있다.
하나는 JUnit 라이브러리에 존재하는 assertThat이고, 다른 하나는 assertj 라이브러리에 존재하는 assertThat이다.
같은 asssertThat이다 보니 import 하는 과정에서 흔하게 실수를 할 수 있다.

전자는 import static org.junit.Assert.assertThat;
후자는 import static org.assertj.core.api.Assertions.*; 이다.
중간에 junit과 assertj라는 큰 차이가 있으므로 유의해서 import 하자.

• static import 하는 경우는 바로 assertThat을 사용하면 되지만, 그냥 import하는 경우는 Assertions.assertThat로 작성해야 한다.
  assertThat()
  Assertions.assertThat()

---

본론으로 돌아와서 차이에 대해 알아보자.
assertj의 assertThat를 사용해야 하는 이유는 이렇다.
JUnit의 assertThat과 비교했을 때,

1. 자동완성
   assertThat에서 반환되는 Assert 클래스를 사용하기 때문에, 메소드 자동완성이 지원되어 편리하다.

2. Assertion 분류
   assertThat에서 인자의 타입에 맞는 Assert 클래스를 반환하기 때문에, 필요한 메소드만 분류되어 있다.

3. 확장성
   체이닝 메소드 패턴으로 작성 가능하기 때문에, 조건 추가를 위해 추가 작업이 필요없어 편리하고 가독성도 좋다.

따라서, assertj의 assertThat을 사용하도록 하자!

---

+) assertJ 내용 정리 참고

https://velog.io/@new_wisdom/assertJ-%EA%B3%B5%EC%8B%9D%EB%AC%B8%EC%84%9C%EC%99%80-%ED%95%A8%EA%BB%98%ED%95%98%EB%8A%94-assertJ-%EC%A0%95%EB%A6%AC

보통 테스트를 진행할 때. 하나의 assertThat()이 실패하면 해당 테스트 자체가 중단이 됩니다. 하지만, Soft assertions을 사용한다면, 모든 assertions을 실행한 후 실패 내역만 확인할 수 있다.

SoftAssertions softly = new SoftAssertions();
softly.assertThat(mansion.guests()).as("Living Guests").isEqualTo(7);
softly.assertThat(mansion.kitchen()).as("Kitchen").isEqualTo("clean");
softly.assertAll()

출처

https://jwkim96.tistory.com/168