본문 바로가기
스터디/Test

[스터디] Test Code1

RyuDung 2019. 4. 6. 07:11

테알못(테스트 잘 모르는 내가)이 테알못(테스트 처음 접한 개발자)에게

 
 

'Test'를 발표 주제로 선정한 이유

현재 스터디는 개인 발표로 스터디를 진행하고 있다. 스터디에 참여하시는 개발자 4분이 테스트코드를 작성하는 것에 대한 중요성을 별로 느끼지못하고 테스트를 작성하지 않고 있었다.
발표준비를 하면서 나 또한 테스트에 대한 정리와 공부를 할 수 있고, 스터디원 분들에게도 도움이 될거 같아 'Test'로 발표주제를 정하였다. 발표 내용은 1년전에 수강했던 박재성 강사님의 TDD수업에서 배웠던 내용, Spring boot Test 내용으로 정했다.
테스트는 본인이 코드를 만들어 내야하기 때문에 내용이 많은 것보다 실습위주로 진행하는 것이, 발표 이후 더 많은 도움이 될거라고 생각했고 실습하는 시간을 더 많이 가질 예정이다.

 
 
 

목차

  • 개발자의 하루
  • 테스트 코드를 작성하는 이유
  • 테스트를 위한 프레임워크
    • junit5
    • assertJ
      • 워밍업(실습)
  • 테스트 작성 원칙
  • 테스트 예제연습
    • 계산기(실습)

 
 
 

흔하디 흔한 개발자의 하루

1. 기획자에게서 새로운 요구사항이 들어왔다.
2. 새로운 기능에 대한 기획 내용을 가지고 열심히 개발했다.
3. QA팀에 넘겼다.
4. 기도를 열심히 했다.
5. 다음날, 무사히 배포를 완료했다.
6. 다음 날, 다른 기능에서 버그가 생겼다고 연락이 왔다.
7. 기능을 롤백 했다..
8. 버그가 왜 생겼는지 열심히 분석했다.
9. 2틀 동안, 디버깅을 찍어보면서 분석을 해보니 새로운 기능을 추가하면서 발생한 문제였다.
10. 의존성을 분리하고 다시 새로운 기능에 대한 개발을 수정했다
11. …

 
 
 

(개발자가 새로운 기능을 추가했을때)

 
 
 

테스트 코드를 작성하는 개발자의 하루

1. 기획자에게서 새로운 요구사항이 들어왔다.
2. 새로운 기능에 대한 기획 내용을 가지고 테스트 코드를 작성했다.
3. 테스트 코드를 작성하 내용을 가지고 기능 개발을 진행했다.
4. QA에 넘기기전에 전체 테스트 코드를 실행보았다.
5. oops! 다른 기능에서 테스트코드가 실패하였다.
6. 새로운 기능과 테스트코드가 실패한 코드를 수정하였다.
7. 전체 테스트 코드가 성공했다.
8. QA에 팀에 넘겼다.
9. 다음날, 시원하게 배포하였다.
10. 배포 다음날 팀장님이 고생했다며, 오늘은 쉬엄 쉬엄하라고 하셨다!
오전에 동기들과 커피를 마시며 놀다가 오후에는 spring boot 2.x 릴리스 문서를 읽다가 퇴근하고 집에가는 길에
영화를 한편 보고 집에서 youtube를 보다가 잠들었다.
11.  …

 
 
 

(개발자 배포 잘 됬을 때)

   

테스트 작성의 이유

  • 개발자의 이해를 테스트한다: 개발자가 모든 치명적인 구성요소의 요구사항들을 코드로 명확히 작성하기에 충분히 문제를 이해하고 있는가?
  • 품질을 보증(QA)한다: 수동적인 QA는 오류를 범할 수 있다. 경험에 비춰보면 리팩토링을 하거나 새 기능 추가 혹은 제거할 때 여파가 있을 - 수 있는 모든 기능들을 기억해내서 테스트하는 것은 불가능하다.
  • 지속적인 배포가 된다: 자동화된 QA는 프로덕션으로 배포되기 전에 잘못된 빌드가 배포 되는 것을 막아준다.
  • 테스트코드 작성은 버그의 발생 횟수를 줄여준다.
  • 테스트코드 작성은 더욱 모듈화된 디자인이 되도록 도와준다.
  • 테스트코드 작성은 코드의 복잡도를 감소시켜 준다.

   

테스트 코드 작성 어떻게 하지??

테스트 프레임워크를 사용하면 된다.

   

JUnit5

  • JUnit이란?
JUnit은 대표적인 Java 프로그래밍 언어의 단위 테스트 프레임 워크 입니다. JUnit은 테스트 중심 개발의 개발에서 중요했으며,
SUnit에서 시작된 xUnit으로 통칭되는 단위 테스트프레임 워크 중 하나입니다.

  • JUnit5 특징

    • 테스트에 대한 정보를 남기기 쉽다.

      @Test
