TDD, 클린 코드 with Java (미션 1. 자동차 경주 - 단위 테스트)

4월 초부터 NEXTSTEP에서 진행하는 TDD, 클린 코드 with Java 과정을 듣고 있습니다.

작년부터 계속 들어야겠다고 생각하다가 올해 듣게 되었는데, 마침 비슷한 시기에 번아웃이 와버려서.. 😭 첫 번째 미션도 굉장히 오래 걸렸네요. 😭😭

 

교육에서 진행한 미션들을 토대로 배운 내용 및 피드백에 대해 정리해 보고자 합니다.

 

(혹시 다르게 생각하시는 포인트가 존재한다면, 말씀해 주시면 감사하겠습니다 🙏)

 

첫 번째 미션인 자동차 경주 - 단위 테스트에는 총 5개의 미션이 존재하고, 각 미션마다 코드를 작성하여 PR을 보내면 리뷰어가 코드 리뷰를 해주는 식으로 진행이 되는데요, 자동차 경주 미션을 수행하며 받았던 리뷰 및 새로 알게 된 내용들은 다음과 같습니다.

 

 

1단계 - 학습 테스트 실습

1단계 미션은 String, Collection(Set)의 클래스에서 특정 함수에 대해 구현하고 단위 테스트를 학습하는 미션입니다.

 

JUnit - containsExactly()

테스트 코드에서 2개의 원소가 존재하는지 검증할 때 size나 인덱스의 값을 사용했었는데, 

containsExactly() 메서드를 통해 정확한 값을 간단히 검증할 수 있습니다.

(해당 메서드는 원소의 순서도 정확히 일치해야 합니다.)

 

 

2단계 - 문자열 덧셈 계산기

2단계 미션은 쉼표(,) 또는 콜론(:)을 구분자로 가지는 문자열을 입력받고, 구분자를 기준으로 분리한 숫자의 합을 구현합니다.

 

매번 새로운 객체를 생성하지 말자

위 코드의 41번 라인에서 Pattern 객체는 무상태 객체의 성격을 가지기에 매번 새로운 Pattern을 생성할 필요는 없을 것 같다는 피드백을 받았습니다.

 

JUnit - @NullAndEmptySource

위 두 테스트는 각각 null, empty를 테스트하는 코드로 @NullAndEmptySource 어노테이션을 사용하면 하나의 메서드로 같이 테스트를 검증할 수 있을 것 같습니다.

 

 

메서드의 네이밍에 관하여

메서드의 네이밍을 고려할 때 항상 동사로 시작하는 네이밍을 선호했었는데, 앞으로는 메서드의 성격에 따라 달리 지어야겠습니다.

• 빌더: 무언가를 만들고 새로운 객체를 반환
• 조정자: 객체로 추상화한 실세계 엔티티를 수정하는 메서드로 반환 타입이 void

빌더(builder) 메서드 예시
 - int pow(int base, int power);
 - float speed();
 - Employee employee(String name);

조정자(manipulator) 메서드 예시
 - void save(String content);
 - void put(String key, int value);
 - void remove(int index);

 

3단계 - 자동차 경주

3단계부터 본격적으로 자동차 경주를 구현하는 미션입니다.

요구사항은 대략적으로 다음과 같습니다.

• 자동차 대수와 시도 횟수를 입력받고, 조건에 따라 자동차는 전진 및 멈출 수 있고, 자동차의 상태를 출력합니다. (Console)

 

클래스 네이밍과 의도

InputCar 클래스명이 의도를 파악하기 힘들다는 리뷰를 받았는데, 저도 작성할 때 파악하기 힘들다는 느낌을 받았었습니다.

조금 더 명확한 의도를 가진 UserInput 등으로 작성하면 더 좋지 않을까 생각합니다.

 

경곗값에 대한 꼼꼼한 테스트

테스트를 어떻게, 무엇을 잘 작성해야 하는지 아직까지 답을 잘 모르겠지만 여기서 배운 것 중 하나는 경곗값에 대한 테스트입니다.

자동차 경주 미션에서는 랜덤 값이 4 이상이면 전진을, 4 미만이면 멈춰있는 상태를 가지는데 여기서 경곗값은 4입니다.

