[토이프로젝트] TimeLine 2.0 개선 오픈

IT 지식/기타지식|2020. 1. 27. 21:41

설계, 운영 모든면에서 실패

토이프로젝트 TimeLine을 만들어서 오픈했었다. 

개발의 목표는 단순하게 개발 블로그, 채용등에 대해 한번에 볼 수 있는 개발자를 위한 통합 페이지를 만드는 것이었다.

https://wedul.site/626

[토이 프로젝트 소개] 개발자 채용, 기술 블로그 정보를 모아주는 TimeLine

혼자 공부를 집에서 어떻게 하면 효율적일까 고민을 많이했다. 집에서 주구장창 책을 읽고 해보면 스킬이 늘까? 그렇게 해봤지만 그게 정답은 아니었다. 남들에게는 모르겠으나 나에게는 아니었다. 회사에서 하는..

wedul.site

하지만 사용하는데 생각보다 불편한 부분이 많았고 설계부분에도 현재 시스템을 고려하지 않고 만들었던게 운영에 걸림돌이 되어버렸다. 그래서 서비스를 잠정적 중단하고 2.0을 만들어서 오픈하기로 했다.

 

 

설계 실패 요인

실패 요인 1.

- 젠킨스를 실행시키면 별도의 관리포인트가 생길것으로 우려해 batch application을 계속 실행시켰던 부분이 큰 문제였다. 내 서버는 배치, db, api모두 하나의 서버에서 돌아가는데 4기가라는 부족한 메모리 상황에서 불필요한 batch application을 실행시켜서 다른 애플리케이션에서 메모리가 많이 부족하게 만들었다. 그래서 젠킨스를 작은 메모리를 할당하여 실행시키고 batch job을 세분화하여 batch application이 계속 실행되지 않게 하였다.

 

 

각 모듈을 build하는 jenkins job
rss, 스크래핑 등을 진행하는 indexing job
현재 api를 교체하는 job

 

 

실패요인 2.

실패요인1과 같이 시스템의 리소스가 많이 부족한 상황에서 api에 호출이 늘어나면 부하가 걸렸다. 그래서 이를 조금이라도 줄여보기 위해서 api에 비동기를 붙이기로 했다. 하지만 사용하고 있는 rdb에서는 비동기가 지원을 하고 있지 않은 상황에서 어떻게 해야하지 고민했는데 마침 r2dbc mysql이 정식 release했다. 굿굿 그래서 이를 사용해서 적용했다. 실제로 드라마틱하게 api 성능이 오른건 아니지만 그래도 확실히 속도가 더 빨라졌다.

 

실패요인 3.

욕심이 생겨 batch에서 긁은 데이터를 writer를 통해 업데이트 하는게 아니라 별도 kafka에 메시지를 보내서 별도 모듈에서 업데이트를 했다. ㅋㅋ 결국 그 욕심이 적은 리소스에 또 문제를 일으켰고 애플케이션이 메모리부족으로 많이 죽었다 에휴 작은 환경에서 무리한 오버스펙은 오히려 문제를 야기한다는걸 더욱 느끼게 되었다. (심지어 필요없는 레디스도 실행시켰다.)

 

실패요인 4.

UI구성을 router, component 구분없이 하나의 컴포넌트에 구분없이 추가하여 확장성 고려도 path구분도 되지 않는 상황이었다. 이를 해결하지 못해서 결국 기능추가도 공유하기도 어려웠다. 그래서 router를 추가하고 페이지를 만들고 각 page에서 사용할 공통 component를 만들어서 편하게 가져다 쓸 수 있도록 구성했다. 그 결과 이제 페이지 하나 늘려서 컴포넌트를 추가하고 빼는건 일도 아니게 되었다. 그리고 하단의 footer를 없애고 vue-sidebar-menu 라이브러리를 사용하여 보는 페이지 뷰를 늘려주었다. 

 

 

변경된 UI

기존의 UI에는 몇 가지 문제가 있었다. 

 

UI 문제 1.

데이터를 보여주는 영역은 가지고 온 제목, 로고, 데이터등을 다 보여주는데 데이터 유형이 모두 달라서 같은 유형으로 보여주기 어려웠다. 채용의 경우 큰 문제가 되지 않았지만 개발 블로그 경우에는 컨텐츠 표시 형식이 모두 달라서 보여주는 영역마다 다 깨졌다. 그래서 채용은 기존틀을 유지하고 테크는 타이틀과 컨텐츠 대표 이미지를 사용해서 리스트를 모여줬다.

좌, 테크 (기술블로그) 영역 리스팅

 

UI 문제 2.

결국 모든 데이터를 아웃링크로 보내다보니 트래픽이 많이 빠졌다. 이를 해결하려면 내부에서 화면을 보여주는게 좋다고 생각했다. 그래서 iframe을 사용해서 화면을 보여주도록 변경했다. 하지만 iframe을 막은 사이트에 경우에는 아웃링크로 가서 볼 수 있도록 아웃링크로 가는 링크를 만들어주었다.

 

 

 

UI 문제 3.

보고 싶은 업체만 보고 싶은 경우에 볼 수 있는 방법이 없었다. 그래서 이를 해결하기 위해서 상단의 리스트 바를 만들어서 자유롭게 골라서 볼 수 있도록 구성했다.

 

업체 리스팅

 

 

 

회고

