0523 ~ 0605

0525 - 단위 테스트, 통합 테스트, 인수 테스트

단위 테스트 (Unit Test)

단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트

단위 테스트에서 테스트 대상 단위의 크기는 엄격하게 정해져 있지 않다. 하지만, 일반적으로 클래스 또는 메소드 수준으로 정해진다. 단위의 크기가 작을수록 단위의 복잡성이 낮아진다. 따라서, 단위 테스트를 활용하여 동작을 표현하기 더 쉬워진다. 즉, 테스트 대상 단위의 크기를 작게 설정해서 단위 테스트를 최대한 간단하고 디버깅하게 쉽게 작성해야 한다.

소프트웨어를 개발할 때, 소프트웨어 내부 구조나 구현 방법을 고려하여 개발자관점에서 테스트한다. 그러므로 단위 테스트는 소프트웨어 내부 코드에 관련한 지식을 반드시 알고 있어야 하는 화이트박스 테스트이다. 단위 테스트는 TDD와 함께 할 때 특히 더 강력해진다.

@DisplayName("자동차가 전진한다")
@Test
public void moveCar() {
    // given
    Car car = new Car("dani");

    // when
    car.move(4);

    // then
    assertThat(car.getPosition()).isEqualTo(1);
}

@DisplayName("자동차가 멈춘다")
@Test
public void stopCar() {
    // given
    Car car = new Car("dani");

    // when
    car.move(3);

    // then
    assertThat(car.getPosition()).isEqualTo(0);
}

통합 테스트 (Integration Test)

통합 테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈들을 모아 이들이 의도대로 협력하는지 확인하는 테스트이다.

통합 테스트는 단위 테스트와 달리 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어 검증할 때 사용한다. 이는 DB에 접근하거나 전체 코드와 다양한 환경이 제대로 작동하는지 확인하는데 필요한 모든 작업을 수행할 수 있다. 그러나, 통합 테스트가 응용 프로그램이 완전하게 작동하는걸 무조건 증명하지는 않는다.

통합 테스트의 장점은 단위 테스트에서 발견하기 어려운 버그를 찾을 수 있다는 점이다. 예를 들어, 통합 테스트에서는 환경 버그(ex. 싱글 코어 CPU에서는 잘 실행되거나 쿼드 코어 CPU에서는 잘 실행되지 않음)이 발생할 수 있다.

한편, 통합 테스트의 단점은 단위 테스트보다 더 많은 코드를 테스트하기 때문에 신회성이 떨어질 수 있다는 점이다. 또, 어디서 에러가 발생했는지 확인하기 쉽지 않아 유지보수하기 힘들다는 점도 있다.

스프링부트에서는 클래스 상단에 @SpringBootTest 어노테이션을 붙여 통합 테스트를 수행할 수 있다.

@SpringBootTest
class SubwayApplicationTests {
    @Test
    void contextLoads() {
    }
}

인수 테스트 (Acceptance Test)

인수테스트는 사용자 스토리(시나리오)에 맞춰 수행하는 테스트이다.

앞선 두 테스트들과 달리 비즈니스 쪽에 초점을 둔다. 프로젝트에 참여하는 사람들이 토의해서 시나리오를 만들고, 개발자는 이에 의거해서 코드를 작성한다. 개발자가 직접 시나리오를 제작할 수도 있지만, 다른 의사소통집단으로부터 시나리오를 받아 개발한다는 의미를 가지고 있다.

인수 테스트는 애자일 개발론에서 파생했다. 특히, 익스트림 프로그래밍(XP)에서 사용하는 용어이다. 이는 시나리오가 정상적으로 동작하는지를 테스트하기 때문에 통합 테스트와는 분류가 다르다. 시나리오에서 요구하는 것은 누가, 어떤 목적으로, 무엇을 하는가이다. 개발을 하다 보면 이런 기능은 API를 통해 드러난다. 인수 테스트는 주로 이 API를 확인인하는 방식으로 이뤄진다.

결국, 인수 테스트는 소프트웨어 인수를 목적으로 하는 테스트이다. 소프트웨어를 인수하기 전에 명세한 요구사항(인수 조건)대로 잘 작동하는지 검증이 필요하다.

