0606 ~ 0619

0610 - 테스트 더블 (Test Double)

테스트 더블(Test Double)이란?

xUnit Test Patterns의 저자인 제라드 메스자로스가 만든 용어로 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행할 수 있도록 만들어주는 객체를 말한다.

예를 들어 우리가 데이터베이스로부터 조회한 값을 연산하는 로직을 구현했다고 하자. 해당 로직을 테스트하기 위해선 항상 데이터베이스의 영향을 받을 것이고, 이는 데이터베이스의 상태에 따라 다른 결과를 유발할 수도 있다.

이렇게 테스트하려는 객체와 연관된 객체를 사용하기가 어렵고 모호할 때 대신 해줄 수 있는 객체를 테스트 더블이라 한다.

테스트 더블의 종류

테스트 더블은 크게 Dummy, Fake, Stub, Spy, Mock으로 나뉜다.

1. Dummy

• 가장 기본적인 테스트 더블이다.
• 인스턴스화 된 객체가 필요하지만 기능은 필요하지 않은 경우에 사용한다.
• Dummy 객체의 메서드가 호출되었을 때 정상 동작은 보장하지 않는다.
• 객체는 전달되지만 사용되지 않는 객체이다.

정리하면 인스턴스화된 객체가 필요해서 구현한 가짜 객체일 뿐이고, 생성된 Dummy 객체는 정상적인 동작을 보장하지 않는다.

public interface PringWarning {
    void print();
}

public class PrintWarningDummy implements PrintWarning {
    @Override
    public void print() {
        // 아무런 동작을 하지 않는다.
    }
}

실제 객체는 PrintWarning 인터페이스의 구현체를 필요하지만, 특정 테스트에서는 해당 구현체의 동작이 전혀 필요하지 않을 수 있다. 실제 객체가 로그용 경고만 출력한다면 테스트 환경에서는 전혀 필요 없기 때문이다.
이런 경우에는 print()가 아무런 동작을 하지 않아도 테스트에는 영향을 미치지 않는다.
이처럼 동작하지 않아도 테스트에는 영향을 미치지 않는 객체를 Dummy 객체라고 한다.

2. Fake

• 복잡한 로직이나 객체 내부에서 필요로 하는 다른 외부 객체들의 동작을 단순화하여 구현한 객체이다.
• 동작의 구현을 가지고 있지만 실제 프로덕션에는 적합하지 않은 객체이다.

정리하면 동작은 하지만 실제 사용되는 객체처럼 정교하게 동작하지는 않는 객체를 말한다.

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    protected User() {}
    
    public User(Long id, String name) {
        this.id = id;
        this.name = name;
    }
    
    public Long getId() {
        return this.id;
    }
    
    public String getName() {
        return this.name;
    }
}

public interface UserRepository {
    void save(User user);
    User findById(long id);
}

public class FakeUserRepository implements UserRepository {
    private Collection<User> users = new ArrayList<>();
    
    @Override
    public void save(User user) {
        if (findById(user.getId()) == null) {
            user.add(user);
        }
    }
    
    @Override
    public User findById(long id) {
        for (User user : users) {
            if (user.getId() == id) {
                return user;
            }
        }
        return null;
    }
}

테스트해야 하는 객체가 데이터베이스와 연관되어 있다고 가정한다.

그럴 경우 실제 데이터베이스를 연결해서 테스트해야 하지만, 실제 데이터베이스 대신 가짜 데이터베이스 역할을 하는 FakeUserRepository를 만들어 테스트객체에 주입하는 방법도 있다. 이렇게 하면 테스트 객체는 데이터베이스에 의존하지 않으면서도 동일하게 동작을하는 가짜 데이터베이스를 가지게 된다.

3. Stub

• Dummy 객체가 실제로 동작하는 것 처럼 보이게 만들어 놓은 객체이다.
• 인터페이스 또는 기본 클래스가 최소한으로 구현된 상태이다.
• 테스트에서 호출된 요청에 대해 미리 준비해둔 결과를 제공한다.

정리하면 테스트를 위해 프로그래밍된 내용에 대해서만 준비된 결과를 제공하는 객체이다.

public class StubUserRepository implements UserRepository {
    // ...
    @Override
    public User findById(long id) {
        return new User(id, "Test User");
    }
}