2.0을 만들겠다고 생각했을 때 나 혼자서 만들기는 어렵다고 판단해서 같이 전직장(pnpsecure)에서 일했던 친구에게 부탁했다. 친구(https://lelecoder.com/)가 마침 이직을 하기 전이라 놀고 있어서 업무를 많이 진행해줬고 그래서 더 많은 컨텐츠를 가져올 수 있었고 수집된 컨텐츠 정보와 에러 정보를 slack으로 받는 기능등을 추가 받을 수 있었다. 함께하니 더 재밌고 좋았다. 나중에 같이 일할 수 있는 기회가 또 왔으면 좋겠다.

 

수집한 컨텐츠 정보를 알려주는 slack과 에러 발생시 알려주는 slack

 

 

추가된 정보와 변경된 구조 그리고 ui가 모두 맘에 든다 많은 분들이 구경와서 더 좋은 컨텐츠를 모아서 보여줄 수 있는 서비스가 되었으면 좋겠다.

해당 프로젝트는 비영리적 목적으로 해당 코드를 가지고 수정하거나 상업적 용도로 사용하는 것을 금지한다.

http://wedul.space

 

새로워진 TimeLine 2.0

 

댓글()
  1. jayden 2020.01.27 23:23 댓글주소  수정/삭제  댓글쓰기

    좋은 정보네요. 타임라인 사이트 자주 찾아갈게요.

Junit5 Test Container사용하여 테스트 환경 구축하기 (인프런 백기선님 강의 정리)

web/Junit|2019. 12. 26. 15:21

도커와 테스트 (TestContainers)

테스트를 위해서는 운영과 동일한 형태의 개발 환경에서 테스트 하는 것이 중요하다. 하지만 매번 동일하게 환경을 구축할 수 없고 모든 개발 자들과 같은 환경을 맞추기도 쉽지 않다.

그래서 Docker를 이용해서 테스트마다 테스트를 위한 컨테이너를 실행시켜서 테스트하고 컨테이너를 제거해주면 좋은데 그런 기능을 TestContainer를 이용해서 가능하다. 실제로 이번에 이직한 회사에서 동일하게 테스트 환경을 사용하는 것을 봤다. 막연하게 그 기능을 사용할 수 있었지만 이번 Junit5 백기선님 강의를 들어서 확실하게 정리할 수 있어서 좋았다. 역시 듣길 잘했다. 꼭 들어보길 강추한다. 그럼 그 내용을 정리해보자.

테스트 컨테이너(Test Container) 라이브러리 추가 및 설정

https://www.testcontainers.org를 보고 테스트에 필요한 모듈의 라이브러리를 추가하면 된다. 나는 gradle을 사용하여 mysql을 사용해야 하기에 다음과 같이 추가했다.

testCompile "org.testcontainers:testcontainers:1.12.4"
testCompile "org.testcontainers:junit-jupiter:1.12.4"
testCompile "org.testcontainers:mysql:1.12.4"

그리고 생성된 mysql test container에서 사용할 설정 값들에 대한 설정이 필요한대 기존 설정과는 다르게 다음과 같이 별도의 jdbc url을 적어줘야한다. 이도 testcontainer 홈페이지에 모듈 설명에 나와있다.

spring:
  datasource:
    url: jdbc:tc:mysql:5.7.22://localhost:3306/test
    driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver

    dbcp2:
      driver-class-name: com.mysql.jdbc.Driver
      test-on-borrow: true
      validation-query: SELECT 1
      max-total: 1

  jpa:
    show-sql: true

테스트 수행

라이브러리와 연결에 대한 설정을 모두 완료하였으면 테스트를 진행해야한다. 테스트 컨테이너를 이용해서 테스트를 진행하기 위해서는 클래스에 @TestContainers 어노테이션을 붙이고 불러들인 MysqlContainer에 어노테이션 @Container를 붙여주면 된다. 그리고 container가 테스트가 실행될 때 시작하고 종료되면 같이 끝나기 위해서 @BeforeAll과 @AfeterAll을 지정해준다.

package com.wedul.javajunit5studyjunit.docker;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.ActiveProfiles;
import org.testcontainers.containers.MySQLContainer;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;
import javax.transaction.Transactional;
import static org.assertj.core.api.Assertions.*;
/**
 * java-junit5-study
 *
 * @author wedul
 * @since 2019/12/24
 **/
@ActiveProfiles("test")
@SpringBootTest
@Testcontainers
class StudentServiceTest {

    @Autowired
    StudentService studentService;

    @Container
    static MySQLContainer mariaDBContainer = new MySQLContainer();

    @Test
    @DisplayName("학생 추가하기")
    @Transactional
    void create_student_test() {
        studentService.createStudent(Student.builder()
            .studentId(2L)
            .age(10)
            .name("wedul")
            .address("seoul jamsil")
            .build()
        );
    }

    @DisplayName("student 조회 테스트")
    @Test
    @Transactional
    void find_student_test() {
        studentService.createStudent(Student.builder()
            .studentId(2L)
            .age(10)
            .name("wedul")
            .address("seoul jamsil")
            .studentNickname("duri")
            .build()
        );
        Student student = studentService.getStudent(2L);
        assertThat(student).isNotNull();
    }

}

만약 별도록 MysqlContainer처럼 지정이 되어 있지 않은 컨테이너를 올려서 테스트 하고 싶을 때는 GenericContainers를 사용하여 공식 이미지를 다운받아서 사용할수도 있다. 자세한건 강의를 참조하면 좋다.

@Container
static GenericContainer genericContainer = new GenericContainer("mysql");

Docker container 값을 스프링 value로 사용하기

서비스로 올라간 Docker container에 속성을 spring에서 사용하고 싶을때는 Application의 설정값을 읽어서 사용할수 있도록 해주는 ApplicationContextInitializer를 구현하여 값을 application에 전달하여 사용할 수 있다.

우선 ApplicaionContextInitializer를 구현하여 컨테이너 속성 값을 environment에 넘겨주고 이를 스프링 value로 꺼내서 사용하면 된다.

@ActiveProfiles("test")
@SpringBootTest
@Testcontainers
@ContextConfiguration(initializers = StudentServiceTest.ContainerPropertyInitializer.class)
class StudentServiceTest {

    @Autowired
    StudentService studentService;

    @Container
    static MySQLContainer mySQLContainer = new MySQLContainer();

    @Value("${container.databaseName}")
    private String databaseName;

    @Test
    @DisplayName("학생 추가하기")
    @Transactional
    void create_student_test() {
        System.out.println(databaseName);
        studentService.createStudent(Student.builder()
            .studentId(2L)
            .age(10)
            .name("wedul")
            .address("seoul jamsil")
            .build()
        );
    }

    @DisplayName("student 조회 테스트")
    @Test
    @Transactional
    void find_student_test() {
        studentService.createStudent(Student.builder()
            .studentId(2L)
            .age(10)
            .name("wedul")
            .address("seoul jamsil")
            .studentNickname("duri")
            .build()
        );
        Student student = studentService.getStudent(1L);
        assertThat(student).isNotNull();
    }

    static class ContainerPropertyInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {

        @Override
        public void initialize(ConfigurableApplicationContext applicationContext) {
            TestPropertyValues.of("container.databaseName=" + mySQLContainer.getDatabaseName())
                .applyTo(applicationContext.getEnvironment());
        }
    }

}

Docker Compose를 사용하여 테스트하기

매번 새로운 설정을 프로그램상이나 yml으로 정의하는건 너무 번거롭다. 그래서 생성할 컨테이너들을 한번에 기재해서 컨테이너로 올릴 때 사용하는 docker compose를 사용하면 편리하다. 간단하게 mysql 컨테이너를 올릴 yml을 만들고 테스트에서 사용해보자. docker-compose 파일을 읽어들일 때는 DockerComposeContainer를 사용해서 올리면 된다.

### docker-compose.yml 파일

version: '3.1'

services:
  maria:
    image: mariadb:latest
    restart: "always"
    ports:
    - "13306:3306"
    environment:
      - MYSQL_ROOT_PASSWORD=dbsafer00
      - MYSQL_DATABASE=test
      - MYSQL_USER=wedul_dev
      - MYSQL_PASSWORD=dbsafer00
// 사용방법
@Container
static DockerComposeContainer composeContainer =
    new DockerComposeContainer(new File("src/test/resources/docker-compose.yml"));

그리고 위에서는 host에서 연결할 port 13306을 지정하였으나 실제로는 지정하지 않고 하면 랜덤포트를 자유롭게 이용하기 때문에 더 좋을 것 같다. 왜냐하면 해보니까 내가 지정한 포트가 다른 개발자 컴퓨터에서는 이미 다른 컨테이너로써 운영중일 수도 있기 때문에 랜덤 포트를 사용하게 하는게 좋은 것 같다.

ports:
- "3306"

 

근데 사용해보니 단점이 있다. container_name과 같이 몇개의 docker-compose에서 제공하는 몇개의 부가 속성들을 제대로 읽어들이지 못하고 오류를 뱉어내기도 한다. 다음과 같이 에러가 발생되어서 지웠다 ㅜㅜ

docker-compose.yml has 'container_name' property set for service 'maria' but this property is not supported by Testcontainers, consider removing it

docker-compose를 매번 테스트할때마다 레포지토리에 dev-tool에 놔뒀다가 사용했었는데 확실히 편해지고 좋을 것 같다. 잘 활용해보자.

출처 : https://www.inflearn.com/course/the-java-application-test
github : https://github.com/weduls/junit5

댓글()

Spring Junit5 test Mockito (백기선님 인프런 강의)

web/Junit|2019. 12. 23. 21:28

mockito는 실제 객체와 비슷하게 동작하도록 하여 검증할 수 있는 방법을 제공해주는 라이브러리 이다. 

spring-boot-starter-test 모듈에 기본적으로 포함되어 있으며, 이 모듈을 사용하지 않을 경우 mockito-core, mockito-junit-jupiter 모듈을 추가하면 된다.

 

Mock 객체 만들기

Mock 객체를 만들어서 테스트를 진행할 수 있다. Mock객체로 만들고 싶은 객체에 @Mock 어노테이션을 달기만 하면 되는데 이때 만들어진 Mock 객체는 Null이기 때문에 그렇게 하지 않기 위해서 @ExtendWith(MockitoExtension.class)를 추가한다.

@ExtendWith(MockitoExtension.class)
class MockWedulTest {

    @Mock
    WedulRepository wedulRepository;

    WedulService wedulService;

    @BeforeEach
    void setup() {
        this.wedulService = new WedulService(wedulRepository);
    }

    @Test
    @DisplayName("Mock test")
    void mock_test() {

    }

}

모든 Mock 객체의 반환 타입은 다음과 같다.

  • 객체는 Null
  • Option 타입은 Optional.empty 리턴
  • Primitive 타입은 기본 Primitive 값
  • 콜렉션은 비워있는 콜렉션
  • void 반환값의 메소드는 아무런 일이 발생되지 않는다.

 

Stubbing

 

Mock 객체에  원하는 동작을 미리 지정해주는 것을 stub라고 하는데 이를 한번 수행해보자.

여러가지 stub 있겠지만 대표적으로 when을 많이 사용한다.

@Test
@DisplayName("Mock test")
void mock_test() {
	Wedul wedul = new Wedul();

	when(wedulRepository.getWedul(anyLong())).thenReturn(wedul);
	assertThat(wedulService.getWedul(1L)).isEqualTo(wedul);
}

 

Stubbing 확인

Mock 객체의 특정 행위가 몇번 호출되었는지, 추가적으로 interaction이 발생되었는지 여부등도 확인이 가능하다.

@Test
@DisplayName("stubbing verify 테스트")
void verify_stub_test() {
	Wedul wedul = new Wedul();
    when(wedulRepository.getWedul(anyLong())).thenReturn(wedul);
    assertThat(wedulRepository.getWedul(1L)).isEqualTo(wedul);

	// 목 객체의 getWedul()이 한번 실행되었는지 검증
    verify(wedulRepository, times(1)).getWedul(1L);
    // 목 객체 validate()가 한번도 안 실행되었는지 검증
    verify(wedulRepository, never()).validate();
    // 해당 Mock이 더 이상 interactiondl 발생되지 않아야 한다.
    verifyNoMoreInteractions(wedulRepository);
}

 

BDD Mockito

BDD(Behaviour-Driven Development)는 행동 기반 테스트인데 Mockito에서 제공하는 기능들을 이용하면 Given / When / Then 순서대로 검증이 가능하다.

- when이라는 subbing 메서드와 동일한 역할을 하는 given은 BDD를 위해서 when 대신 Given으로 사용한다.

- then을 통해서 검증이 가능하다.

@Test
@DisplayName("BDD 테스트")
void bdd() {	
	// given
    Wedul wedul = new Wedul();
    given(wedulRepository.getWedul(1L)).willReturn(wedul);

	// when
    Wedul selectWedul = wedulService.getWedul(1L);

	// then
    assertThat(selectWedul).isEqualTo(wedul);
    then(wedulRepository).should(times(1)).getWedul(1L);
    then(wedulRepository).shouldHaveNoMoreInteractions();
}

 

출처 : https://www.inflearn.com/course/the-java-application-test/

Github : https://github.com/weduls/junit5

댓글()

Spring BootJunit5 테스트 (백기선님 인프런 강의)

web/Junit|2019. 12. 23. 20:34

Junit 5 테스트

Junit4를 잘 알고 있던건 아니지만 새로 입사한 회사에서 Junit5를 사용하여 테스트 코드를 짜기때문에 더 잘 알고 싶어 공부하게 되었다. 그 중 백기선님의 Junit5 테스트 코드 관련 인강을 인프런에서 듣게 되었다. 내용이 너무 좋았고 그동안 몰랐고 정리가 되지 않았던 부분을 많이 알게 되었다. 이를 아주 간략하게만 정리해봤다. 가격이 그리 비싸지 않기 때문에 한번쯤은 꼭 보는걸 추천한다.
https://www.inflearn.com/course/the-java-application-test/#


소개

  • Junit5는 Junit3, 4에서 사용하던 Junit Platform 구현체 Vintage대신 Jupiter를 사용해서 TestEngine Api를 사용하는 test 프레임워크이다.
  • Spring Boot 2.2.x가 릴리즈된 이후로는 공식적으로 Spring-boot-starter-tester에 제공되고 있다.
  • Junit4까지는 test 코드가 public 하여야 했지만 Junit5 부터는 클래스, 메소드 모두 public하지 않아도 된다.


추가된 기능

Test 이름 지정
테스트의 이름을 지정할 때 기존에 _(언더스코어)를 사용하여 많이 작명하였었다.

@Test
public void when_join_not_error() {
}

하지만 이와 같은 방식으로 사용하게 되면 테스트가 실행되었을 때 내용을 보는데 많이 불편하다.

이런 불편함을 junit5의 Display 전략을 이용하면 편하게 볼 수 있다.

첫 번째 방법으로 @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class)을 사용하여 _(언더스코이)이름을 언더스코어를 제거한 이름으로 만들어 줄 수 있다.

@DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class)
class WedulTest {

    @Test
    void when_join_not_error() {

    }

}

하지만 단순하게 _(언더스코어)만 바꿔줬다고 가시적으로 보이지는 않는다. 그래서 테스트 이름을 직접 지정해 줄 수 있다.

@Test
@DisplayName("가입시 에러가 발생하는지 테스트")
void when_join_not_error() {

}


Assert 방법
기본적으로 Junit5에서 제공하는 Assert는 아래와 같은 방식으로 사용할 수 있다.

image

  • expected : 기대하는 결과물
  • actual : 실제 값
  • message : 기대하는 결과물과 실제 값이 달랐을 때 발생될 문자

예를 들어 Wedul이라는 객체에 id를 가져왔을 때 1L인지 테스트하고 아니면 "아이디가 다릅니다." 메시지가 호출하게 해보자.

@Test
@DisplayName("가입시 에러가 발생하는지 테스트")
void when_join_not_error() {
    Wedul wedul = new Wedul();

    assertEquals(wedul.getId(), 1L, "아이디가 다릅니다.");
}

image

하지만 이렇게 작업 하는 것 보다 테스트를 편하게 도와주는 AssertJ 라이브러리를 사용해서 테스트 하면 더욱 편하다. 실제로 이 방식으로 팀에서도 하고 있어서 사용하는데 편했다.

assertThat(wedul.getId).isEqual(1L);

isEqual 이외에도 isNotNull, isNull 등 다양하게 확인이 가능하다.


특정 조건이 맞는 경우만 테스트 진행
assumeTrue, assumingThat를 사용하여 조건이 일치 할 때만 테스트를 진행하도록 할 수 있다.

// 시스템 환경설정의 profile이 dev일 때만 밑에 기능 테스트 가능!
assumeTrue("dev".equalsIgnoreCase(profile));

// assumingTest를 통해 특정 조건이 가능했을 때, 다음파라미터의 테스트 가능
assumingThat("dbafer".equals("dbsafer"), () -> {
    assertThat(study.getLimit()).isEqualTo(0);
});

만약 조건이 맞지 않으면 다음과 같이 테스트가 중지된다.
image


특정 동작하는 테스트들만 그룹화하여 테스트 하기
테스트 코드를 만들었을 때 특정 동작을 하는 테스트 코드들만 그룹화하고 필요 시 이들만 테스트 하고 싶을 수 있다. 이때 @Tag("그룹명")을 통해 그룹화 할 수 있다.

@Test
@DisplayName("가입 오류 테스트")
@Tag("quick")
void when_join_not_error() {}

위와 같이 @Tag로 묶고 해당 태그가 붙은 테스트만 실행 시키고 싶은 경우에 Run/Debug Configurations 다이얼로그를 띄우고 Test Kind를 Tag로 변경한 뒤 Tag Expression에 테스트 하고자하는 태그명을 적어주면 된다.
image


커스텀 태그 만들기
test를 위해서 태그를 붙이다 보면 동일한 동작을 하는 test method들에 동일한 태그를 반복해서 붙여줘야할 때가 있다. 아주 귀찮다. 이를 해결하기 위해 커스텀 태그를 만들어서 사용할 수 있다.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Tag("quick")
@Test
public @interface QuickTag {
}

// 이렇게 공통 태그를 묶어서 커스텀 태그를 만들 수 있다.
@DisplayName("가입 오류 테스트")
@QuickTag()
void when_join_not_error() {
    Wedul wedul = new Wedul();

    assertEquals(wedul.getId(), 1L, "아이디가 다릅니다.");
}


반복 테스트하기
테스트를 몇회 이상 반복하고 싶을 때 @RepeatedTest 어노테이션을 사용해서 테스트 할 수 있다. 그리고 RepetitionInfo를 매개변수로 받아 현재 반복 정보를 확인 할 수 있다. 그리고 name에 별도 인자값을 주어 현재 반복 테스트 정보를 이용하여 테스트 이름을 만들 수 있다.

@DisplayName("반복 테스트")
@RepeatedTest(value = 10, name = "{currentRepetition}/{totalRepetition} {displayName}")
void repeatTest(RepetitionInfo repetitionInfo) {
    System.out.println("반복 테스트");
}

image


Parameter를 받아서 테스트 하기
테스트를 진행할 parameter를 받아서 테스트를 진행 할 수 있다. 이때 파라미터로 보내는 메서드는 static하고 이름이 같아야 한다.

