0718 ~ 0724

0719 - 도메인 주도 설계(Domain Driven Development) 이해

도메인 주도 설계 도입 배경

Before

기존 개발

• 데이터에 종속적인 애플리케이션
• 모델링과 개발과의 불일치 발생

After

도메인 주도 설계

• 이런 불일치를 해소하기 위한 노력 중 하나가 바로 DDD
• 공통의 언어(*유비쿼터스 언어)를 사용하여 도메인과 구현을 충분히 만족하는 모델을 만든다.
• *유비쿼터스 언어를 사용하여 용어사전을 만든다. (예) 헌터 | hunter | 보물을 찾는 사냥꾼
• '설계'와 '구현'은 계속된 수정 과정을 거친다. (반복 작업)

*유비쿼터스 언어(보편 언어)란? 도메인 어휘를 이해관리자들이 공통적으로 의미를 이해할 수 있도록 정의하는 것

효과적인 모델링

• 사용자와 개발자는 동일한 언어로 이야기 하는가?
• 해당 언어가 애플리케이션에서 수행해야 할 내용에 관한 논의를 이끌어갈 만큼 풍성한가?

도메인

• 일반적인 요구하상, 전문 용어, 그리고 컴퓨터 프로그래밍 분야에서 문제를 풀기 위해 설계된 어떤 소프트웨어 프로그램에 대한 기능성을 정의하는 연구의 한 영역
• 소프트웨어로 해결하고자 하는 문제 영역 (예) 광고회사의 광고와 관련된 지식 = 도메인

도메인 모델

• 특정 도메인을 개념적으로 표현한 것
• 도메인 모델을 사용하면 여러 관계자들(개발자, 기획자, 사용자 등)이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 된다.
• 모델의 각 구성 요소는 특정 도메인을 한정할 때 비로소 의미가 와전해지기 때문에, 각 하위 도메인마다 별도로 모델을 만들어야 한다.
  (예) 쿠팡에서 상품을 주문할 때 필요한 것 : 고객의 주문서 모델, 상품 정보의 상품 모델

도메인 주도 설계 아키텍처 개요

*핵심 로직(비즈니스 로직)은 도메인 모델에 담아서 사용한다.

도메인 모델의 네 개의 영역

*아래로 내려갈수록 의존성이 강해진다.

• PRESENTATION LAYER : 표현 영역 또는 UI영역. 사용자의 요청을 받아 응용 영역에 전달하고, 응용 영역의 처리 결과를 다시 사용자에게 보여주는 역할을 한다. (Controller 영역, DispatcherServlet에게 요청과 응답을 전달하는 역할)
• APPLICATION LAYER : 응용 영역. 시스템이 사용자에게 제공해야 할 기능을 구현한다. (Service 영역)
• DOMAIN LAYER : 도메인 영역. 도메인 모델을 구현한다. (이름, 주소, 상품, 주문서 등)
• INFRASTRUCTURE LAYER : 구현 기술에 대한 것을 다룬다. (외부 API, 데이터베이스, 외부 라이브러리 사용 등)

PRESENTATION LAYER(표현영역)

• 사용자가 시스템을 사용할 수 있는 (화면) 흐름을 제공하고 제어
• 사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공한다.
• 사용자의 세션을 관리한다.

APPLICATION LAYER(응용영역)

• 사용자의 요청을 처리하기 위해 리포지터리로부터 도메인 객체를 구하고, 도메인 객체를 사용한다.
• 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.
• 도메인 객체 간의 실행 흐름을 제어
• *트랜잭션 처리
• 도메인 영역에서 발생시킨 이벤트를 처리

*트랜잭션이란? 데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위.

도메인 주도 설계 기본요소

엔티티(Entity)와 벨류(Value)

• 도출한 모델은 크게 엔티티와 벨류로 구분
• 데이터와 함께 도메인 기능을 제공한다.

Entity

• 식별자를 갖는다.
• 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다.

도메인 모델에 set 메서드 넣지 않기

• 도메인 모델에 get/set 메서드를 무조건 추가하는 것은 좋지 않은 버릇이다.
• 특히 set 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다.
• set 메서드의 또 다른 문제는 도메인 객체를 생성할 때 완전한 상태가 아닐 수도 있다는 것이다.
• 도메인 객체가 불완전한 상태로 사용되는 것을 막으러면 생성 시점에 필요한 것을 전달해 주어야 한다.

Value Object