위의 코드처럼 StubUserRepository는 findByID() 메서드를 사용하면 언제나 동일한 id값에 TestUser라는 이름을 가진 User 인스턴스를 반환받는다.
테스트 환경에서 User 인스턴스의 name을 Test User만 받기를 원하는 경우 이처럼 동작하는 객체를 만들어 사용할 수 있다.
물론 이러한 방식의 단점은 테스트가 수정될 경우 Stub 객체도 함께 수정해야 하는 단점이 있다.
우리가 테스트에서 자주 사용하는 Mockito 프레임워크도 Stub와 같은 역할을 해준다.
이처럼 테스트를 위해 의도한 결과만 반환되도록 하기 위한 객체가 Stub이다.

4. Spy

• Stub의 역할을 가지면서 호출된 내용에 대해 약간의 정보를 기록한다.
• 테스트 더블로 구현된 객체에 자기 자신이 호출 되었을 때 확인이 필요한 부분을 기록하도록 구현한다.
• 실체 객체처럼 동작시킬 수도 있고, 필요한 부분에 대해서는 Stub로 만들어서 동작을 지정할 수도 있다.

정리하면 실제 객체로도 사용할 수 있고 Stub 객체로도 활용할 수 있으며 필요한경우 특정 메서드가 제대로 호출되었는지 여부를 확인할 수 있다.

public class MailingService {
    private int sendMailCount = 0;
    private Collection<Mail> mails = new ArrayList<>();

    public void sendMail(Mail mail) {
        sendMailCount++;
        mails.add(mail);
    }

    public long getSendMailCount() {
        return sendMailCount;
    }
}

MailingService는 sendMail을 호출할 때마다 보낸 메일을 저장하고 몇 번 보냈는지를 체크한다. 그리고 나중에 메일을 보낸 횟수를 물어볼 때 sendMailCount를 반환한다.
이처럼 자기 자신이 호출된 상황을 확인할 수 있는 객체가 Spy이다.
이 또한 Mockito 프레임워크의 verify() 메서드가 같은 역할을 한다.

5. Mock

• 호출에 대한 기대를 명세하고 내용에 따라 동작하도록 프로그래밍 된 객체.
• Mockito 프레임워크가 대표적인 Mock 프레임워크.

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {
    @Mock
    private UserRepository userRepository;
    
    @Test
    void test() {
        when(userRepository.findById(anyLong())).thenReturn(new User(1, "Test User"));
        
        User actual = userService.findById(1);
        assertThat(actual.getId()).isEqualTo(1);
        assertThat(actual.getName()).isEqualTo("Test User");
    }
}

0613 - orphanRemoval

부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제해주는 기능이다.

@Entity
public class Parent {

    @Id
    @GeneratedValue
    private Long id;

    private String username;

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> childList = new ArrayList<>();
}

orphanRemoval가 true 시

Parent parent1 = em.find(Parent.class, parent.getId());
parent1.getChildList().remove(0); // delete 쿼리나간다.

자동으로 delete 쿼리가 나간다.

• 이 속성은 참조하는 곳이 하나일 때만 사용해야 한다.
• 특정 엔티티가 개인 소유할 때만 사용해야 한다.
• @OneToOne과 @OneToMany에서만 사용이 가능하다.

CascadeType.ALL + orphanRemovel=true
이 두개를 같이 사용하게 되면 부모 엔티티가 자식의 생명주기를 모두 관리할 수 있게 된다.

0615 - CQRS

CQRS 아키텍처란?

명령(시스템 데이터 변경) 역할을 수행하는 구성 요소와 쿼리(시스템 데이터 조회) 역할을 구새항하는 구성 요소를 나누는 아키텍처

시스템 데이터를 변경하는 코드와 시스템 데이터를 조회하는 코드를 따로 만드는 것, 구현방식이나 시스템 규모에 따라서 DB를 나누기도하고 프로세스를 나누기도 함

• Command : 명령
  • 시스템 데이터 변경
  • ex) 주문 생성, 수정, 취소
• Query : 조회
  • 시스템 데이터 조회
  • ex) 주문 조회
• Responsibility : 책임
  • 구성 요소의 역할
  • 구성 요소 ex) 클래스, 함수, 모듈, 패키지, 웹서버, DB 등