@ParameterizedTest(name = "{index} {displayName} message={0}")
@MethodSource()
void parameterTest(String str) {
    System.out.println(str);
}

static Stream<Arguments> parameterTest() {
    return Stream.of(
      Arguments.of("cjung"),
        Arguments.of("wedul")
    );
}

마찬가지로 @ParameterizedTest value에 이름을 index, index 등으로 테스트 정보를 기입할 수 있다.
image


Parameter 조작하여 테스트 하기
테스트에 들어오는 parameter를 조작하여 사용할 수 있다. 우선 SimpleArgumentConverter를 사용하면 들어온 데이터를 바로 다른 타입으로 변경해서 파라미터로 사용할 수 있게 해준다.

@ParameterizedTest(name = "{index} {displayName} message={0}")
@MethodSource()
void parameterConvertTest(@ConvertWith(WedulConverter.class) Wedul wedul) {
    System.out.println(wedul.getId());
}

static Stream<Arguments> parameterConvertTest() {
    return Stream.of(
        Arguments.of("1"),
        Arguments.of("2")
    );
}

static class WedulConverter extends SimpleArgumentConverter {
    @Override
    protected Object convert(Object source, Class<?> targetType) throws ArgumentConversionException {
        assertThat(source.getClass()).isEqualTo(String.class);
        return new Wedul(Long.parseLong(source.toString()));
    }
}

그리고 Aggregator를 이용하여 들어온 파라미터들을 합쳐서 파라미터를 제공해줄 수 있다.

@ParameterizedTest(name = "{index} {displayName} message={0}")
@MethodSource()
void parameterAggregatorTest(@AggregateWith(WedulAggregator.class) Wedul wedul) {
    System.out.println(wedul.getId());
    System.out.println(wedul.getBalance());
}

static Stream<Arguments> parameterAggregatorTest() {
    return Stream.of(
        Arguments.of("1", 21),
        Arguments.of("2", 41)
    );
}

static class WedulAggregator implements ArgumentsAggregator {
    @Override
    public Object aggregateArguments(ArgumentsAccessor accessor, ParameterContext context) throws ArgumentsAggregationException {
        return new Wedul(accessor.getLong(0), accessor.getInteger(1));
    }
}


테스트 인스턴스
테스트 간의 의존관계가 있기 때문에 클래스에 있는 모든 테스트들은 서로 다른 객체에서 실행된다. 그렇기 때문에 테스트에서 클래스 내부에 있는 인스턴스를 접근해서 값을 변경해도 다른 테스트에서 해당 데이터를 접근하면 기존 값으로 되어있다. 진짜 그런지 인스턴스 변수 값을 조작해서 찍어보고 객체의 hash값을 찍어보자.

public class WedulTestInstance {

    int value = 1;

    @Test
    void test_1() {
        System.out.println(this);
        System.out.println(value++);
    }

    @Test
    void test_2() {
        System.out.println(this);
        System.out.println(value++);
    }

}

image

해시값도 같고 인스턴스 변수도 변하지 않는다는 걸 볼수 있다. 이를 해결하기 위해서 @TestInstance(TestInstance.Lifecycle.PER_CLASS)를 클래스에 지정하여 클래스당 인스턴스를 하나만 만들게 할 수 있다. 이러면 value도 변하고 해시값도 같은 걸 확인할 수 있다.
image


테스트 순서
테스트의 순서를 경우에 따라 지정하고 싶은 경우에는 클래스에 어노테이션으로 @TestMethodOrder를 사용하여 지정하는데 그 구현체로는 MethodOrder에는 OrderAnnotation, Alphanumeric, Random이 존재한다. 그리고 각 메서드에 @Order(순서)를 지정하여 진행할 수 있다.

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
public class TestOrder {

  @Test
  @Order(0)
  void second() {
      System.out.println(1);
  }

  @Test
  @Order(1)
  void first() {
      System.out.println(2);
  }

}


테스트 전역 properties
전역으로 설정가능한 테스트 속성을 추가하여 사용할 수 있다. 위치는 test/resources에 junit-Platform.properties 파일을 만들어서 진행하고 인텔리제이에 resources를 추가한다. 만약 메소드에 더 우선순위가 높은 애노테이션이 붙어있으면 그 설정이 우선이 된다.
image

## 대표 설정 값들
// 클래스마다 하나의 인스턴스 생성 (적용)
junit.jupiter.testinstance.lifecycle.default = per_class

// Disabled 무시하고 실행하기
junit.jupiter.conditions.deactivate = org.junit.*DisabledCondition


Junit5 확장팩
Junit5에서 사용 할 확장 모델을 만들어서 테스트를 편하게 만들 수 있다. 사용할 때는 클래스에 @ExtendWith(확장팩 클래스.class)를 통해서 진행할 수 있다. 확장팩에 사용할 수 있는 리스트는 다음과 같다.
image
Extension을 만들고 사용하는 부분은 이곳 참조.
https://github.com/weduls/junit5/blob/master/java-junit5-study-junit/src/test/java/com/wedul/javajunit5studyjunit/extensions/FindSlowTestExtension.java


변경된 기능

Junit4에서는 @Before, @BeforeClass, @After, @AfterClass를 사용하여 테스트 사용 전, 후에 대하여 setup등을 진행하였다. Junit5에서도 동일한 기능을 제공하는데 이름만 변경되었다.

Junit4 Junit5 기능
@Before @BeforeEach 테스트 마다 실행되기전 실행
@BeforeClass @BeforeAll 테스트 클래스 당 테스트 전 실행되는 메서드, static 메서드 (Test Instance 전략 변경 시 non static 가능)
@After @AfterEAch 테스트 마다 실행된 후 실행
@AfterClass @AfterAll 테스트 클래스 당 테스트 후 실행되는 메서드, static 메서드 (Test Instance 전략 변경 시 non static 가능)



출처 : https://www.inflearn.com/course/the-java-application-test/#

Github : https://github.com/weduls/junit5


댓글()

Fast Forword와 merge 그리고 rebase 정리

IT 지식/Git|2019. 12. 13. 00:01

5년차가 될정도로 개발을 어느정도 진행했지만 아직까지도 git에 대한 정리가 잘 되지 않는다.

 

공부도 하고 정리도 했었지만 실상 회사에서 주구장창 브랜치 만들고 머지만 해서 진행했기 때문에 fast forword를 하고 merge, rebase하는 것과 안하고 하는것의 방법을 잘 알지 못했다.

 

개념은 알아도 직접 많이 해보지 않으면 그게 와닿지 않는 것 같다.

그럼 현재 이직한 회사에서는 이 방법을 많이 사용하기에 정리를 해서 까먹지 않도록 해보자.

 

Merge

Merge는 이미 우리가 익히 알고 있듯이 두 개의 브랜치를 합치는 걸 의미한다. 그럼 fast forword를 하고 merge를 하면 어떻게 되는지 보자.

현재 이렇게 되어있는 상황에서 feature/si를 fast forword 포함해서 merge 해보겠다.  우선 master로 checkout하고 머지하려고 하는 feature/test 브랜치 우측클릭하여 머지를 해보자.

그럼 master가 feature/si의 커밋 위치로 가있는 것을 알 수 있다.

그럼 다시 마스터를 커밋하기 전으로 돌리고 다시 non fast forword를 해보자.

우선 다시 돌리자.

그리고 source tree에서는 global옵션 - Git에서 "병합 시 fast-forword를 사용하지 않고 항상 커밋을 생성"을 선택하고 다시 merge 해보자.

그러면 아래와 같은 모양으로 feature/si의 브랜치는 그대로 있고 master의 브랜치는 더 앞으로 가있는 것을 볼 수 있다.

 

그럼 과연 fast forword가 정확히 무엇인가?? 

궁금하다.

 

찾아보니 fast forword는 병합하려는 브랜치에 새로운 커밋이 없는 상황에서 발생되며 merge가 된 브랜치의 최신 커밋으로 head가 옮겨지는 것을 말한다.

 

위의 예에서 보면 master에서 분기된 feature/si브랜치가 새로운 커밋을 가지고 있고 master는 feature/si가 분기 된 이후에 새로운 커밋이 없는 상황이었다. 이때 git merge feature/si를 하게 되면 master는 feature/si 마지막 커밋으로 옮겨지고 한줄로 이어서 보여지는 아래 그림 오른쪽 처럼 되게 된다. 

 