소프트웨어를 인수할 때, 소프트웨어 내부 구조나 구현 방법을 고려하기보다는 실제 사용자 관점에서 테스트하는 경우가 많다. 따라서, 인수 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 블랙박스 테스트이다. 실제 사용자 관점에서 테스트 할 때 E2E(End-to-End) 형식을 이용해서 확인한다.

Java에서는 RestAssured, MockMvc 같은 도구를 활용하여 인수 테스트를 작성 할 수 있다.

public static ExtractableResponse<Response> 회원_생성_요청(MemberRequest memberRequest) {
    return RestAssured
            .given()
            .contentType(MediaType.APPLICATION_JSON_VALUE)
            .body(memberRequest)
            .when().post("/api/members")
            .then()
            .extract();
}

0526 - Single branch로 Clone 후, 새로운 브랜치 추가

git에서 브랜치가 많을경우 특정 브랜치만 추적하도록 clone할 수 있다.

git clone -b <branch name> --single-branch <github url> <target directory>
git clone -b jaesungahn91 --single-branch https://github.com/jaesungahn91/jwp_qna

위와 같이 clone한 후 새로운 브랜치를 추가하고 싶은 경우가 있으면 다음과 같이 새로운 브랜치를 추가할 수 있다.

git remote set-branches --add origin [remote-branch]
git fetch origin [remote-branch]:[local-branch]

0529 - ATDD, 인수 테스트

인수 테스트(Acceptance Test)란?

명세 등 요구 사항이 충족되는지 확인하기 위해 비즈니스 측면에 초점을 맞춘 테스트라고 생각할 수 있다. 보통 마지막 단계에서 작업(기능)이 완전히 완료되었는지 검사하는데 수행된다.
요구사항(인수 조건)이 만족하는지 확인하는 과정에서, 시나리오에 맞춰 테스트가 수행된다. 이때, 인수 조건(Aceeptance Criteria)이 사용자 스토리를 시나리오 형식으로 표현되며 시나리오는 프로젝트에 참여하는 사람들(개발자, 기획자 등)의 토의를 통해 나온다.
시나리오의 중점은 누가, 어떤 목적으로, 무엇을 하는가 이다.

ATDD, 인수 테스트 주도 개발

인수 테스트를 먼저 작성한 다음 기능 개발을 하는 방법
사용자(고객)-개발자-테스터간의 커뮤니케이션을 기반한 개발 방법
애자일의 프로그래밍 방법론 중 하나로 사용자 스토리를 기반으로 인수 조건을 도출하여 기능 개발을 진행하는 방법론이다.

ATDD를 통해 요구사항과, 작업의 순서와 범위를 명확하게 파악할 수 있다.

0531 - String.format

public static String format(String format, Object... args);
public static String format(Locale l, String format, Object... args);

String의 static 메서드인 format 메서드는 문자열의 형식을 설정하는 메서드이다.

1. %d (= Integer Formatting)

• 10진수 integer의 형식을 설정할 때 이용한다.

int i = 23;

System.out.println(String.format("%d_", i));
System.out.println(String.format("%5d_", i));
System.out.println(String.format("%-5d_", i));
System.out.println(String.format("%05d_", i));

// 출력
23_
   23_
23   _
00023_

int i = 123456789;

System.out.println(String.format("%,d_", i));
System.out.println(String.format("%,15d_", i));
System.out.println(String.format("%,-15d_", i));
System.out.println(String.format("%,015d_", i));

// 출력
123,456,789_
    123,456,789_
123,456,789    _
0000123,456,789_

2. %s (s= String Formatting)

• 문자열의 형식을 설정할 대 이용한다.

String str = "tete";

System.out.println(String.format("%s_", str));
System.out.println(String.format("%12s_", str));
System.out.println(String.format("%-12s_", str));
System.out.println(String.format("%.2s_", str));
System.out.println(String.format("%-12.2s_", str));
System.out.println(String.format("%12.2s_", str));

// 출력
tete_
        tete_
tete        _
te_
te          _
          te_

3. %f (= Floating point Formatting)

• 실수형 숫자 형식을 설정할 때 이용한다.

double n = 123.45678;