@DisplayName("assertEquals(예상값, 실제값, '비교에 대한 설명')")
void test1() {
  assertEquals(2, 2, "2는 2의 비교는 같다.");
}

    • 반복적인 테스트 기능

      @RepeatedTest(5)
void repeatedTestWithRepetitionInfo(RepetitionInfo repetitionInfo) {
  assertEquals(5, repetitionInfo.getTotalRepetitions());
}

    • 파라미터에 대한 테스트 기능

      @ParameterizedTest
@ValueSource(ints = {1, 2, 3, 4})
void palindromesInt(int candidate) {

  List<Integer> ints = Arrays.asList(1, 2, 3, 4);

  assertTrue(ints.contains(candidate));
}

    • 테스트 순서 보장 기능

      @DisplayName("테스트 순서를 정하는 샘플")
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
public class OrderTest {

  @DisplayName("세번째")
  @Test
  @Order(3)
  void nullValues() {

  }

  @DisplayName("두번째")
  @Test
  @Order(2)
  void emptyValues() {

  }

  @DisplayName("첫번째")
  @Test
  @Order(1)
  void validValues() {

  }
}

    • @Tag, Flitering 등.. junit4 보다 다양한 기능을 지원

  • JUnit5 예제코드

    • JUnit5에 익숙하지 않다면 예제코드를 돌려보며, 테스트 프레임워크에 대한 동작을 익히자.

   

assertj

  • assertJ란?
AssertJ는 풍부한 assertion 세트를 제공하는 Java 라이브러리로서, 유용한 오류 메시지를 제공하고 테스트 코드 가독성을
향상 시키며 자주 사용하는 IDE 내에서 사용하기 쉽도록 설계되었습니다.

  • assertJ 특징

    • 코드 가독성이 높다
    • 사용하기 편리하다
    • 메서드 체이닝이 가능하다(BDD 스타일로 작성 가능하다) 
        assertThat("Frodo")
          .startsWith("Fro")
          .endsWith("do")
          .isEqualToIgnoringCase("frodo");

  • assertJ 예제코드(실습)(30분)

    • 예제를 받아보면 컴파일 에러가 나고 있을 것이다.
    • README.md에 작성된 assertj Doc을 찾아보며, 컴파일에러를 잡고 프레임워크를 익히자.

   

테스트 작성 원칙 요약

  1. 테스트는 단위 테스트를 기본 단위로 한다.

    • 되도록 하나의 메서드에서 하나의 기능을 처리하도록 한다
    • 메서드 단위의 테스트

  2. 테스트를 작성할 때 기본 플로우

    • given(주어진 상황)

    • when(행위)

    • then(결과)

    • 예

        @Test
  public void operate_plus() {
      //given
      String operator = "+";

      //when
      int result = Operator.operate(operator, 1, 2);

      //then
      assertEquals(3, result);
  }

  3. 테스트 코드에도 필요한 주석을 남긴다.

  4. 가능한 TODO를 먼저 작성한다.

  5. 가장 쉬운것 부터 만든다.

  6. 입력부터 출력순으로 만든다.

   

실습) 간단한 계산기를 만들어 보자.(3시간)

연산자(+, -, *, %)와 두 개의 숫자를 입력받아 결과를 print 해주는 계산기를 만들어 보자.

  • 위에서 연습한 테스트 프레임워크(Junit5, assertJ)를 자유롭게 사용한다.
  • 위의 테스트 원칙을 지키며 만든다.
  • 계산기 만들기 예제(실습)

   

TDD는 바로 쉽게 적용 가능할까?

  • 처음부터 쉽게 적용하기는 어렵다. 조금씩 천천히
    • 테스트를 먼저 작성하기 힘들다면 개발 후 테스트코드를 작성하며 프레임워크를 익히자.
    • 가장 간단한 테스트코드를 작성하면서 테스트 프레임 워크를 익히자.
    • 레거시 프로젝트에 있다면, 내가 작성하는 코드만이라도 테스트를 작성해보자.
  • 익숙하지 않기 때문에 개발 기간이 초기에 더 오래 걸린다.
  • (소속 회사, 팀) 환경에 따라서 테스트 코드 작성이 어려울 수 있다.
    • 설득을 하자.
    • 개인프로젝트를 하자.
    • 이직을 하자.
  • 조급해하지 말고 천천히 익혀 실무에서 더 많이 배워가자.

   

다음편은 [스터디] Test Code2 스프링부트 테스트

(마땅한 짤이 없어서.. 죄송합니다.)
참고자료
저작자표시 비영리 변경금지

티스토리툴바