하지만 이는 이력관리하기가 어렵기 때문에 merge하는것처럼 보여주고 이력관리를 위해서 --no-ff 옵션을 붙여서 머지하게 되면 왼쪽처럼 히스토리도 남고 master와 breanch의 위치가 구분되게 된다.

Rebase

rebase는 feature 브랜치의 커밋을 새로 rebase되는 커밋의 parent commit으로 된다. 이렇게 하게 되면 히스토리가 깔끔하게 보인다.

우선 rebase를 진행하기 위해 feature 브랜치로 checkout하고 rebase를 진행할 마스터 브랜치를 누르고 리베이스를 진행한다.

그럼 아래처럼 master위에 feature 브랜치가 위로 붙는 구조가 될것이다.  

이 상태에서 마스터로 체크아웃 하고 feature/si로 merge를 하면 fast forword가 되어 둘이 동일한 커밋을 바라보게 된다.

명령어로 정리하면 다음과 같다.

git checkout feature/si
git rebase master
git checkout master
git merge feature/si

 

 

하지만 이렇게 되면 브랜치의 히스토리를 확인하기가 어렵다. 만약 히스토리를 확인하고 싶으면 아래 명령어를 사용하면 히스토리를 확인할 수 있다.

git checkout feature/si
git rebase master
git checkout master
git merge --no-ff feature/si

 

 

어렵다 ㅋㅋ git은 해도해도 헷갈린다. 

만약 참고하시고 이상한 부분 있으면 말씀 부탁드립니다~

댓글()

RestHighLevelClient를 사용하여 search after 기능 구현하기

web/Spring|2019. 11. 14. 17:55

https://wedul.site/541에서 search after 기능을 사용해서 검색을 하는 이유를 알아봤었다.

그럼 spring boot에서 RestHighLevelClient를 이용해서 search after를 구현을 해보자.

 

1. Mapping

우선 index가 필요한데 간단하게 상품명과 지역 가격정보들을 가지고 있는 wedul_product 인덱스를 만들어 사용한다.

{
    "settings": {
        "index": {
            "analysis": {
                "tokenizer": {
                    "nori_user_dict": {
                        "type": "nori_tokenizer",
                        "decompound_mode": "mixed",
                        "user_dictionary": "analysis/userdict_ko.txt"
                    }
                },
                "analyzer": {
                    "wedul_analyzer": {
                        "tokenizer": "nori_user_dict",
                        "filter": [
                            "synonym"
                        ]
                    }
                },
                "filter": {
                    "synonym": {
                        "type": "synonym",
                        "synonyms_path": "analysis/synonyms.txt"
                    }
                }
            }
        }
    },
    "mappings": {
        "dynamic": "false",
        "properties": {
            "productId": {
                "type": "keyword"
            },
            "place": {
                "type": "text",
                "fields": {
                    "keyword": {
                        "type": "keyword"
                    }
                }
            },
            "message": {
                "type": "text"
            },
            "query": {
                "type": "percolator"
            },
            "name": {
                "type": "text",
                "analyzer": "wedul_analyzer",
                "fields": {
                    "keyword": {
                        "type": "keyword"
                    }
                }
            },
            "price": {
                "type": "integer"
            },
            "updateAt": {
                "type": "date",
                "format": "epoch_second"
            },
            "createAt": {
                "type": "date",
                "format": "epoch_second"
            }
        }
    }
}

값은 적당하게 3개정도 삽입하였다.

저장되어 있는 초기값.

 

2. 라이브러리 

사용에 필요한 라이브러리들을 gradle을 사용해서 추가한다. 

plugins {
    id 'org.springframework.boot' version '2.2.0.RELEASE'
    id 'io.spring.dependency-management' version '1.0.8.RELEASE'
    id 'java'
}

ext {
    set('elasticsearch.version', '7.4.2')
}

group = 'com.wedul'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'

repositories {
    mavenCentral()
    maven { url "https://plugins.gradle.org/m2/" }
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    compileOnly 'org.projectlombok:lombok'
    compile group: 'org.apache.commons', name: 'commons-lang3', version: '3.9'
    compile group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.10.0'
    annotationProcessor 'org.projectlombok:lombok'
    testCompile group: 'org.mockito', name: 'mockito-all', version:'1.9.5'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

    // gson
    compile group: 'com.google.code.gson', name: 'gson', version: '2.8.6'

    // elasticsearch
    compile 'org.elasticsearch.client:elasticsearch-rest-high-level-client:7.4.2'
    compile group: 'org.elasticsearch', name: 'elasticsearch', version: '7.4.2'
}

 

 

3.RestHighLevelClient configuration

restHighLevelClient 사용을 위한 Configuration 파일을 만들어주는데 id와 pw는 AppConfig라는 별도 properties를 관리하는 bean에서 받아서 사용하는데 base64로 인코딩되어있어서 이를 decoding후 사용한다. (부족한 코드는 글 맨 아래있는 github 링크 참조)

package com.wedul.study.common.config;

import com.wedul.study.common.util.EncodingUtil;
import lombok.extern.slf4j.Slf4j;
import org.apache.http.HttpHost;
import org.apache.http.auth.AuthScope;
import org.apache.http.auth.UsernamePasswordCredentials;
import org.apache.http.client.CredentialsProvider;
import org.apache.http.impl.client.BasicCredentialsProvider;
import org.elasticsearch.client.RestClient;
import org.elasticsearch.client.RestClientBuilder;
import org.elasticsearch.client.RestHighLevelClient;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;

/**
 * study
 *
 * @author wedul
 * @since 2019-11-07
 **/
@Configuration
@Slf4j
public class ElasticsearchClientConfig implements FactoryBean<RestHighLevelClient>, InitializingBean, DisposableBean {

    @Autowired
    AppConfig appConfig;

    private RestHighLevelClient restHighLevelClient;

    @Override
    public RestHighLevelClient getObject() {
        return restHighLevelClient;
    }

    @Override
    public Class<?> getObjectType() {
        return RestHighLevelClient.class;
    }

    @Override
    public void destroy() {
        try {
            if (null != restHighLevelClient) {
                restHighLevelClient.close();
            }
        } catch (Exception e) {
            log.error("Error closing ElasticSearch client: ", e);
        }
    }

    @Override
    public boolean isSingleton() {
        return false;
    }

    @Override
    public void afterPropertiesSet() {
        restHighLevelClient = buildClient();
    }

    private RestHighLevelClient buildClient() {
        try {
            String id = EncodingUtil.decodingBase64(appConfig.getElasticsearchConfig().getId());
            String pw = EncodingUtil.decodingBase64(appConfig.getElasticsearchConfig().getPw());

            // 계정 설정
            final CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
            credentialsProvider.setCredentials(AuthScope.ANY,
                new UsernamePasswordCredentials(id, pw));

            // client 설정
            RestClientBuilder builder = RestClient.builder(
                new HttpHost(appConfig.getElasticsearchConfig().getIp(),
                    appConfig.getElasticsearchConfig().getPort(), "http"))
                .setHttpClientConfigCallback(httpClientBuilder -> httpClientBuilder.setDefaultCredentialsProvider(credentialsProvider));

            restHighLevelClient = new RestHighLevelClient(builder);
        } catch (Exception e) {
            log.error(e.getMessage());
        }
        return restHighLevelClient;
    }

}

 

 

4. Handler 추가

자주 사용되는 Elasticsearch 문법을 처리하기 위해서 만들어 놓은 ElasticsearchHandler에 search after에 사용 될 메소드를 추가한다. search after는 sort 필드가 없으면 사용이 불가능 하기 때문에 sort 필드가 없는 경우 에러를 전달한다.

public static SearchSourceBuilder searchAfter(Map<String, SortOrder> sortFields, QueryBuilder query, Object[] searchAfter, int size) {
    return searchAfterBuilder(sortFields, query, searchAfter,  size);
}

public static SearchSourceBuilder searchAfter(Map<String, SortOrder> sortFields, QueryBuilder query, Object[] searchAfter) {
    return searchAfterBuilder(sortFields, query, searchAfter, 20);
}

