[우테코 - 1주차] 10.17(목) TDD 코드 작성

1. 준비

• 오늘은 학교를 다녀오느라 코드를 짤 시간이 부족했다.
  • 노트북으로 코드를 짜면 좋겠지만 인터넷이랑 앉아서 갈 수 없어서….
• 때문에 이미 어제 작성한 원시 코드가 잘 돌아가는지 Test 코드를 작성하기로 했다.

2. 몰입

1) 테스트 코드 구상

• 메소드별로 테스트하는 코드를 만들어야 겠다고 계획했다.
  • 커스텀 구분자가 유효한 경우
  • 커스텀 구분자가 //s\\n 순서가 아닌 경우
  • 구분자 추출이 유효한 경우
  • 구분자 추출이 잘못된 경우
  • 커스텀 구분자로 기본 구분자를 입력하거나, 숫자를 입력하는 경우
  • 입력이 배열로 정상 변환되는지
  • 구분자를 포함한 입력이 배열로 정상 변환되는지
  • 빈칸이 포함되는 예외
  • 0이 포함되는 예외
  • 0이 여러개인 예외
  • 숫자, 구분자가 아닌 문자가 입력되는 경우
  • int보다 큰 숫자가 입력되는 경우
  • String → int로 배열 형변환 체크
  • 합 연산이 제대로 되는지

2) 테스트 과정 오류 발생

• gradlew.bat clean test를 입력해서 실행하면 한글이 깨져서 BUILD FAIL이 떴다.
  • 윈도우 사용자들에게서 종종 나타난다고 한다.
  • 해결 방법은 아래와 같다.
    1. 해결 방법
       1. 윈도우 검색창에 "시스템 환경 변수 편집"을 입력하고 들어간다.
       2. 환경 변수에 들어간다.
       3. 사용자 변수에서 새로 만들기를 누른다.
       4. 변수 이름은 JAVA_OPTS로 하고, 변수 값은 -Dfile.encoding=UTF-8로 설정한다.

참고한 블로그

powershell, bash gradlew 한글 깨짐 현상 수정

powershell, bash gradlew 한글 깨짐 현상 수정

 

• 메소드를 처음에는 전체 기능으로 검사했는데 메소드별로 하는게 좋다고 해서 다시 작성했다 ㅎㅎ...
• 테스트 코드를 평소에 작성하지 않아 메소드별로 최초로 작성하는데 어려움을 겪었다.
  • 기존 인프런 강의에서 했던 기억이 나서 블로그에서 테스트 코드를 뒤적였다…
  • 테스트 코드와 관련된 정보를 찾아서 메소드 1개를 테스트에 성공하니 나머지는 유사하게 만들면 되기 때문에 금방 한 것 같다.
• 메소드별 테스트로 만들면 아래와 같은 이점이 있다고 한다.
  • 모듈화된 테스트이기 때문에 메소드에서 어느 오류가 있는지 정확하게 파악 가능
  • 각 메소드에 대응하는 테스트 코드가 있기 때문에 기능 추가 및 삭제시 테스트 코드를 수정하는데 용이
  • 테스트는 하나의 메소드를 검증하는 역할만을 하므로 테스트 코드도 단일 책임 원칙(SRP)을 따르게된다.
  • 각 메소드의 테스트가 분리되어 있으면 어떤 기능을 테스트하는지 명확하게 이해가능
  • 특정 메소드에 문제가 있는 경우 전체 코드가 아니라 그 메소드와 관련된 테스트만 실행 가능
  • 메소드별로 테스트가 잘 구성되어 있으면, 리팩토링이나 내부 로직을 변경할 때 해당 메소드가 의도한 대로 작동하는지 신속하게 확인 가능

3. 느낀 점

1) TDD 중심 코드의 필요성

• TDD 중심 코드가 아니기 때문에 테스트를 먼저 구상하고 통과하기 위한 코드를 작성하는 순서를 지키지 않았다.
  • 때문에 테스트 코드가 문제가 발생하지 않더라도 정확하게 신뢰하기가 어렵다.
• 기능 구현 전 테스트를 작성하면 버그나 예외를 발견할 수 있다.
  • 실제로 테스트 코드를 통해 오탈자와 처리하지 못한 예외처리를 발견했다.
  • 이처럼 테스트를 미리 생각하고 이에 맞춰 코드를 짜면 2차 수정 작업을 하지 않을 수 있을 것 같다.
• 테스트를 위한 코드를 짜기 위해 자연스럽게 모듈화된 설계를 하게 된다.
  • 각 메소드 별로 테스트를 진행하기 때문에 모듈화를 기반으로 코드를 짜게 된다.

TDD 중심 코드를 한번도 짜보지 않았고, 테스트를 이처럼 메소드별로 진행한것도 처음이다.

덕분에, 이번 기회에 TDD 중심 코드를 짜면 좋은 이점과 테스트를 어떤 방식으로 진행해야 할지 알게 된 것 같다.