보통 경곗값에 대해 많은 문제가 발생할 확률이 높기에 경곗값을 기준으로 테스트하는 것이 좋다고 합니다.

 

또한 위 테스트는 4 이상인 경우만 테스트가 존재하기에 4 미만인 케이스에 대해서도 테스트를 작성하면 더욱 꼼꼼한 테스트가 될 수 있을 것 같습니다.

 

무의미한 객체

위 코드에서 랜덤 값을 생성하는 책임은 ThreadLocalRandom이 이미 가지고 있고, RandomValue는 어떠한 조작이나 로직 없이 랜덤 값만 생성해서 전달하고 있습니다.

ThreadLocalRandom 클래스를 한 번 감싼 것을 제외하면 딱히 클래스의 필요성이 불분명해 보입니다.

 

이것과는 별개로 위 코드는 nextInt() 메서드가 랜덤 값을 반환하기에 테스트하기도 쉽지 않아 보이는데요, 

위 코드를 테스트가 용이한 코드로의 작업은 이후 단계에서 진행해 보겠습니다. 🙂

 

 

4단계 - 자동차 경주(우승자)

4단계 미션은 3단계 미션에서 아래의 요구 사항이 추가된 미션입니다.

• 자동차에 이름을 부여할 수 있다.
• 자동차 경주 게임 완료 후 우승자를 출력한다. (우승자는 한 명 이상일 수 있다.)

 

모든 원시값과 문자열을 포장하라 (Car - Position, Name)

미션 4단계부터는 소트웍스 앤솔러지 책에서 다루고 있는 객체지향 생활 체조 원칙 중 하나인 모든 원시 값과 문자열을 포장하여 사용해 보려고 했습니다.

 

그에 따라 Car 객체에는 자동차의 이름을 나타내는 Name, 자동차의 거리를 나타내는 Position을 primitive 변수가 아닌 포장한 객체를 선언하여 사용했습니다. 이로 인해 기존의 코드라면 전부 Car 객체에 추가해야 할 로직이나 유효성 검증 등이 각각 Name, Position 객체에게 역할이 분리되었고, 메시지를 전달하여 조금 더 객체지향적인 코드를 작성할 수 있는 경험을 할 수 있었습니다.

 

public으로 제공되는 API에 대해서는 가능한 전부 테스트를 작성하자.

위 Car 객체와 연관되는 부분으로 자동차 경주와 관련된 로직은 대부분 Position, Name 객체에 존재하기 때문에 Car 객체의 메서드들에 대한 테스트도 필요한가?에 대한 대답이 public 메서드는 가능한 테스트를 진행해라 였습니다. (사실은 귀찮아서...)

 

단순히 Name, Position 객체를 반환하는 public 메서드보다는 winner인지 확인하는 isWinner 메서드 정도는 테스트가 필요하지 않을까 싶습니다.

 

테스트는 기본적으로 public하게 제공되는 API는 모두 최대한의 테스트를 제공하는 게 좋습니다.
public한 메서드가 외부에 공개된다는 것은 그 이후로는 deprecated 시키기 어렵고 계속해서 호환이 되어야 하고 안전성을 제공해야 한다는 뜻이기도 하거든요

 

Test Fixture 생성

현재 로직에서는 자동차의 기본 거리는 0이고, 자동차가 전진하려면 반드시 메서드를 실행한 후 전진이 가능합니다.

 

따라서 우승자의 거리를 구하기 위해 forward() 메서드가 선행이 되어야 하는 조건이 존재합니다.

 

이를 해결하기 위해 Fixture를 고려할 수 있는데, Fixture란 테스트를 실행하기 위해 필요한 것을 의미합니다.

위 코드에선 forward() 메서드를 Fixture라고 볼 수 있을 것 같습니다.

 

위에서는 Test Fixture를 위해 Position에서 distance를 매개변수로 받는 생성자를 추가하면 될 것 같습니다.

개인적으로 테스트를 위해 프러덕션 코드가 추가되는 것은 좋지 않다고 생각하지만, 위 코드처럼 생성자를 오버라이딩 하는것은 괜찮지 않을까? 하는 생각도 있습니다. 🧐