private static SearchSourceBuilder searchAfterBuilder(Map<String, SortOrder> sortFields, QueryBuilder query, Object[] searchAfter, int size) {
    SearchSourceBuilder builder = new SearchSourceBuilder();

    if (CollectionUtils.isEmpty(sortFields)) {
        throw new InternalServerException("잘못된 필드 요청입니다.");
    }

    sortFields.forEach((field, sort) -> {
        builder.sort(field, sort);
    });
    builder.size(size);
    builder.query(query);

    if (ArrayUtils.isNotEmpty(searchAfter)) {
        builder.searchAfter(searchAfter);
    }

    return builder;
}

 

 

5. 기능 구현

위의 기능들을 이용해서 실제로 구현해보자. productService와 productRepository 클래스를 통해서 구현하였다. 자세한 설명없이 간단하기 때문에 소스를 보면 알 수 있다. 

 

우선 최종 결과물로 사용될 클래스는 ElasticResult인데 다음과 같이 현재 요청이 마지막인지 표시하는 isLast와 다음 요청을 위해 보내줘야 하는 cursor값과 결과값 전체 total과 결과 리스트 list 필드가 존재한다.

@Builder
@Data
public class ElasticResult<T extends ElasticsearchDto> {

    private boolean isLast;
    private long total;
    private List<T> list;
    private Object[] cursor;

}

 

그 다음 service로직을 통해 결과를 얻어서 위 ElasticResult에 결과를 담아보자. products 메서드는 요청을 받아서 elasticsearch에 실제 조작요청을 하는 productRepository에 동작을 요청하고 값을 받아서 처리하는 메서드이다. 그리고 extractProductList는 결과값에서 ProductDto 값을 뽑아내는 메서드이다.

public ElasticResult<ProductDto> products(String index, Object[] searchAfter, int size) throws IOException {
    SearchResponse searchResponse = productRepository.products(index, searchAfter, size);
    SearchHits searchHits = searchResponse.getHits();
    int hitCnt = searchHits.getHits().length;
    boolean isLast = 0 == hitCnt || size > hitCnt;

    return ElasticResult.<ProductDto>builder()
        .cursor(isLast ? null : searchHits.getHits()[hitCnt - 1].getSortValues())
        .isLast(isLast)
        .list(extractProductList(searchHits))
        .total(searchHits.getTotalHits().value)
        .build();
}

private List<ProductDto> extractProductList(SearchHits searchHits) {
    List<ProductDto> productList = new ArrayList<>();

    searchHits.forEach(hit -> {
        Map<String, Object> result = hit.getSourceAsMap();

        productList.add(ProductDto.builder()
            .name(String.valueOf(result.get("name")))
            .productId(String.valueOf(result.get("productId")))
            .place(String.valueOf(result.get("place")))
            .price(Integer.valueOf(result.get("price").toString()))
            .updateAt(Long.valueOf(result.get("updateAt").toString()))
            .createAt(Long.valueOf(result.get("createAt").toString())).build());
    });

    return productList;
}

 

그리고 마지막으로 es에 직접적으로 콜을 하는 productRepository 이다. 여기서 정렬 키워드는 name과 place를 사용한다.

public SearchResponse products(String index, Object[] searchAfter, int size) throws IOException {
    SearchRequest searchRequest = new SearchRequest(index);
    Map<String, SortOrder> sorts = new HashMap<String, SortOrder>() {
        {
            put("name.keyword", SortOrder.DESC);
            put("place.keyword", SortOrder.DESC);
        }
    };

    SearchSourceBuilder searchSourceBuilder = ElasticsearchHandler.searchAfter(sorts, QueryBuilders.matchAllQuery(), searchAfter, size);
    searchRequest.source(searchSourceBuilder);
    return restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT);
}

 

 

6. 테스트

그럼 위에 내용이 잘 구현되었는지 테스트를 해보자. 총 3개의 데이터가 있는데 이 데이터를 1개씩 search after를 통해서 값을 받아서 저장하고 한번에 출력하도록 해보자.

@Test
@DisplayName("search after")
public void searchAfter() throws IOException {
    ElasticResult<ProductDto> result = productService.products(PRODUCT_INDEX, new Object[]{}, 1);
    List<ProductDto> productDtos = new ArrayList<>();

    while(result != null && !result.isLast()) {
        productDtos.addAll(result.getList());
        result = productService.products(PRODUCT_INDEX, result.getCursor(), 1);
    }
    productDtos.addAll(result.getList());

    productDtos.forEach(productDto -> {
        System.out.println("이름 : " + productDto.getName());
        System.out.println("장소 : " + productDto.getPlace());
    });
}

결과는 정상적으로 3가지 모두 잘 출력되는 걸 알 수있다.

 

우선 기능 구현을 해보기 위해서 진행하였는데 더 다듬어야 할 것같다.

자세한 소스는 github참조

댓글()

객체지향의 사실과 오해 3 ~ 4장

Book Review|2019. 11. 5. 18:12
객체지향의 사실과 오해
국내도서
저자 : 조영호
출판 : 위키북스 2015.06.17
상세보기

3. 타입과 추상화

추상화는 어떤 내용을 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다. 그 방법으로 사물간의 차이점을 빼고 공통점을 일반화하여 단순하게 만들고 불필요한 세부사항을 제거하여 단순화 하는 것이다. 즉 복잡성을 이해하기 쉬운 수준으로 단순화하는 것이다.

 

이런 추상화 개념을 이용해서 객체지향에 대입해서 생각해보자.

 

그룹화

각 객체는 명확한 경계를 가지고 서로 구별할 수 있는 구체적인 사람이나 사물을 말한다.

여러 객체에서 공통적인 요소를 뽑아서 그룹화 하면 복잡성을 효과적으로 감소 시킬 수 있다. 예를 들어 토끼, 강아지 등을 동물이라는 공통의 그룹으로 묶고 사과, 딸기 등을 과일이라는 공통의 그룹으로 묶으면 차이점을 빼고 공통점만을 취해 단순화 할 수 있는 추상화의 일종이다.

 

객체지향에서 객체 개개별로 구별하면 좋지만 그렇기에는 너무 이해하기 어려워지기 때문에 공통적인 특성을 뽑아서 하나로 묶는데 이를 묶기위한 공통적인 기반을 개념(concept)라고 한다. 이런 개념을 이용해서 객체를 여러 그룹으로 분류(classification) 할 수 있다. 이렇게 분류가 된 객체를 그룹의 일원이 되었다고 하여 인스턴스(instance)라고 한다.

 

객체 분류의 개념

그럼 객체에서 그룹으로 분류하기 위해 사용되는 개념은 symbol (이름이나 명칭), intension (개념의 정의), extension (개념에 속한 객체들의 집합) 3가지의 관점을 가지고 있다.

 

토끼라는 객체는 동물이라는 개념의 symbol을 사용하였고 4개의 다리와 척추동물이라는 intension을 사용하였고 같이 소속된 돼지나 강아지들을 보면서 extension을 확인하였다. 이로써 토끼는 동물이라는 그룹으로 분류될 수 있게 되었다.

 

객체 분류의 단점

잘못된 객체 분류를 통해 그룹에 이상한 객체가 소속되면 유지보수가 어렵고 변화에 대처하기가 어려워진다.

위의 내용을 종합해보면 객체를 분류하는 건 공통의 요소를 뽑아서 일반화하고 단순화하여 복잡성을 극복하는 작업이다.

 

 

타입

타입은 개념(concept)와 동일한 의미로써 공통점을 기반으로 객체를 묶기위한 틀이다. 객체에서 가장 중요한건 어떠한 행동을 하느냐가 가장 중요하고 그에 따라 타입이 결정된다. 내부에서 표현하는 방식이 서로 다르더라도 행동이 같다면 둘의 타입은 같을 수 있다.

Animal animal1 = new Dog(); 
Animal animal2 = new Cat(); 

animal1.eat(); 
animal2.eat();

위 두개의 객체의 내부 행동은 다르지만 먹는다는 행동이 같기에 같은 타입을 가질 수 있다. 이를 다형성이라고 한다. 이를 통해서 외부의 행동만 제공하고 내부적으로 상세 내용을 숨기는 캡슐화 원칙을 수행 가능하다.

 