• 벨류 타입은 불변을 원칙으로 한다.
• 의미를 명확하게 표현하거나 두 개 이상의 데이터가 개념적으로 하나인 경우 벨류 타입을 이용한다.
• 시스템이 성숙함에 따라 데이터 값을 객체로 대체한다.
• 벨류 객체의 값을 변경하는 방법은 새로운 벨류 객체를 할당하는 것뿐이다.
• 식별자가 존재하지 않는다.

Aggregate

• 관련 객체를 하나로 묶은 군집
• 애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 갖는다.
• 애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.
• 애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.
• 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
• 대부분의 애그리거트는 한개의 엔티티 객체를 가지며, 두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다.
• 각 애그리거트는 자기 자신을 관리할뿐 다른 애그리거트는 관리하지 않는다.
  (예)주문 애그리 거트는 배송지 변경, 주문 상품 변경 등 자신은 관리하지만 회원 비밀번호 변경, 상품 가격 변경 등은 하지 않는다.

*주문(Order) 애그리거트 : 주문, 배송지 정보, 주문자, 주문목록, 총 결제금액의 하위 모델이 있다. 이때 이 하위 개념을 표현한 모델을 하나로 묶어서 '주문'이라는 상위 개념으로 표현할 수 있다.
즉, 주문은 Root Aggregate가 된다.
Root Aggregate를 중점으로 종속되어 있는 엔티티들은 동일한 라이프사이클(하나의 트랜잭션)을 가진다.
*퍼사드 패턴과 유사하다. (참고: https://jusungpark.tistory.com/23)

애그리거트 루트

• 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 꺠지지 않도록 하는 것이다.(애그리거트: 독립된 객체군)
• 부득이하게 트랜잭션으로 두 개 이상의 애그리거트를 수정해야 한다면 애그리거트에서 다른 애그리거트를 직접 수정하지 않고, 응용 서비스에서 두 애그리거트를 수정하도록 구현해야 한다.
• 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
• 이는 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화 할 수 있도록 돕는다.
• 루트 엔티티는 애그리거트에 속해 있는 엔티티와 벨류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다.

*애그리거트 루트를 통해서만 도메인 로직을 구현하게 만드는 습관*

- 단순히 필드를 변경하는 set 메소드를 public으로 만들지 않는다.
- 벨류타입은 불변으로 구현한다.

애그리거트 참조

• 애그리거트를 직접 참조할 때 발생할 수 있는 문제는 편리함을 오용할 수 있다는 것, 성능에 대한 고민, 확장의 어려움 등이 있다.
• ID참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.
• ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원천적으로 방지할 수 있다.

리포지터리

• 엔티티나 벨류가 요구사항에서 도출되는 도메인 모델이라면, 리포지터리는 구현을 위한 도메인 모델
• 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.
• 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
• 리포지터리가 완전한 애그리거트를 제공하지 않으면, 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 도중에 NPE와 같은 문제가 발생하게 된다.
• 리포지터리는 애그리거트(루트) 단위로 존재하며 테이블 단위로 존재하는 것이 아니다.

(예시)

public interface OrderRepository {
    public Order findByNumber(OrderNumber number);
    public void save(Order order);
    public void delete(Order order);
}

여러 애그리거트가 필요한 기능
*결제 금액 계산 로직

• 상품 애그리거트 : 구매하는 상품의 가격이 필요하다. 또한 상품에 따라 배송비가 추가되기도 한다.
• 주문 애그리거트 : 상품별로 구매 개수가 필요하다.
• 할인 쿠폰 애그리거트 : 쿠폰별로 지정한 할인 금액이나 비율에 따라 주문 총 금액을 할일한다. 할인 쿠폰을 조건에 따라 중복 사용할 수 있다거나 지정한 카테고리의 상품에만 적용할 수 있다는 제약 조건이 있다면 할인 꼐산이 복잡해진다.
• 회원 애그리거트 : 회원 등급에 따라 추가 할인이 가능하다.

"이 상황에서 실제 결제 금액을 계산해야 하는 주체는 어떤 애그리거트 일까?"

도메인 서비스

• 한 애그리거트에 넣기 애매한 도메인 개념을 구현하려면 애그리거트에 억지로 넣기보다는 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다.
• 응용 영역의 서비스가 응용 로직을 다룬다면 도메인 서비스는 도메인 로직을 다룬다.
• 도메인 영역의 애그리거트나 밸류와 같은 다른 구성요소와 비교할 떄 다른 점은 상태 없이 로직만 구현한다.
• 서비스를 사용하는 주체는 애그리거트가 될 수도 있고 응용 서비스가 될 수도 있다.
• 애그리거트 메서드를 실행할 때 도메인 서비스를 인자로 전달하지 않고 반대로 도메인 서비스의 기능을 실행할 때 애그리거트를 전달하기도 한다.
• 특정 기능이 응용 서비스인지 도메인 서비스인지 감을 잡기 어려울 때는 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태 값을 계산하는지 검사해 보면 된다.

(예) 계좌이체 로직은 계좌 애그리거트의 상태를 변경한다. 결제 금액 로직은 주문 애그리거트의 주문 금액을 계산한다. 이 두로직은 각각 애그리거트를 변경하고 애그리거트의 값을 계산하는 도메인 로직이다.
도메인 로직이면서 한 애그리거트에 넣기 적합하지 않으므로 이 두 로직은 도메인 서비스로 구현하게 된다.

*트랜잭션 처리와 같은 로직은 응용 로직이므로 응용 서비스에서 처리해야 한다.

UML

• 모델 기반 의사소통은 *UML 상의 다이어그램으로 한정돼서는 안된다.

BOUNDED CONTEXT

• 애그리거트의 명시적 경계
• 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다.
• 하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인 마다 모델을 만들어야 한다.
• 모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다.
• 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.
• 도메인 : Bounded Context = 1:1 이 이상적이다.

*주의할 점

• 하위 도메인 모델이 뒤섞이지 않도록 하는 것
• 개별 Bounded Context Package로 구성하여 하위 도메인이 섞이지 않도록 하여 효과를 낼 수 있다.
• 도메인이 섞이게 된다면 기능 확장이 어렵게 되고 이는 서비스의 경쟁력을 떨어뜨리는 원인이 될 수 있다.

0720 - 자바 예외처리 방법과 종류

java exception handling (Checked Exception, Unchecked Exception)

예외와 에러의 의미

예외(Exception)란 입력 값에 대한 처리가 불가능하거나, 프로그램 시행 중에 참조된 값이 잘못된 경우 등 정상적인 프로그램의 흐름을 어긋나는 것을 말한다. 또한, 자바에서의 예외는 개발자가 직접 처리할 수 있기 때문에 예외 상황을 미리 예측하여 다룰 수 있다.

에러(Error)는 시스템에 비정상적인 상황이 발생한 경우를 말한다. 주로 자바 가상 머신(JVM)을 통해 발생되며 예외와 반대로 이를 애플리케이션 코드에서 잡으려고 하면 안된다.

package src.throwable.error;

public class ErrorExample {

    public static void gillog(String log) {
        System.out.println(log);
    }

    public static void main(String[] args) {
        try {
            gillog("Error Test");
        } catch (StackOverflowError e) {
            // ......... :(
        }
    }
}

에러의 경우 StackOverflowError에 대해 Catch를 하려 해도 처리할 수 없다.

예외(Exception)의 구분

• RuntimeException을 상속하지 않는 클래스는 Checked Exception로 분류할 수 있다.
• RuntimeException을 상속하는 클래스는 Unchecked Exception으로 분류할 수 있다.

에러(Error)의 종류

에러의 종류에는 LinkageError, ThreadDeath, AssertionError, VirtualMachineError가 있다.

• LinkageError : 어떤 클래스가 다른 클래스에 대한 종속성이 있는 상황에서, 후자 클래스가 이전 클래스를 컴파일 한 후 비호환적으로 변경된 경우 발생하는 에러
• ThreadDeath : 더 이상 사용되지 않는 Thread에 대해 Thread.stop() method가 호출 될 때, 삭제되는 Thread에서 Instance가 throw 되며 발생하는 에러
• AssertionError : Assertion이 실패한 경우 발생하는 에러. (해당 지점에서 개발자가 반드시 참이어야 한다고 생각하는 사항을 표현한 논리식을 Assertion이라 한다.)
• VirtualMachine : JVM이 손상되었거나 계속 작동하는 데 필요한 리소스가 부족할때 발생하는 에러

CheckedException과 UncheckedException

CheckedException

• 반드시 예외 처리해야 하며, 컴파일 시점에서 예외 발생이 확인된다.
• 에러와 RuntimeException을 상속하지 않은 예외들을 모두 포함한다.
• Error, FileNotFoundException, ClassNotFoundException 등이 대표적이다.
• 스프링 프레임워크에서 CheckedException은 트랜젝션 처리 시에 예외가 발생해도 롤백하지 않는다.

UncheckedException

• 명시적으로 예외 처리할 필요가 없으며, 런타임 시점에서 예외 발생이 확인된다.
• RuntimeException을 상속받는 예외들을 포함한다.
• NullPointerException, ClassCastException 등이 대표적이다.
• 스프링 프레임워크에서 UncheckedException은 트랜젝션 처리시에 예외가 발생한 경우 롤백을 수행한다.

순수 자바 관점에서의 UncheckedException 상황에서는 롤백을 수행하지 않아도 된다.

예외처리 방법

예외 처리방법에는 복구, 회피, 전환이 있다.

예외 복구

• 예외 상황을 파악하고 문제를 해결해서 정상 상태로 돌려놓는 방법
• 예외를 잡아서 일정 시간, 조건만큼 대기하고 다시 재시도를 반복한다.
• 최대 재시도 횟수를 넘기게 되는 경우 예외를 발생시킨다.

final int MAX_RETRY = 100;
public Object someMethod() {
    int maxRetry = MAX_RETRY;
    while(maxRetry > 0) {
        try {
            ...
        } catch(SomeException e) {
            // 로그 출력. 정해진 시간만큼 대기한다.
        } finally {
            // 리소스 반납 및 정리 작업
        }
    }
    // 최대 재시도 횟수를 넘기면 직접 예외를 발생시킨다.
    throw new RetryFailedException();
}

예외처리 회피

• 예외 처리를 직접 담당하지 않고 호출한 쪽으로 던져 회피하는 방법
• 그래도 예외 처리의 필요성이 있다면 어느 정도는 처리하고 던지는 것이 좋다.
• 긴밀하게 역할을 분담하고 있는 관계까 아니라면 예외를 그냥 던지는 것은 무책임하다.

// 예시 1
public void add() throws SQLException {
    // ...생략
}

// 예시 2 
public void add() throws SQLException {
    try {
        // ... 생략
    } catch(SQLException e) {
        // 로그를 출력하고 다시 날린다!
        throw e;
    }
}

예외 전환

• 예외 회피와 비슷하게 메서드 밖으로 예외를 던지지만, 그냥 던지지 않고 적절한 예외로 전환해서 넘기는 방법
• 조금 더 명확한 의미로 전달되기 위해 적합한 의미를 가진 예외로 변경한다.
• 예외 처리를 단순하게 만들기 위해 포장(wrap) 할 수도 있다.

// 조금 더 명확한 예외로 던진다.
public void add(User user) throws DuplicateUserIdException, SQLException {
    try {
        // ...생략
    } catch(SQLException e) {
        if(e.getErrorCode() == MysqlErrorNumbers.ER_DUP_ENTRY) {
            throw DuplicateUserIdException();
        }
        else throw e;
    }
}

// 예외를 단순하게 포장한다.
public void someMethod() {
    try {
        // ...생략
    }
    catch(NamingException ne) {
        throw new EJBException(ne);
        }
    catch(SQLException se) {
        throw new EJBException(se);
        }
    catch(RemoteException re) {
        throw new EJBException(re);
        }
}

0721 - 다이나믹 테스트(Dynamic Test)

다이나믹 테스트(Dynamic Test)란?

다이나믹 테스트에 대해 알아보기 전에 상대되는 개념인 정적 테스트와 함께 개념을 비교해서 특징을 한번 살펴보자.

JUnit을 이용해서 테스트를 작성하게 되면 보통 @Test라는 어노테이션을 사용 해서 테스트 케이스를 작성하게 되는데, 이와 같은 방식의 테스트를 정적 테스트라고 한다. 정적 테스트는 컴파일 시점에 코드가 지정된다는 특징을 가지고 있다. 가정은 동적인 기능에 대한 기본 테스트 형태를 제공하지만, 그 표현이 컴파일 시점에 제한된다는 한계를 가지고 있다.

이에 비해 다이나믹 테스트는 런타임 동안에 테스트가 생성되고 수행된다. 그래서 프로그램이 수행되는 도중에도 동작을 변경할 수 있는 특징이 있다. 이 다이나믹 테스트는 @Test어노테이션을 사용하지 않고, @TestFactory 어노테이션을 통해 팩토리 메서드로 생성된다.

다이나믹 테스트의 장점

1. 유연성

다이나믹 테스트를 작성하는 가장 큰 이유는 아마도 런타임 시점에 테스트 케이스를 생성할 수 있다는 유연성을 꼽을 수 있다.

@ParameterizedTest
@ValueSource(ints = {1, 2, 3, 4, 5})
void isUnderTenTest(int number) {
  boolean result = isUnderTen(number);
  
  assertThat(result).isTrue();
}

@TestFactory
Stream<DynamicTest> isUnderTenTest() {
  List<Integer> numbers = getNumberFromDatabase() // 1, 2, 3, 4, 5, 6, 7, 8, 9

  return numbers.stream()
      .map(num -> dynamicTest(num + "가 10미만인지 검사",
          () -> {
               boolean result = isUnderTen(num);
               assertThat(result).isTrue();
          }
    ));
}

테스트하고자 하는 메서드가 도메인 핵심 로직을 수행하는 메서드이고, 동적으로 여러 테스트 케이스를 검증이 필요하다면 다이나믹 테스트가 훨씬 유용한 방법이 된다.
다이나믹 테스트의 강력함은 테스트 케이스가 동적으로 생성되고 수행되기 때문에, 여러 dynamicTest안에서 데이터 결과를 공유하고 연속성 있는 테스트를 작성할 수 있다는 것이다.

2. 가독성

인수테스트 처럼 하나의 메서드 안에서 사용자 시나리오를 작성해야할 경우

/*
Feature: 지하철 노선 관리

  Scenario: 지하철 노선을 관리한다.
    When 지하철 노선 n개 추가 요청을 한다.
    Then 지하철 노선이 추가 되었다.
    
    When 지하철 노선 목록 조회 요청을 한다.
    Then 지하철 노선 목록을 응답 받는다.
    And 지하철 노선 목록은 n개이다.
    
    When 지하철 노선 수정 요청을 한다.
    Then 지하철 노선이 수정 되었다.

    When 지하철 노선 제거 요청을 한다.
    Then 지하철 노선이 제거 되었다.
    
    When 지하철 노선 목록 조회 요청을 한다.
    Then 지하철 노선 목록을 응답 받는다.
    And 지하철 노선 목록은 n-1개이다.
 */
@DisplayName("지하철 노선을 관리한다.")
@Test
void manageLine() {
    // when
    createLine("신분당선");
    createLine("1호선");
    createLine("2호선");
    createLine("3호선");
    // then
    List<LineResponse> lines = getLines();
    assertThat(lines.size()).isEqualTo(4);
  
    // when
    LineResponse line = getLine(lines.get(0).getId());
    //then
    assertThat(line.getId()).isNotNull();
    assertThat(line.getName()).isNotNull();
    assertThat(line.getStartTime()).isNotNull();
    assertThat(line.getEndTime()).isNotNull();
    assertThat(line.getIntervalTime()).isNotNull();
  
    ...
}

@DisplayName("노선을 관리한다.")
@TestFactory
Stream<DynamicTest> dynamicTestsFromCollection() {
    return Stream.of(
        dynamicTest("노선을 만드는 요청으로 새로운 노선을 생성한다.", () -> {
            // when
            createLine("신분당선");
            createLine("1호선");
            createLine("2호선");
            createLine("3호선");

            // then
            List<LineResponse> lines = getLines();
            assertThat(lines.size()).isEqualTo(4);
        }),
    
        dynamicTest("생성된 노선 목록을 불러온다.", () -> {
            // given
            List<LineResponse> lines = getLines();
 
            // when  
            LineResponse line = lines.get(0);
 
            // then
            assertThat(line.getId()).isNotNull();
            assertThat(line.getName()).isNotNull();
            assertThat(line.getStartTime()).isNotNull();
            assertThat(line.getEndTime()).isNotNull();
            assertThat(line.getIntervalTime()).isNotNull();
        }),
      
        ...
    );
}

다이나믹 테스트 작성밥법

1. @TestFactory 어노테이션 사용

• @TestFactory 메소드는 테스트 케이스를 생산하는 팩토리이다.
• @TestFactory 메서드는 private 또는 static이면 안된다.

2. 컬렉션 반환

• @TestFactory 메서드는 Stream, Collection, Iterable 또는 Iterato 를 return 해야 한다. 그렇지 않으면, JUnitException을 발생 시킨다.
• 테스트 수는 동적이며, ArrayList 크기에 따라 달라진다.

3. 첫번째 인자로 테스트 이름 작성

• dynamicTest 는 테스트 이름과, 실행 함수 두 요소로 이루어져있다
• 그 만큼 테스트 이름을 잘 작성해주는 것이 가독성을 높이는 측면에서도 중요하다

@TestFactory
Stream<DynamicTest> exampleDynamicTest() {
    return Stream.of(
        dynamicTest("First Dynamic Test", () -> {
            // test code
        }),
        dynamicTest("Second Dynamic test", () -> {
            // test code
        })
    );
}

주의 사항

다이나믹 테스트는 JUnit의 생명주기 콜백함수를 지원하지 않는다. 그러므로 @BeforeEach나 @AfterEach와 같은 테스트 생명 주기와 관련된 요소들을 사용할 수 없다

0722 - AssertJ 필수기능정리

https://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html

AssertJ란?

자바 테스트를 위해 좀 더 풍부한 문법을 제공하고 메서드 체이닝을 통해 직관적인 테스트 흐름을 작성할 수 있도록 개발된 오픈소스 라이브러리

예제

@Test
  public void split() {
    String[] values = "1,2".split(",");
    assertThat(values).containsExactly("1", "2");

    values = "1".split(",");
    assertThat(values).containsExactly("1");
  }

JUnit5의 경우, assertEquals(expected, actual)과 같이 두 개의 인자를 받아서 비교를 하지만, AssertJ는 메소드 체이닝을 통해 가독성을 높여주는 특징이 있습니다. assertEquals()는 왼쪽이 expected인지 actual인지 혼동될 여지가 있지만, assertThat()은 actual 인자 하나만 요구하고 그 뒤로 메소드 체이닝을 하므로 acutal과 expected를 명확하게 구분지어준다는 장점이 있습니다.

Test Fail Message

JUnit5의 경우, 마지막 인자값에 선택적으로 메시지를 넣어줌으로써 테스트 실패 메시지를 명시할 수 있는데, AssertJ에서는 as()를 호출하여 사용합니다. 단, assertion이 수행되기 전에 사용해야 합니다.

TolkienCharacter frodo = new TolkienCharacter("Frodo", 33, HOBBIT);
 // failing assertion, remember to call as() before the assertion, not after !
 assertThat(frodo.getAge()).as("check %s's age", frodo.getName()).isEqualTo(100);

만약, frodo의 나이가 100과 같지 않다면 "check 33's age"와 같은 오류 메시지를 출력한다.

Filtering assertions

import static org.assertj.core.api.Assertions.in;
import static org.assertj.core.api.Assertions.not;
import static org.assertj.core.api.Assertions.notIn;
...

// filters use introspection to get property/field values
assertThat(fellowshipOfTheRing).filteredOn("race", HOBBIT)
                               .containsOnly(sam, frodo, pippin, merry);

// nested properties are supported
assertThat(fellowshipOfTheRing).filteredOn("race.name", "Man")
                               .containsOnly(aragorn, boromir);

// you can apply different comparison
assertThat(fellowshipOfTheRing).filteredOn("race", notIn(HOBBIT, MAN))
                               .containsOnly(gandalf, gimli, legolas);

assertThat(fellowshipOfTheRing).filteredOn("race", in(MAIA, MAN))
                               .containsOnly(gandalf, boromir, aragorn);

assertThat(fellowshipOfTheRing).filteredOn("race", not(HOBBIT))
                               .containsOnly(gandalf, boromir, aragorn, gimli, legolas);

// you can chain multiple filter criteria
assertThat(fellowshipOfTheRing).filteredOn("race", MAN)
                               .filteredOn("name", not("Boromir"))
                               .containsOnly(aragorn);

람다식을 사용하여 필터링도 가능하다

Assertions on extracted properties/fields of iterable/array elements

// extract the names ...
List<String> names = new ArrayList<String>();
for (TolkienCharacter tolkienCharacter : fellowshipOfTheRing) {
  names.add(tolkienCharacter.getName());
}
// ... and finally assert something
assertThat(names).contains("Boromir", "Gandalf", "Frodo", "Legolas");

• extracing()

// 단일필드검사
assertThat(fellowshipOfTheRing).extracting("name", String.class)
                               .contains("Boromir", "Gandalf", "Frodo", "Legolas")
                               .doesNotContain("Sauron", "Elrond");

// 여러필드검사
import static org.assertj.core.api.Assertions.tuple;

// extracting name, age and and race.name nested property
assertThat(fellowshipOfTheRing).extracting("name", "age", "race.name")
                               .contains(tuple("Boromir", 37, "Man"),
                                         tuple("Sam", 38, "Hobbit"),
                                         tuple("Legolas", 1000, "Elf"));

Soft assertions

@Test
public void host_dinner_party_where_nobody_dies() {
   Mansion mansion = new Mansion();
   mansion.hostPotentiallyMurderousDinnerParty();
   // use SoftAssertions instead of direct assertThat methods
   SoftAssertions softly = new SoftAssertions();
   softly.assertThat(mansion.guests()).as("Living Guests").isEqualTo(7);
   softly.assertThat(mansion.kitchen()).as("Kitchen").isEqualTo("clean");
   softly.assertThat(mansion.library()).as("Library").isEqualTo("clean");
   softly.assertThat(mansion.revolverAmmo()).as("Revolver Ammo").isEqualTo(6);
   softly.assertThat(mansion.candlestick()).as("Candlestick").isEqualTo("pristine");
   softly.assertThat(mansion.colonel()).as("Colonel").isEqualTo("well kempt");
   softly.assertThat(mansion.professor()).as("Professor").isEqualTo("well kempt");
   // Don't forget to call SoftAssertions global verification !
   softly.assertAll();
}

모든 assertions을 실행한 후 실패 내역을 확인

Exception assertions

@ParameterizedTest
  @ValueSource(strings = {"", "spring"})
  @DisplayName("이름 길이가 0 이하 또는 5 이상일 때 에러 확인")
  void car_name_exception(String name) {
    assertThatThrownBy(() -> new Car(name))
        .isInstanceOf(IllegalStateException.class)
        .hasMessageContaining("이름 길이는 0이하 또는 5이상이어야 합니다.");
  }

0723 - 자바 자료구조

자바 자료구조 구조 및 사용법 정리

큐(Queue)

순서대로 처리되는 자료구조(FIFO : First In First Out)

• Enqueue : 큐 맨 뒤에 데이터 추가
• Dequeue : 큐 맨앞쪽의 데이터 삭제

Queue 특징

• FIFO(First In First Out) 구조
• 큐는 한 쪽 끝은 프런트(front)로 정하여 삭제 연산만 수행함
• 다른 한 쪽 끝은 리어(rear)로 정하여 삽입 연산만 수행함
• 그래프의 넓이 우선 탐색(BFS)에서 사용
• 컴퓨터 버퍼에서 주로 사용, 마구 입력이 되었으나 처리를 하지 못할 때, 버퍼(큐)를 만들어 대기

Queue 사용법

• 선언

Queue<Integer> intQueue = new LinkedList<>();
Queue<String> stringQueue = new LinkedList<>();

• 값 추가

Queue<Integer> queue = new LinkedList<>();
queue.add(1);
queue.add(2);
queue.offer(3);

• 값 삭제

Queue<Integer> queue = new LinkedList<>(List.of(1, 2, 3));

queue.poll();   // 첫번째 값 반환 및 제거 비어있을시 null
queue.remove(); // 첫번째 값 제거
queue.clear();  // 초기화

• 첫번째 값 출력

Queue<Integer> queue = new LinkedList<>(List.of(1, 2, 3));

queue.peek();   // 출력

스택(Stack)

데이터를 쌓아올리는 자료구조(Last In First Out)

특징

• 먼저 들어간 자료가 나중에 나옴 LIFO(Last In First Out)
• 시스템 해킹에서 버퍼오버플로우 취약점을 이용한 공격을 할 때 스택메모리의 영역에서 함
• 인터럽트 처리, 수식의 계산, 서브루틴의 복귀 번지 저장 등에 쓰임
• 그래프의 깊이 우선 탐색(DFS)에서 사용
• 재귀적(Recursion) 함수를 호출 할 때 사용

stack 사용법

• 선언

Stack<Integer> stack = new Stack<>();

• 값 추가

Stack<Integer> stack = new Stack<>();

stack.push(1);
stack.push(2);
stack.push(3);

• 값 삭제

Stack<Integer> stack = new Stack<>();

stack.push(1);
stack.push(2);
stack.push(3);

stack.pop();
stack.clear();

• 상단 값 출력

Stack<Integer> stack = new Stack<>();

stack.push(1);
stack.push(2);
stack.push(3);

stack.peek();