• Segregation : 역할에 따라 구성 요소 나누기

단일 모델의 단점

명령과 쿼리를 구분해 피할 수 있는 문제들

• 기능 추가에 따라 코드의 책임이 모호해지고, 기능마다 다른 테이블에 의존하게 된다
• 명령은 한 영역의 데이터를 다루는데 반해 쿼리는 여러 영역의 데이터를 사용한다.
• 명령과 쿼리는 코드 변경 빈도와 사용자가 다르다. 서로 다른 이유로 모델의 코드가 바뀐다는 것은 책임의 분리가 적절하지 않다는 것이다.
• 기능마다 요구 성능이 다르다. 단일 모델은 기능에 맞는 다양한 성능 향상 기법 적용이 어렵다.
  • ex) 명령 : 사용자 주문 기능, 쿼리 : 백오피스 주문 목록 조회

CQRS의 구현

같은 프로세스, 같은 DBMS

• 코드 수준에서만 명령과 쿼리가 분리된다
• 데이터의 동일성이 보장된다

같은 프로세스, 같은 DBMS, 다른 테이블

• 쿼리 전용 테이블을 사용한다
• 코드 수준, 데이터 수준에서 명령과 쿼리가 분리된다
• 명령이 데이터를 변경할때, 쿼리 전용 테이블도 수정해야한다

같은 프로세스, 다른 DBMS

• Redis를 캐시로 하고 쿼리 DB로 사용하는 경우를 생각해볼 수 있다

다른 프로세스, 다른 DBMS

![image]

• MSA를 생각해볼 수 있다

3가지 변경 전파 전략

CQRS 아키텍처에서 여러 DBMS를 사용하게 된다면 변경 전파 전략도 수립해야 한다

명령이 쿼리 DBMS를 수정

• 구현이 단순
• 쿼리 DB 장애시 데이터 유실 가능성이 있다
• 명령 기능이 쿼리 DB까지 접근하기 때문에 명령 기능의 에러 가능성이 높다

변경 내용 기록 후, 전파기 사용

• 명령 DB에 변경 내용 테이블을 관리해야한다
• 데이터 변경과 변경 내용을 하나의 트랜잭션으로 처리할 수 있어 데이터 유실 방지가 가능하다
• 전파기를 구현해야한다

DB가 제공하는 CDC 사용

• CDC : 데이터베이스에 있는 데이터의 변경을 파악하고 추적하는 소프트웨어 프로세스
• 명령 DB 바이너리 로그를 읽어 변경을 파악하고, 쿼리 DB에 전달할 수 있다
• 명령 코드가 변경 내용을 관리할 필요가 없다

0616 - MSA와 SOA의 차이

SOA, MSA란?

SOA는 서비스 지향 설계 방식(Service Oriented Architecture)
SOA는 서비스 단위로 개발을 하고, 개발된 서비스들을 공유함으로써 재가용성을 늘리고 유연성을 확보하는 것을 목표

MSA는 마이크로 서비스 설계 방식(Micro Service Architecture)
MSA 또한 아주 작은 단위의 서비스로 소프트웨어를 구성함으로써 민첩하고 유연한 설계하는 것을 목표

공유 지향점

SOA는 비지니스 측면에서의 서비스 재사용성을 중요시하여 ESB(Enterprise Service Bus)라는 서비스 채널 이용 -> 서비스 공유, 재사용

MSA는 한 가지 작은 서비스에 집중하여 서비스 공유하지 않고 독립적 실행

• SOA : 재사용을 통한 비용 절감
• MSA : 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응

기술 방식

• SOA는 공통의 서비스를 esb에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
• MSA는 각 독립된 서비스가 노출된 REST API를 사용
• SOA는 서비스를 개발하고 최대한 재가용
• MSA는 서비스가 공유되기 보다 독립적으로 실행되는 것을 지향

0618 - 자바 테스트 격리

테스트 격리란?

테스트는 순서에 상관없이 독립적으로 실행되며 결정적으로 수행되어야 한다. 테스트를 서로 격리하여 한 테스트를 실행하여도 다른 테스트에 영향을 주지 않도록 해야한다.

계층별 테스트

