우아한테크캠프 Day03

코드 작성할 때 가장 중요한 것은

중복코드 제거 (프로덕션 코드뿐만 아니라 테스트 코드도)

지금 우리에게 가장 필요한 역량은

리팩토링 역량 (많은 시간을 들일 것)

테스트 코드 하나 완성될 때마다, 바로 리팩토링 진행

역시 박재성 교수님 수업은 믿고 듣는 수업이다.

---

Day03 학습 내용

---

자동차 경주게임을 TDD로 진행하며 어려웠던 점

1. 우승자를 구하는 로직을 테스트코드 작성할 때, 초깃값을 내가 원하는 형태로 만들 방법이 없어서 어려움을 겪었다.

     (Car 정보를 개발자가 임의로 조정할 수 있어야 테스트하기 쉽다.)

   * 반성 : 우승자 구하는 메소드에 input으로 초깃값을 넣어주는 방법을 왜 생각 못 했을까?

2. 자동차를 move 하는 메소드 내부에서 랜덤 숫자를 생성하는 부분이 있어 테스트하기 어려웠다.

   Why? 호출할 때마다 자동차가 움직일지 아닐지 예측하기 어려웠기 때문에

문제를 어떻게 해결했나? 인터페이스로 테스트하기 쉬운코드와 테스트하기 어려운 코드를 분리시켰다. (DI를 통해 해결!!!) 

                                      인터페이스를 구현한 실제 사용할 랜덤클래스와 테스트용 랜덤클래스 2개를 만듦 (바꿔치기 개념)

인터페이스

public interface RandomGenerator {
    int generate(int limit);
}

실제 사용할 랜덤클래스

public class RealRandomGenerator implements RandomGenerator {
    @Override
    public int generate(int limit) {
        Random random = new Random();
        return random.nextInt(limit);
    }
}

테스트용 랜덤클래스

public class TestRandomGenerator implements RandomGenerator {
    @Override
    public int generate(int limit) {
        return 7;
    }
}

DI 주입하는 부분

@Test
public void 이동() {
    List<RacingCar> cars = Arrays.asList(pobiCar);
    RandomGenerator randomGenerator = new TestRandomGenerator();

    RacingGame racingGame = new RacingGame(cars, randomGenerator);
    racingGame.moveCars(1);

    assertThat(cars.get(0).getPosition()).isEqualTo(1);

}

TDD란

요구사항을 분석하는 기술 + 설계를 잘하게 도와주는 도구 (좋은 설계를 해야 TDD가 가능)

* 모든 기능을 TDD로 하기 현실적으로 어렵다. 전체 기능이 아니더라도 일부 기능을 뽑아서 TDD 연습을 해볼 것

TDD에서 중요한 것

기능 목록 추출 (요구사항을 보며 기능을 작은 단위로 쪼갤 수 있는 분석 능력이 중요하다.)

ex. 

1. 콤마 구분으로 이름을 받아 자동차 생성하는 기능

2. 경주가 끝난 자동차에서 우승 자동차 추출

3. 우승 자동차에서 화면에 표시할 문자열 생성

4. 자동차 위치에 따라 화면에 표시할 문자열 생성

[Tip]

처음부터 다 하려고하지말고 할 수 있는 범위까지 기능 목록을 추출해 볼 것. 처음에는 분석할 수 있는 범위가 적을 것이다.

하지만 시간이 가면 갈수록 기능 목록이 더 많아지고 세밀해지게 된다. 

개발하다가 기획자들과 소통하다 보면 도메인 지식이 넓어지기 때문에

TDD를 하면 좋은 점

1. TDD를 하다 보면 이런 input을 넣으면 이런 output이 나오는 구나라고 API 사용법을 알게 된다.

2. API를 빠르게 익히고 습득하는 데 좋은 도구다.

   (다른 분야로 넘어갔을 때도 API를 익히는 데 있어 테스트를 적극적으로 활용하면 좋다.)

TDD 절차

1단계 : 임의로 클래스를 만들고 사용할 메소드의 input과 output을 정함 (틀(?)을 만드는 과정) - fail 과정

2단계 : 프로덕션 코드 구현 

3단계 : 테스트 성공 -pass 과정 

4단계 : 리팩토링

TDD 기능목록 관리법

todo

이름 입력값이 null 또는 빈 문자열인 경우

...

done

콤마 구분으로 이름을 받아 자동차 생성

...

구현하다가 또 다른 구현 거리가 생기더라도 구현하고있던 기능을 계속해서 구현해 나갈 것. 

다만, 구현할 것이 생긴다면 todo에만 기록 해둘 것

객체지향 프로그래밍

객체 지향 프로그래밍에서는 객체와 객체를 비교해야 한다. (객체끼리 상태 값을 비교하는 게 아니다)

# 객체지향 생활체조 원칙

• 규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만 한다.
• 규칙 2: else 예약어를 쓰지 않는다.
• 규칙 3: 모든 원시값과 문자열을 포장한다.
• 규칙 4: 한 줄에 점을 하나만 찍는다.
• 규칙 5: 줄여쓰지 않는다(축약 금지).
• 규칙 6: 모든 엔티티를 작게 유지한다.
• 규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
• 규칙 8: 일급 콜렉션을 쓴다.
• 규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

[Tip]

객체에 메시지를 던져 물어봐라 (객체에 메시지를 던지는 구조로 바꾸면 indent가 줄어든다.)