System.out.println(3.4);
System.out.println(n);
System.out.println();

System.out.println(String.format("%f_", 3.4));
System.out.println(String.format("%f_", n));
System.out.println(String.format("%.6f_", n));
System.out.println(String.format("%15f_", n));
System.out.println(String.format("%-15f_", n));
System.out.println(String.format("%.3f_", n));
System.out.println(String.format("%.2f_", n));
System.out.println(String.format("%15.2f_", n));
System.out.println(String.format("%-15.2f_", n));
System.out.println(String.format("%015f_", n));
System.out.println(String.format("%015.2f_", n));

// 출력
3.4
123.45678

3.400000_
123.456780_
123.456780_
     123.456780_
123.456780     _
123.457_
123.46_
         123.46_
123.46         _
00000123.456780_
000000000123.46_

4. Locale 설정

• 오버로딩된 String.format(Locale, 포맷, 값); 메서드를 이용하여 국가별 포맷 설정이 가능.

int money = 35000;
Date today = new Date();

System.out.println(String.format("￦ %,d", money));
System.out.println(String.format(Locale.GERMANY, "%,d €", money));
System.out.println(String.format("%tp", today));
System.out.println(String.format(Locale.ENGLISH, "%tp", today));

// 출력
￦ 35,000
35.000 €
오후
pm

0602 - JPA 연관관계 편의 메서드

연관관계 편의 메서드

양방향 연관관계를 맺을 때에는, 양쪽 모두 관계를 맺어주어야한다. 사실 JPA의 입장에서 보았을 때에는 외래키 관리자(연관관계의 주인)쪽에만 관계를 맺어준다면 정상적으로 양쪽 모두에서 조회가 가능하다.

Team team1 = new Team("Team1");
em.persist(team1);

Member member1 = new Member("Member1");
member1.setTeam(team1); // 연관관계 설정 member1 -> team1

하지만 객체까지 고려한다면, 양쪽 다 관계를 맺어야한다.

Team team1 = new Team("Team1");
em.persist(team1);

Member member1 = new Member("Member1");
member1.setTeam(team1); // 연관관계 설정 member1 -> team1
team1.getMembers().add(member1) // 연관관계 설정 tema1 -> member1

즉, 객체의 양방향 연관관계는 양쪽 모두 관계를 맺어주어야 순수한 객체 상태에서도 정상적으로 동작한다.

이렇듯 양방향 연관관계는 결국 양쪽 모두를 신경써야한다. 만약, setTeam과 getMembers().add를 각각 호출하면 실수가 발생할 수 있다. 따라서 양쪽 모두의 관계를 맺어주는 것을 하나의 코드처럼 사용하는 것이 안전하다.

public void setTeam(Team team) {
    this.team = team;
    team.getMembers().add(this);
}

위와 같이 한번에 양방향 관계를 설정하는 메서드를 연관관계 편의 메서드라고 한다.

하지만 위와같이 setTeam 메서드를 작성하는 경우 버그가 발생할 수 있다. 예로

member1.setTeam(team1);
member1.setTeam(team2);

위와 같이 연속적으로 setTeam을 호출한 이후 team1에서 멤버를 조회하면 member1가 여전히 조회된다. team2로 변경할 때 team1과의 관계를 제거하지 않았기 때문이다.

--> 수정

public void setTeam(Team team) {
    if (this.team != null) { // 기존에 이미 팀이 존재한다면
        this.team.getMembers().remove(this); // 관계를 끊는다.
    }
    this.team = team;
    team.getMembers().add(this);
}

taem1.addMember(member1);

// Team
public void addMember(Member member) {
    this.members.add(member);
    member.setTeam(this);
}

0603 - @DirtiesContext

스프링 단위 테스트 진행시 하나의 Spring Context를 재사용함에 따라 발생하는 문제를 해결하기 위해 사용한다.

@DirtiesContext 어노테이션은 테스트를 수행 전, 수행 후, 각 테스트 케이스마다 수행하기 전 수행한 이후에 Context를 재생성하는 역할을 한다.