데이터들이 공유되기 때문에 불완전한 테스트를 작성하게 된다. 따라서 데이터베이스를 얼마나 의존하지 않고 테스트를 작성할지 또는 데이터 베이스 상태를 테스트 이전으로 돌릴지에 대해서 신경을 써야 한다.

- Domain(POJO) 계층

• 애플리케이션의 POJO(Model, Utils, etc...)는 JUnit으로 테스트
• 객체는 new 연산자(또는 빌더)로 간단히 인스턴스화
• 각각의 테스트가 실행되기 전에 @BeforeEach에서 인스턴스 초기화
• 데이터베이스를 사용하지 않기 때문에 격리를 걱정할 필요 없음

private Question question;

@BeforeEach
void setUp(){
    question = Question.builder()
        .userId(1L)
        .title(TEST_QUETION_TITLE)
        .content(TEST_QUESTION_CONTENT)
        .build();
}

@DisplayName("조회수 초기값 확인")
@Test
void initValueOfVisits(){
    assertThat(question.getVisits().getVisitCount()).isEqualTo(0L);
}

@DisplayName("조회수 증가")
@Test
void increaseVisits(){
    question.increaseVisits();
    assertThat(question.getVisits().getVisitCount()).isEqualTo(1L);
}

- Service 계층

• 실질적인 비즈니스 로직을 수행
• 실제 데이터베이스 사용
• 트랜잭션이 끝나면 데이터베이스 상태 변경
• 테스트 간 격리가 필요
• 실제 데이터베이스를 사용하면서 계층구조로 이루어져있기 때문에 사실상 통합 테스트가 되버림
• @Transactional을 사용해서 테스트가 종료되면 rollback가능
• Mockito를 이용하면 실제 데이터베이스를 사용하지 않기 때문에 테스트 격리를 고민할 필요가 없다.

- Controller 계층

• @SpringBootTest
  • Spring IoC로 실제 컨트롤러 빈을 사용해서 테스트
  • 실제 데이터베이스 사용
  • 통합 테스트
• @WebMvcTest
  • MockMvc RestAPI 클라이언트 테스트 도구 사용
  • 데이터베이스를 사용하지 않고 단위 테스트 수행

- Repository 계층

• @DataJpaTest
  • Slice Test 진행
  • In Memory로 테스트 수행
  • 자동으로 @Transactional(rollback=true)이 사용됨

인수 테스트

• 시스템이 실제 운영 환경에서 사용될 준비가 되었는지 최종적으로 확인하는 단계
• 실제 운영환경에 맞게 서버를 띄우고 데이터베이스를 사용
• 테스트 격리를 신경쓰지 않으면 테스트가 실패하기 쉬움
• 테스트 단위가 커서 한번 실패하면 디버깅하기 까다로움
• Mock 객체가 아닌 실제 빈을 사용

인수테스트 방법

1. @Transactional : 인수 테스트에서 제대로 작동하지 않음. 요청을 보내는 http client 쪽과 실제 로직을 수행하는 서버로직이 서로 다른 쓰레드에서 실행된다. 테스트 코드에서 어노테이션을 롤백 전략으로 해두어도, 다른 스레드에서 실행되는 서버 사이드 트랜잭션은 그 테스트 코드의 영향을 받지 않고 데이터베이스가 변하게 된다.

2. 매번 테스트 종료시 생성한 픽스처 및 데이터 삭제

3. 매번 테스트 종료시 테이블 Truncate

• Delete보다 Truncate가 좋은 이유

  • 트랜잭션 로그 공간을 적게 차지
  • 쿼리 실행시 행단위로 락을 걸지 않음

• 3-1 @Sql로 SQL 파일 실행

• 3-2 EntityManager 이용(보스독님이 추천하는 방식) 엔티티 매니저로 쿼리를 직접 만들어서 실행하는 방식. 엔티티에 있는 테이블 이름을 가지고온 후 리스트에 저장

데이터 베이스를 주입 받고 테스트를 실행하기 직전 @BeforeEach에서 테이블 이름을 조사한 후 Truncate를 실행. 이렇게 만들어 두면 추후 엔티티가 추가되거나 삭제될 때 동적으로 테이블을 조사하기 때문에 테스트 격리에 투입되는 비용을 줄일 수 있음

정리

• 잘격리된 테스트는 유지보수가 수월
• 더욱 안전한 테스트 작성으로 코드의 품질 보장