이처럼 객체에 타입을 지정할 때는 데이터가 아니라 행동에 따라서 지정 해야 하는 책임 주도 설계를 해야 한다.

 

일반화/특수화 (supertype/subtype)

객체 타입에는 일반적으로 포함되는 타입과 특수한 타입 두 가지로 나뉜다. 강아지로 예를 들어보면 강아지가 짖는건 일반적인 강아지 타입의 특징이다. 하지만 훈련된 애완견의 경우 일반 강아지와 다른 행동이 가능하다. 여기서 강아지라는 특징은 일반적인 것이고 애완견은 특수화된 타입을 의미한다. 여기서 알 수 있듯이 특수화와 일반화의 차이는 행동을 통해서 기반 된다. 특수화된 타입은 일반화 타입의 특징을 포함하고 있으며 일반적인 특징보다 더 적은 모집군을 가지고 있다.

 

이를 슈퍼타입, 서브타입이라고도 하는데 서브타입은 슈퍼티입의 행위에 추가적으로 특수한 행위를 추가한 것이기 때문에 슈퍼타입의 행동은 서브 타입에게 자동으로 상속된다.

 

3장 결론

  • 타입을 통해서 객체를 분류하는데 이 타입은 객체의 행동을 통해서 정해진다. 이렇게 분류한 타입을 이용하여 클래스를 이용하여 프로그램화 한다.

  • 추상화는 객체의 특징을 보고 일반화/특수화하여 불필요한 부분을 제거하고 단순하게 만들어서 분류하는 것이다.

 

4. 역할, 책임, 협력

객체지향에서 협력은 가장 중요한 프레임이다. 협력에 초점을 맞춰서 설계를 하게 되면 저절로 객체들의 행동이 드러나고 그에따라 상태가 결정된다. 객체의 모양을 빚는 것은 객체가 참여하는 협력으로 어떤 협력에 참여하는지가 객체에 필요한 행동을 결정하고, 필요한 행동이 객체의 상태를 결정한다.

 

책임

객체들간의 협력에서 각 객체가 적절한 행동을 해줄 책임을 가지고 있다. 책임은 객체지향의 중요한 재료로써 눙숙한 프로그램 설계는 객체에게 적절하게 책임을 부여해주는 것을 의미한다.

 

이런 책임을 분류하는 기준은 외부에 제공해줄 수 있는 정보와 외부에 제공해 줄 수 있는 서비스에 대한 정의이다. 이런 책임을 바탕으로 객체지향에서 객체는 어떤 객체에 요청 메시지에 따라 어떤 책임 행동을 해줄 수 있는지 결정하는 것이 포인트이다.

 

역할

역할은 객체지향에서 재사용이 가능하고 유연한 설계를 가지는데 중요한 구성요소이다. 동일한 역할을 동일한 책임을 수행할 수 있다는 뜻이다. 또한 동일한 역할을 하는 객체를 추상화하여 유연성을 가지게 하고 재사용성과 단순하게 객체지향을 설계할 수 있다.

 

이 처럼 역할이 추상화되면 상황에 따라 여러 객체를 대체하면서 사용할 수 있어 유연성이 증가한다.

 

협력에 따라 흐르는 객체의 책임

- 설계 시 객체들 사이에 주고받을 요청과 응답의 흐름을 깔끔하게 만들고 (협력 설계) 그 객체들이 협력에 참여하여 자신의 역할을 책임있게 수행해야 한다.

- 즉 객체간의 관계를 먼저 만들고 그 다음 역할과 책임을 설계하라.

 

 

출처 : 객체지향의 사실과 오해 (조영호)

댓글()

JPA 다양한 Join 방법 정리 (N+1, queryDSL, fetch join)

web/Spring|2019. 11. 4. 20:31

JPA를 사용하다 보면 join을 할 때가 많아진다. join을 어떠한 방법으로 하느냐에 따라서 수행되는 쿼리가 달라지고 성능에 문제가 발생하는 경우도 종종있다.

 

그래서 다양한 방식의 join 방식을 알아보고 방식에 따라 작업을 진행해 보자.

우선 사용될 entity 두 개를 설명하면 다음과 같다.

@Getter
@Entity
@Table(name = "wedul_classes")
@AllArgsConstructor(access = AccessLevel.PROTECTED)
@NoArgsConstructor
@Builder
public class WedulClasses extends CommonEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long wedulClassesId;

    @OneToMany(mappedBy = "wedulClasses", fetch = FetchType.LAZY)
    private Set<WedulStudent> wedulStudentList = new LinkedHashSet<>();

    private String classesName;

    private String classesAddr;

}

@Getter
@Entity
@Table(name = "wedul_student")
@AllArgsConstructor(access = AccessLevel.PROTECTED)
@NoArgsConstructor
@Builder
public class WedulStudent extends CommonEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long wedulStudentId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "wedul_classes_id")
    @JsonBackReference
    private WedulClasses wedulClasses;

    private String studentName;

    private int studentAge;

    @Enumerated(value = EnumType.STRING)
    private StudentType studentType;

}

이 두 엔티티는 class와 student의 관계로 1대 N의 관계를 가지고 있다.

이 과정에서 사용될 데이터는 임의로 추가했고 다음과 같다.

 

wedul_classe 테이블의 데이터

wedul_student 테이블의 데이터

사용 쿼리 툴) tadpole docker version

 

 

그럼 이 entity를 이용해서 데이터를 조인하여 조회해보자.

 

1. 단순 조회

우선 첫 번째로 JpaRepository 인터페이스 사용 시 기본적으로 제공하는 findAll을 사용해보자.

@Repository
public interface WedulClassesRepository extends JpaRepository<WedulClasses, Long> {

    Optional<WedulClasses> findByClassesName(String classesName);

}

이를 사용하여 데이터를 조회해보면 사용 되는 쿼리는 다음과 같다.

-- classes 목록을 조회하는 쿼리
select
    wedulclass0_.wedul_classes_id as wedul_cl1_0_
    ,wedulclass0_.create_at as create_a2_0_
    ,wedulclass0_.update_at as update_a3_0_
    ,wedulclass0_.classes_addr as classes_4_0_
    ,wedulclass0_.classes_name as classes_5_0_
  from
    wedul_classes wedulclass0_
;


-- 아래 쿼리들은 wedul_classes_id 개수별로 조회되는 쿼리
select
    wedulstude0_.wedul_classes_id as wedul_cl7_1_0_
    ,wedulstude0_.wedul_student_id as wedul_st1_1_0_
    ,wedulstude0_.wedul_student_id as wedul_st1_1_1_
    ,wedulstude0_.create_at as create_a2_1_1_
    ,wedulstude0_.update_at as update_a3_1_1_
    ,wedulstude0_.student_age as student_4_1_1_
    ,wedulstude0_.student_name as student_5_1_1_
    ,wedulstude0_.student_type as student_6_1_1_
    ,wedulstude0_.wedul_classes_id as wedul_cl7_1_1_
  from
    wedul_student wedulstude0_
  where
    wedulstude0_.wedul_classes_id = ?
;
select
    wedulstude0_.wedul_classes_id as wedul_cl7_1_0_
    ,wedulstude0_.wedul_student_id as wedul_st1_1_0_
    ,wedulstude0_.wedul_student_id as wedul_st1_1_1_
    ,wedulstude0_.create_at as create_a2_1_1_
    ,wedulstude0_.update_at as update_a3_1_1_
    ,wedulstude0_.student_age as student_4_1_1_
    ,wedulstude0_.student_name as student_5_1_1_
    ,wedulstude0_.student_type as student_6_1_1_
    ,wedulstude0_.wedul_classes_id as wedul_cl7_1_1_
  from
    wedul_student wedulstude0_
  where
    wedulstude0_.wedul_classes_id = ?
;
select
    wedulstude0_.wedul_classes_id as wedul_cl7_1_0_
    ,wedulstude0_.wedul_student_id as wedul_st1_1_0_
    ,wedulstude0_.wedul_student_id as wedul_st1_1_1_
    ,wedulstude0_.create_at as create_a2_1_1_
    ,wedulstude0_.update_at as update_a3_1_1_
    ,wedulstude0_.student_age as student_4_1_1_
    ,wedulstude0_.student_name as student_5_1_1_
    ,wedulstude0_.student_type as student_6_1_1_
    ,wedulstude0_.wedul_classes_id as wedul_cl7_1_1_
  from
    wedul_student wedulstude0_
  where
    wedulstude0_.wedul_classes_id = ?