@DirtiesContext indicates that the underlying Spring ApplicationContext has been dirtied during the execution of a test (that is, the test modified or corrupted it in some manner — for example, by changing the state of a singleton bean) and should be closed. When an application context is marked as dirty, it is removed from the testing framework’s cache and closed. As a consequence, the underlying Spring container is rebuilt for any subsequent test that requires a context with the same configuration metadata.
You can use @DirtiesContext as both a class-level and a method-level annotation within the same class or class hierarchy. In such scenarios, the ApplicationContext is marked as dirty before or after any such annotated method as well as before or after the current test class, depending on the configured methodMode and classMode.

doc.spring.io에 따르면 @DiritiesContext ApplicationContext 테스트를 실행하는동안 테스트프레임워크의 캐시를 제거하고 닫게한다. 결과적으로 기본 Spring Container에 동일한 구성 멧타 데이터가 있는 컨텍스트를 필요로하는 후속 테스트를 위해 재 빌드된다고 나와있다.

메소드나 클래스레벨에 어노테이션을 붙이는 것으로 동작하며, methodMode, classMode에 따라 각각 다르게 동작하게 설정할 수 있다.

1. 클래스의 테스트가 시작하기 전에 context 재생성

@DirtiesContext(classMode = BEFORE_CLASS)
public class FreshContextTests {
 // 테스트 케이스들이 새로운 context에서 실행됨
}

2. 클래스의 테스트가 모두 끝난 다음 context 재생성 (기본값)

@DirtiesContext
public class ContextDirtyingTests {
 // 테스트 케이스가 context의 @Bean의 상태에 영향을 끼침
}

3. 클래스의 모든 테스트 케이스마다 시작하기 이전에 context 재생성

@DirtiesContex(classMode = BEFORE_EACH_TEST_METHOD)
public class FreshContextTests {
 // 모든 케이스에서 새로운 context가 필요함
}

4. 클래스의 모든 테스트 케이스가 끝날 때 마다 context 재생성

@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD)
public class ContextDirtyingTests {
 // 모든 케이스가 context의 상태에 영향을 끼침
}

5. 특정 케이스를 시작하기 전에 context 재생성

@DirtiesContext(methodMode = BEFORE_METHOD)
@Test
public void testProcessWhichRequiresFreshAppCtx() {
 // 새로운 context가 필요한 어떤 로직
}

6. 특정 케이스를 시작한 이후 context 재생성

@DirtiesContext
@Test
public void testProcessWhichDirtiesAppCtx() {
 // context의 상태를 변경하는 어떤 로직
}

0605 - requireNonNull

자바 7에 추가된 Objects 클레스에서 제공하는 Null 체크를 위한 메소드 이다. 파라미터로 입력된 값이 null 이라면 NPE(NullPointerException)가 발생하고, 그렇지 않다면 입력값을 그대로 반환하는 간단한 메소이이다. requireNonNull은 아래와 같이 세가지로 오버로딩 되어있다.

리턴타입	메소드
T	requireNonNull(T obj)
T	requireNonNull(T obj, String message)
T	requireNonNull(T obj, Supplier msgSupplier)

첫번째 메소드는 null을 전달하면 메세지가 비어있는 NPE 예외를 던진다,

Objects.requireNonNull(null);
// java.lang.NullPointerException

두번쨰 메소드는 null을 전달하면, 두번째 파라미터로 전달한 문자열을 메세지로 갖는 NPE 예외를 던진다.

Objects.requireNonNull(null, "null은 전달될 수 없습니다!");
// java.lang.NullPointerException: null은 전달될 수 없습니다!

세번째 메소드는 null을 전달하면, 두번째 파라미터로 전달한 Supplier를 구현한 익명 함수의 반환값을 메세지로 갖는 NPE 예외를 던진다.

Objects.requireNonNull(null, () -> "null은 전달될 수 없습니다!");
// java.lang.NullPointerException: null은 전달될 수 없습니다!

requireNonNull을 사용하는 이유

• 빠른 실패 (Fail-Fast)
  디버깅을 쉽게하기 위해서는 문제가 발생한 경우 즉각적으로 감지할 필요가 있다. 문제의 원인과 문제의 발생 지점이 물리적으로 떨어져 있다면 디버깅하기 어렵다.
• 명시성과 가독성