단위테스트를 해야하는 영역은 어디까지일까?

[minaver]

이슈

단위테스트를 진행하면서 단위테스트를 어디까지 진행해야하는지에 대한 의문이 생겼다.

Service단의 단위테스트를 진행할 때 예외 처리 단위 테스트 또한 진행하는데 만약 다음과 같은 코드가 있다면 해당 코드를 단위 테스트를 해주는 것이 과연 효과적인 걸까?

다음은 Service 단의 코드이고

public List<...> getSth(String userId) throws BaseException {
        Users user = usersRepository.findById(userId)
                .orElseThrow(() -> new BaseException(BaseResponseStatus.EMPTY_BY_USER_ID));
...

아래는 해당 메서드의 예외 테스트 코드이다.

    @Test
    @DisplayName("Invalid User Id 테스트")
    void invalid_userId_test() {
        // given
        given(fakeUsersRepository.findById(any())).willReturn(Optional.empty());

        // when
        String userId = "admin";

        // then
        assertThatThrownBy(() -> smtService.getSth(userId))
                .isInstanceOf(BaseException.class);
    }

여기서의 테스트는 UsersRepository에서 Optional.empty()가 나왔을 때 getSth() 메서드 안에 있는 orElseThrow()가 정상작동 하는지를 보는 테스트라고 생각한다.
그렇다면 해당 테스트는 개발자의 손을 벗어난 라이브러리 단의 기능이 정상 작동하는지 테스트하고 있는게 아닐까? 즉 테스트 할 필요가 없는 부분 아닐까?

문제는 일단 개발자가 어디까지 테스트를 해야하는지에 대한 개념이 잡혀있지 않다.
이 개념이 테스트 코드를 작성하는데 가장 중요한데 방법적인 부분만 알고 핵심을 모르고 있다는 생각이 든다.
테스트 코드의 '목적'에 대한 공부가 필요하다.

공부해볼 내용

1. 테스트 코드를 실행해야 하는 범위

• 자바지기님 TDD 리팩토링
• 자바지기님 숫자야구 TDD 1
• 자바지기님 숫자야구 TDD 2
• 구글링을 해보자

2. 좋은 테스트 코드란 무엇인가?

• Clean Code 책을 봐보자

[minaver]

[우아한테크세미나] 190425 TDD 리팩토링 by 자바지기 박재성님

강의 목적

어떻게 연습하면 좀더 효과적으로 TDD와 리팩토링을 진행할 수 있을지에 대한 설명

1. 의식적인 연습이란?

TDD, 리팩토링.. 과연 무조건 연습한다고 잘할 수 있을까?
무엇인가 연습할때 무조건 많은 시간을 쏟는다고 잘해지지 않는다.

TDD를 연습하기 위한 목적은..

테스트하기 쉬운 코드와 테스트하기 어려운 코드를 구분하는 눈
테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 감(sense)

그렇다면 이를 위해 좀 더 효과적으로 연습할 수 있는 방법은 없을까?

1. 평생동안 연습하겠다는 마음가짐으로 시작해야 한다!
2. 일정 수준에 영향을 받지 않고 꾸준히 연습하기 위해서 초기에는 장난감 프로젝트로 연습한다.

2. TDD, 리팩토링 적용 - 개인

1단계 단위 테스트 연습

TDD는 테스트 코드를 먼저 만든다는 개념이기에 처음 시작으로 접하기 어렵다. 그러므로 단위 테스트부터 시작하는것이 좋다.
Input, Output이 명확한 코드가 단위테스트를 연습하기 좋다.

2단계 TDD 연습하기

난이도가 낮은 자신에게 익숙한 문제로 시작하는 것을 추천
UI, DB에 의존 관계를 가지지 않는 요구사항으로 연습하는 것을 추천

TDD Circle of Life : Test Fails -> Test Passes -> Refactor -> ...
=> 대부분의 사람들은 Test Fails -> Test Passes 과정만을 반복하지만, 여기서 정말 중요한 것은 Refactor 활동이다.

3단계 메서드 분리하기(리팩토링)

객체지향 생활체조에 따른 메서드 분리

코드분리가 좋은 이유?
코드를 분리하므로 하나의 메서드를 처음 보는 사람에게 더 이해파악이 쉬워진다.
모든 세부로직이 다 들어있는 코드를 보는것 보다 세부 로직이 모두 메서드화 되어있어 보는 사람으로 하여금 한눈에 파악할 수 있게할 수 있다. (여기서 메서드 명이 정확한 의미로 명시되있어야 할것 같다)

4단계 클래스 분리하기(리팩토링)

1. 일급 콜렉션을 쓴다 : Primitive 변수, 콜렉션 하나만을 가진 클래스를 만들어 해당 클래스에 해당 데이터가 가져야할 제약사항, 특성을 넣는다.
2. 클래스 안에서 인스턴스 변수를 점점 줄여나가자 : 이러면 계속해서 새로운 클래스를 만들어나갈 수 있다.

5단계 장난감 프로젝트로 연습하기

main 메서드를 통해 수동적으로 체크하지 않고 main 메서드 없이 TDD만으로 개발할 수 있다면 TDD를 어느정도 인지하고 있다고 할 수 있다.

6단계 이후 의존관계가 있는 프로젝트로 연습하기

여기서는 앞서 이야기한

테스트하기 쉬운 코드와 테스트하기 어려운 코드를 구분하는 눈
테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 감(sense)

이 굉장히 중요하다.

3. TDD, 리팩토링 적용 - 개인(주니어) -> 팀

TDD, 리팩토링의 필요성을 느끼고 이를 팀에 전파하고 싶을때!

🤔 생각해볼 점이 있음..

• 사람은 기본적으로 변화를 거부하는 성향
• 팀은 변화를 거부하는 성향이 더 강함
• 대부분의 사람들은 변화에 실패한 경험을 가지고 있음

=> 이런 경우 내가 맡은 기능 구현에 TDD, 리팩토링 적용하여 묵묵히 혼자 진행
근데 리더가 하지말라면 하지말자. 손해보는 장사가 아니다.

4. TDD, 리팩토링 적용 - 팀

팀장이 되어도

• 사람은 기본적으로 변화를 거부하는 성향
• 팀은 변화를 거부하는 성향이 더 강함
• 대부분의 사람들은 변화에 실패한 경험을 가지고 있음
  이것들을 생각해봐야한다.

1:1 면담에서 팀원이 문제점을 이야기 할때 '어떻게 하면 될까?', '너라면 어떻게 할것 같아?' 라는 반문을 해라
-> 팀원들은 자신만의 해결책을 가지고 있다.

현재보다 조금씩 나아지고 있다는 방향성이 중요하다. -> 이러면 팀원들이 기다려주고 신뢰한다.

리팩토링, 클린코드를 진행하다 성능이슈가 생길 때?

하드웨어는 점점 싸지고 인건비는 점점 비싸진다.
즉 장기적인 관점에서 일단은 가독성이 높은 방향으로 코드를 만드는 것이 중요하다 생각한다.
실질적으로 코드 로직 상에서 성능 이슈가 생기는 상황은 별로 없다. 대부분 DB나 통신 성능 이슈임 즉, 문제가 생기는 시점에서 해당 문제를 생각하면 될 것 같다.

배운 점

TDD의 전반적인 개발 노하우나 방법보다는 리팩토링 및 학습 방법, 조직에 적용하는 방법에 대한 조언이 있던 강의였다. 소프트 스킬에 대한 이야기도 많이 해주셔서 원래 목적과 완전히 부합하진 않았지만 배운 점이 많은 강의였던것 같다.

👀⚡️ 눈과 감

테스트하기 쉬운 코드와 테스트하기 어려운 코드를 구분하는 눈
테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 감(sense)

부분이 중요하다는 사실이 동감되면서 인상깊게 다가왔지만 정확하게 그 기준은 말해주지 않으셨다. 당연 이 부분은 말해준다고 되는 부분이 아닌 본인이 터득해나가야하는 부분이기에.. 따로 언급은 안하신게 아닐까 생각한다.

🎨 일급 콜렉션

'일급 콜렉션을 쓴다' 는 부분도 굉장히 인상적으로 다가왔다. 일급 콜렉션을 쓰면서
클래스를 분리하면 각 클래스별로 테스트를 할 수 있고, 이는 결론적으로 비즈니스 로직(Service) 단에서의 역할분리로 이어질 수 있으니 비즈니스 로직에서의 테스트와 일급 콜렉션에서의 테스트를 따로 진행할 수 있고, 자연스럽게 해당 테스트들은 한가지 요구사항, 도메인에 대한 테스트가 되고 결과적으로 전체적인 테스트가 쉬워지는 방향으로 갈 수 있다고 생각된다.

일급 콜렉션 사용 
-> 클래스 분리 
-> 비즈니스(서비스) 로직의 과중 감소 
-> 테스트 분할 진행 가능 
-> 한가지 요구사항, 도메인에 대한 테스트 가능 
=> 쉬운 테스트 가능

[minaver]

[TDD로 숫자 야구 게임 구현 1]

TDD란?

단위 테스트 != TDD
TDD는 테스트 코드를 프로덕션 코드보다 먼저 구현해야 한다.

TDD = TFD(Test First Development) + 리팩토링

👉 TDD를 TFD 라고 하지 않는 이유는 TDD 과정에는 항상 '리팩토링 과정' 이 포함되어 있기 때문이다!
즉 TDD 과정은 설계를 한번에 몰아서 하자는 것이 아닌 어떤 테스트 케이스 하나를 추가하고 그 사이클 내에 설계 작업을 작은 단위로 쪼개 설계를 진행하자는 것이다.

TDD를 하는 이유?

• 디버깅 시간을 줄여준다.
• 동작하는 문서 역할을 한다.
• 변화에 대한 두려움을 줄여준다.

TDD Cycle

실패하는 테스트 구현 -> 테스트가 성공하도록 프로덕션 코드를 구현 -> 프로덕션 코드와 테스트 코드를 리팩토링 -> ...

TDD 원칙

1. 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

TDD 방법

1. 요구사항 분석을 통해 대략적인 객체를 설계한다. 이때 핵심 도메인 영역을 집중적으로 설계한다.
2. MVC 기준으로 View와 Controller 부분은 테스트 하는것이 까다로우니 핵심 도메인 영역을 설계 후 테스트를 목표로 한다.
3. 테스트하기 쉬운 영역과 테스트하기 어려운 영역을 분리한다. (예를 들면 랜덤 생성 처리하는 함수의 테스트는 어려우니 분리)
4. 테스트 코드 먼저 작성
5. 개별 테스트 코드에서 사용하는 클래스, 메서드를 거꾸로 생성하면서 컴파일 에러를 빠르게 해결 (option + enter + 디렉토리 변경)
6. 실행해본다. => 실패하는 테스트
7. 리팩토링
8. 다시 테스트 (경계값을 가지고 테스트 해보는게 중요 : 가능한 적은 테스트 케이스를 가지고 모든 경우를 테스트 해볼 수 있는게 좋은 테스트 코드이다)
9. 하나의 기능을 리팩토링까지 완료해서 본인이 만족하는 수준까지 완료하면 커밋하는게 좋음

TDD 조언

큰 덩어리를 작은 단위로 쪼개야 테스트, TDD가 쉬워진다.

숫자 야구 게임의 경우
처음에 123, 456 두 수가 주어지면 두 숫자 배열을 전부 비교한다고 생각한다.
근데 생각보다 로직이 복잡하다 각 자리수를 도는 이중 루프가 들어가는 로직이 들어가야할 것으로 보인다.
그렇다면 위에 큰 덩어리를 작은 단위로 쪼갬 을 생각해 보자.

이를 작은 단위로 나누려면 숫자 하나하나를 비교해야한다.
그러면 1, 4를 비교하면 될까?
여기서 1과 4만 비교하면 아무런 정보도 얻을 수 없다. 왜냐면 숫자 야구는 숫자만을 비교하는게 아닌 숫자의 위치도 비교해야 함이다.

숫자값 위치값이라는 데이터로 1 1 , 4 1 이라는 위치값을 같이 주고 해당 조건을 비교하는 로직을 만들면

1 1 , 4 1 -> nothing
1 1 , 1 1 -> strike
1 1 , 1 2 -> ball 

이라는 조금 더 작은 단위의 유효한 로직을 만들 수 있다.

테스트를 용이하게 하기 위해서는 이처럼 큰 단위의 로직을 작은 단위의 유효한 로직으로 만드는 작업이 중요하다