2주 차 라이브 강의에서도 포비가 위 내용에 대해 다음과 같이 언급하고 있습니다.
테스트를 위한 코드(메서드)가 추가되는 것은 악행이다.(설계가 잘못된 것)
하지만 테스트를 위한 생성자를 추가하는 것은 가능하다. (아무래도 생성자를 통한 객체 생성은 이후 상태 변경은 불가능하지만, 메서드는 상태를 변경하기에 그런 것이 아닐까 생각합니다. 🧐

물론 위처럼 테스트를 위한 생성자를 추가한다면 목적과 다르게 사용되어 사이드 이펙트가 발생할 수 있는 위험도 존재합니다.

(자동차의 최초 거리는 0인데, 누군가 생성자를 잘못 사용하여 최초 자동차 거리를 임의로 지정하는 등의 문제가 발생할 수 있습니다.)

 

결국 각 선택에는 장단점이 존재하고, 현재 상황에 더 적합한 방법을 선택하는 것이 좋을 듯 합니다.

 

문서화의 세분화

// Before
- 자동차에 이름을 부여할 수 있다. (이름은 5글자를 초과할 수 없다.)

// After
- 자동차에 이름을 부여할 수 있다.
  - 5글자 이내의 이름으로 생성할 경우 정상적으로 생성된다.
  - 5글자 이상의 이름으로 생성할 경우 IllegalArgumentException 예외를 던진다.

기능 목록에 대해 문서화를 하면 더욱 명확해지고 테스트 코드 작성에도 연습이 될 듯 합니다.

 

정적 팩토리 메서드 패턴을 통해 객체 생성을 명확하게, 내용은 은닉하기

https://tecoble.techcourse.co.kr/post/2020-05-26-static-factory-method/

모두가 0인 Position을 초기값으로 받는다면 정적 팩토리 메서드 패턴을 활용해서 해당 내용을 메서드 시그니처로 올리고 내용은 은닉해도 될 것 같습니다.

 

 

5단계 - 자동차 경주(리팩터링)

5단계 요구사항은 3~4단계의 자동차 경주에 대해 핵심 비즈니스 로직을 가지는 객체를 domain 패키지, UI를 view 패키지 등으로 구현하는 과정입니다.

 

앞 단계에서 조금씩 분리를 해놔서 따로 많은 부분에 대해 작업을 하지는 않았습니다.

 

자동차의 전진 조건을 제어하는 전략 패턴을 구현하자.

기존 As-Is 코드에서는 랜덤 값이 playing() 메서드에서 생성되어 테스트도 어렵고, Position 객체가 스스로 조건을 판별해 전진을 하는 어색한 상황이 존재합니다.

 

또한 현재 요구 사항은 전진 조건만 존재하지만, 추후 요구 사항이 변경하여 후진 조건 등이 추가된다면 비즈니스 내용(조건)이 추상화가 되어 있지 않기에 유지 보수성이 떨어질 수 있다는 피드백을 받았습니다.

 

랜덤 값을 생성하는 로직은 분리하여 테스트하기 어려운 부분을 테스트 가능한 구조로 개선하고, 비즈니스 로직을 추상화 하는 리팩터링을 진행해 보았습니다.

 

따라서 비즈니스 로직은 전략 패턴을 통한 추상화를 적용하였고, 랜덤 값을 생성하는 로직 또한 인터페이스로 분리하여 테스트 코드를 작성할 때에도 Fake 객체를 생성하여 테스트에 용이하도록 리팩터링을 적용하였습니다.

 

추가적으로 ForwardStrategy 인터페이스의 isMovable() 메서드의 반환 타입을 boolean이 아닌 int형으로 선언하고, 구현체에서 리턴 값을 0이나 1로 반환한다면 forward() 메서드에서 if 조건문도 제거할 수 있을 것 같습니다.

 

 

 

자동차 경주 미션이 너무나 늦게 끝나 버려서 두 번째 미션 부터는 조금 더 힘을 내어 빠르게 진행하고, 피드백을 받고, 포스팅을 작성할 수 있으면 좋겠습니다 😂