;

쿼리를 자세히 보면 알겠지만 wedul_classes를 조회하는 쿼리와 그 wedul_classes 개수만큼 쿼리가 실행되는것을 볼 수 있다.

많이 들어 봤을 법한 N+1 문제가 발생한 것이다.

이 방식으로 쿼리 수행 시 N번의 쿼리가 발생해야 하기에 데이터 수만큼 쿼리가 실행되는 안좋은 부담을 안고 가야해서 좋지 않다.

 

2. left fetch join

위의 1번의 N+1 문제 해결로 고안된 방법 중 하나가 fetch join이다. 나는 left join을 하고자 하기에 left fetch join을 시도해보자. 우선 사용된 코드는 다음과 같다.

@Repository
public interface WedulClassesRepository extends JpaRepository<WedulClasses, Long> {
    @Query(value = "select DISTINCT c from WedulClasses c left join fetch c.wedulStudentList")
    List<WedulClasses> findAllWithStudent();
}

distinct가 붙은 이유는 카티션곱에 의해서 여러개의 결과값이 발생해 버리기 때문에 추가하였다.

그럼 사용된 쿼리도 확인해보자.

select
    distinct wedulclass0_.wedul_classes_id as wedul_cl1_0_0_
    ,wedulstude1_.wedul_student_id as wedul_st1_1_1_
    ,wedulclass0_.create_at as create_a2_0_0_
    ,wedulclass0_.update_at as update_a3_0_0_
    ,wedulclass0_.classes_addr as classes_4_0_0_
    ,wedulclass0_.classes_name as classes_5_0_0_
    ,wedulstude1_.create_at as create_a2_1_1_
    ,wedulstude1_.update_at as update_a3_1_1_
    ,wedulstude1_.student_age as student_4_1_1_
    ,wedulstude1_.student_name as student_5_1_1_
    ,wedulstude1_.student_type as student_6_1_1_
    ,wedulstude1_.wedul_classes_id as wedul_cl7_1_1_
    ,wedulstude1_.wedul_classes_id as wedul_cl7_1_0__
    ,wedulstude1_.wedul_student_id as wedul_st1_1_0__
  from
    wedul_classes wedulclass0_
      left outer join wedul_student wedulstude1_
        on wedulclass0_.wedul_classes_id = wedulstude1_.wedul_classes_id

left join을 해서 한번에 데이터를 가져올 수 있는 걸 확인 할 수 있지만 아쉽게도 Lazy로 데이터를 가져오지 못하고 Eager로 가져와야 한다.

 

3. EntityGraph

이제 3번째 방식으로 entity graph를 사용하여 실행시켜보자. 코드는 아래와 같다.

@EntityGraph(attributePaths = "wedulStudentList")
@Query("select c from WedulClasses c")
Page<WedulClasses> findEntityGraph(Pageable pageable);

실행되는 쿼리는 다음과 같아서 2번과 동일하다. (page를 사용한 것만 차이)

select
    wedulclass0_.wedul_classes_id as wedul_cl1_0_0_
    ,wedulstude1_.wedul_student_id as wedul_st1_1_1_
    ,wedulclass0_.create_at as create_a2_0_0_
    ,wedulclass0_.update_at as update_a3_0_0_
    ,wedulclass0_.classes_addr as classes_4_0_0_
    ,wedulclass0_.classes_name as classes_5_0_0_
    ,wedulstude1_.create_at as create_a2_1_1_
    ,wedulstude1_.update_at as update_a3_1_1_
    ,wedulstude1_.student_age as student_4_1_1_
    ,wedulstude1_.student_name as student_5_1_1_
    ,wedulstude1_.student_type as student_6_1_1_
    ,wedulstude1_.wedul_classes_id as wedul_cl7_1_1_
    ,wedulstude1_.wedul_classes_id as wedul_cl7_1_0__
    ,wedulstude1_.wedul_student_id as wedul_st1_1_0__
  from
    wedul_classes wedulclass0_
      left outer join wedul_student wedulstude1_
        on wedulclass0_.wedul_classes_id = wedulstude1_.wedul_classes_id
  order by
    wedulclass0_.update_at desc;

 

4. QueryDSL

Querydsl은 정적 타입을 이용해서 SQL과 같은 쿼리를 사용할 수 있도록 해주는 프레임워크로 HQL쿼리를 실행하게 도와준다.

설정 방식은 gradle 5 기준으로 다음과 같다.

plugins {
    id 'org.springframework.boot' version '2.2.0.RELEASE'
    id 'io.spring.dependency-management' version '1.0.8.RELEASE'
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"
    id 'java'
}

group = 'com.wedul'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
    maven { url "https://plugins.gradle.org/m2/" }
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    compile group: "org.flywaydb", name: "flyway-core", version: '5.2.4'
    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'mysql:mysql-connector-java'
    compile group: 'org.apache.commons', name: 'commons-lang3', version: '3.9'
    compile group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.10.0'
    annotationProcessor 'org.projectlombok:lombok'
    testCompile group: 'org.mockito', name: 'mockito-all', version:'1.9.5'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

    // query dsl
    compile("com.querydsl:querydsl-apt")
    compile("com.querydsl:querydsl-jpa")
}

// querydsl 적용
def querydslSrcDir = 'src/main/generated'

querydsl {
    library = "com.querydsl:querydsl-apt"
    jpa = true
    querydslSourcesDir = querydslSrcDir
}

compileQuerydsl{
    options.annotationProcessorPath = configurations.querydsl
}

configurations {
    querydsl.extendsFrom compileClasspath
}

sourceSets {
    main {
        java {
            srcDirs = ['src/main/java', querydslSrcDir]
        }
    }
}

그리고 QueryDsl 사용을 위해 QueryDslRepositorySupport를 상속받아서 사용할 수 있는데 마지막에 distinct를 사용한 것은 2번 fetch 조인의 이유와 동일하다.

@Repository
public class WedulClassesQueryDsl extends QuerydslRepositorySupport {

    public WedulClassesQueryDsl() {
        super(WedulClasses.class);
    }

    public List<WedulClasses> findAllWithStudent() {
        QWedulClasses wedulClasses = QWedulClasses.wedulClasses;
        QWedulStudent wedulStudent = QWedulStudent.wedulStudent;

        return from(wedulClasses)
            .leftJoin(wedulClasses.wedulStudentList, wedulStudent)
            .fetchJoin()
            .distinct()
            .fetch();
    }

}

그럼 마찬가지로 실행되는 쿼리를 확인해보자.

select
    distinct wedulclass0_.wedul_classes_id as wedul_cl1_0_0_
    ,wedulstude1_.wedul_student_id as wedul_st1_1_1_
    ,wedulclass0_.create_at as create_a2_0_0_
    ,wedulclass0_.update_at as update_a3_0_0_
    ,wedulclass0_.classes_addr as classes_4_0_0_
    ,wedulclass0_.classes_name as classes_5_0_0_
    ,wedulstude1_.create_at as create_a2_1_1_
    ,wedulstude1_.update_at as update_a3_1_1_
    ,wedulstude1_.student_age as student_4_1_1_
    ,wedulstude1_.student_name as student_5_1_1_
    ,wedulstude1_.student_type as student_6_1_1_
    ,wedulstude1_.wedul_classes_id as wedul_cl7_1_1_
    ,wedulstude1_.wedul_classes_id as wedul_cl7_1_0__
    ,wedulstude1_.wedul_student_id as wedul_st1_1_0__
  from
    wedul_classes wedulclass0_
      left outer join wedul_student wedulstude1_
        on wedulclass0_.wedul_classes_id = wedulstude1_.wedul_classes_id

애도 2번, 3번과 동일한 쿼리가 작성되는 걸 확인할 수 있다.

기본적으로 단순하게 다대일 데이터를 가져오려고 하면 N+1 문제가 발생할 수 있기 때문에 조심해야하고 이를 해결하기 위해서는 다양한 방식의 문제 해결 방식이 있는걸 확인할 수 있었다.

무엇이 가장 좋은지는 본인이 판단하거나 상황에 맞게 사용하면 좋을 거 같다.

댓글()