Life/Book Record

[서평] 테스트 주도 개발 - 켄트 벡

샤아이인 2022. 7. 22.

저의 돈으로 직접 사서 직접 완독해 본 후 써보는 후기입니다. 따라서 장점은 장점대로 칭찬할 것이며, 단점은 단점대로 언급할 것입니다.

 

 

테스트 주도 개발

테스트 주도 개발은 테스트가 개발을 주도하는 방법이다. 테스트가 개발을 주도한다는 것은 테스트가 코딩의 방향을 이끌어 간다는 말이다. 테스트를 실패하는 코드가 없으면 코딩을 하지 않고

book.naver.com

 

<읽은 기간>

2022/07/01 ~ 2022/07/20

(예전에 2장까지 읽다 포기한 적이 있었습니다 ㅎㅎ)

<리뷰 순서>

1) 책의 표지

2) 단원별 구성

3) 내용

4) 읽은 소감

우선 저의 글의 앞부분만 보는 분들을 위해 먼저 간단히 3가지에 대해 답해보겠습니다.

Q 이 책을 읽기 전에 필요한 수준/ 지식은?

=> 일단 TDD 초보자에게는 추천하지 않는다.

이 책을 쓰신 켄트 벡이야 TDD의 사상을 널리 알리기 위해 최대한 쉽게? 글을 쓰셨겠지만, 생각처럼 쉽게 잘 읽히는 책은 아니다.

(대부분이 쳅터2를 읽다 접는 책으로 유명하다)

 

어느 정도 개발을 해본 사람이면 모를까, 난생처음 TDD를 배우기 위한 책으로는 추천하지 않는다.

만약 처음 TDD를 글로써 배워보고 싶다면 다음 책을 추천한다.

https://blogshine.tistory.com/226

 

[서평] 테스트 주도 개발 시작하기

저의 돈으로 직접 사서 직접 완독해 본 후 써보는 후기입니다. 따라서 장점은 장점대로 칭찬할 것이며, 단점은 단점대로 언급할 것입니다. 테스트 주도 개발 시작하기 작동하는 깔끔한 코드를

blogshine.tistory.com

 

읽기 어렵다는 점을 제외하고 나면, 정말 좋은책이다.

단순하게 답을 제시하기보다는 켄트 벡의 생각이 많이 담겨있는 책이라 좋은 것 같다.

 

Q 이 책을 읽어야 할 필요성, 어디에 도움이 될까?

=> 나 같은 경우 TDD 자체의 개발방식에 익숙한 단계는 되었다. (잘한다는 거 아니다... 익숙은 하다는 것이다... 내 테스트 코드들은 아직도 많이 더럽다...)

콘솔 기반의 과제나 개발을 할 때는 대부분 테스트 코드를 먼저 작성하기 시작했으며, Spring 기반의 애플리케이션을 만들 때는 ATDD 사이클을 적용하려 노력하고 있다.

 

이 정도 스스로 공부를 해봤으면 정석에 가까운 전설의 그 책! 테스트 주도 개발을 읽을 때가 된 거 같았다.

켄트 벡이 어떤 생각을 하면서 TDD 사이클을 진행해 나가는지 확인해 볼 수 있는 아주 좋은 책이다.

Q 이 책을 읽은 후 추후 공부는?

=>  TDD는 헬스와 유사한 것 같다.

지속적인 반복과 의식적인 노력을 통해 연습해 나갈 수 있다.

Spring 기반의 TDD를 지속적으로 더 노력할 것 같다.

 

다음 읽어볼 책으로는 다음 책을 구매해 두었다

ATDD의 정석에 가까운 책이라 알려져 있다.

애자일 방법론 기반의 ATDD를 Spring에 적용시켜 보려 노력 중인데, 이에 대한 기반 지식을 학습할 수 있을 것 같다.

 

1. 책의 표지

인사이트의 책들은 다 표지가 깔끔해서 좋다.

내가 이쁘다 생각한 책들은 대부분 인사이트, 위키북스인 것 같다.

 

원래 원서는 위 표지가 아닌데, 한국에서는 표지가 바뀌어서 나온 것 같다.

이쁘니 다행인 걸로 ㅎㅎ

 

2. 단원별 구성

책의 목차는 다음과 같다.

▶ 1부 - 화폐 예제

간단하게 TDD 사이클 기반의 통화 계산 코드를 작성해 나가면서 TDD를 경험해 나갈 수 있다.

Java코드 기반으로 되어있어 나에게는 편하게 읽혔다.

 

▶ 2부 - xUnit 예시

xUnit을 Python 기반으로 만들어가는 과정이다.

나는 Python 코드가 마음에 들지 않아, 따로 Java로 만들어 가면서 글로 정리해 두었다.

 

▶ 3부 - 테스트 주도 개발의 패턴

3부도 좀 어려웠으며, 이해 못 하고 지나간 부분도 분명 존재한다.

중간중간 짧은 글로만 설명하고 지나가는 부분들이 분명 있다. 이는 독자가 스스로 공부해봐야 할 것 같다.

(ex 플러거블 객체가 잘 이해가지 않았었다. 플러거블 셀렉터는 Reflection을 공부해봐서 이해가 가는데... 객체는 이해가 잘...)

 

2부 내용을 기반으로 리뷰를 해보겠다.

 

3. 내용

일단 책의 모든 쳅터들이 매우 짧게 구성되어 있다. 대충 10장? 장도가 한 페이지로 돼있는 것 같다.

이 또한 저자의 agile 철학이 담겨있는 구성이 아닐까? 싶다.

 

더 나아가 TDD의 정신일 수도 있겠다. RED - GREEN - REFACTOR 사이클을 빠르게 돌리듯,

책의 쳅터들 또한 빠르게 읽으며 해당 단원의 주제에만 집중할 수 있도록 한다. 이는 TDD 라 할수 있다.

xUnit 예시 관련 도입부이다.

 

책에서 보이듯, 약간 외국식 아저씨 개그가 중간중간 있는 것 같다? 책을 진지하게 읽어서 그런가... 읽으면서 웃은 적은 없다...

 

책은 대부분 위와 같은 형식으로 설명해준다.

특히 2부 같은 경우 Python을 활용하기 때문에 파이썬을 아는 사람이 읽는다면 나보다는 덜 어려워할 것 같다.

파이썬을 깊게 공부해본 적이 없어서 어렵게 느껴졌다...

 

참고로, 1부에서는 Java로 진행했다.

 

책에 코드가 많은 것은 아니지만, 중간중간 지속적으로 코드가 나온다.

 

또한 위와 같이 마지막 장에서 해당 쳅터를 요약하는 글로 끝이 나는 것이 일반적이다.

 

사실 이 책에서는 위 2부의 내용이 가장 중요하다고 생각한다.

따라서 나는 직접 Java로 구현하여 글로 만들어 두었다. 도움이 필요한 분이 있다면 읽어보길 권장한다.

 

https://blogshine.tistory.com/469

 

[TDD] JUnit 만들기 - 1

해당 글은 TDD: By Example 책의 2부 내용인 Python으로 xUnit 만들기를 Java 코드로 변경하여 스스로 만든 내용입니다. 총 2개의 글로 작성될 예정입니다. 1. Junit 만들기 1부 2. Junit 만들기 2부 코드 또한 G.

blogshine.tistory.com

https://blogshine.tistory.com/470

 

[TDD] JUnit 만들기 - 2

해당 글은 TDD: By Example 책의 2부 내용인 Python으로 xUnit 만들기를 Java 코드로 변경하여 스스로 만든 내용입니다. 총 2개의 글로 작성될 예정입니다. 1. Junit 만들기 1부 2. Junit 만들기 2부 코드 또한 G.

blogshine.tistory.com


13장에 다음과 같은 내용도 있었다. 다형성을 활용하는 방법 중 하나이다.

@Test
public void reduceMoneyTest() {
    Bank bank = new Bank();
    Money reduced = bank.reduce(Money.dollar(1), "USD");
    assertThat(reduced).isEqualTo(Money.dollar(1));
}

위와 같은 테스트 코드가 있다고 해보자.

 

public class Bank {

    public Money reduce(Expression source, String to) {
        if(source instanceof Money) {
            return (Money) source;
        }
        Sum sum = (Sum) source;
        return sum.reduce(to);
    }
}

Bank에서는 복잡하게 class의 타입을 확인하는 로직을 통해 구별한다. instanceof를 사용하고 있다...

 

Class를 명시적으로 검사하는 코드가 있다면, 항상 다형성을 통해 해결하는 것이 좋다.

 

우선 Sum이 reduce를 구현하니, Money 또한 reduce를 구현하도록 변경시키자!

public class Bank {

    public Money reduce(Expression source, String to) {
        if(source instanceof Money) {
            return ((Money) source).reduce(to);
        }
        Sum sum = (Sum) source;
        return sum.reduce(to);
    }
}

 

Expression 인터페이스에 reduce 메서드 추가

public interface Expression {
    Money reduce(String to);
}

 

다음과 같이 변경하여 다형성을 이용하면 instanceof와 같이 직접적으로 확인하지 않아도 된다.

public class Bank {

    public Money reduce(Expression source, String to) {
        return source.reduce(to);
    }
}

 

위와 같이 책을 읽다 보면 객체지향적인 내용들 또한 생각해볼 수 있는 부분이 많다.

 

4. 읽은 소감

 

장점

그냥 책 자체에서 배워볼 점이 많다.

어떻게 보면 TDD의 붐을 일으키신 장본인이라 할 수 있는 켄트 벡이 어떤 생각을 하면서 TDD를 진행해 나가는지 지켜볼 수 있다.

위에서도 말했듯, 정답이라기보다는 켄트 벡 자신의 생각이 많이 담겨 있는 책이라 더 좋다 생각한다.

 

 TDD책에서 생활방식

단순하게 코드 level에서의 TDD만 생각하는 것 이 아니라, 우리의 일상생활에서도 어떻게 TDD를 뒷받침 해야 하는지와 같은 내용들도 있어 재미있다 생각하였다.

 

예를 들어 "낡은 책상, 좋은 의자" 란 소단원은 진짜 웃긴 부분인 것 같다.

TDD책을 읽다 비싼 의자를 사라는 말을 읽게 될 줄 누가 알았게는 가?

 

켄트 벡 주변 인물들의 생각들

그 외에도 켄트 벡 자신의 생각뿐만 아니라, 옆에서 그에게 조언을 해준 사람들의 접근 방식 또한 읽어볼 수 있다. 

 

예를 들어 주석과 관련된 내용이 있었는데, 패트릭 로간이 이와 같은 아이디어를 제공했다고 한다.

나는 몇몇 이유로 최근 모든 작업에 '아웃라인'을 작성하기 시작했다.
테스팅 또한 마찬가지다. 테스트를 작성하기 전에 일단 원하는 테스트에 대한 짧은 아웃라인을 적는다. 예를 들어
/* 터플 공간에 추가하기 */
/* 터플 공간에서 갖고오기 */
/* 터플 공간에서 읽어들이기 */
 이것들은 내가 각 카테고리 밑에 특정 테스트를 추가할 때까지 일종의 임시 자리 표시가 된다.

 

또한 마지막 장에서 로버트 마틴이 2장 남짓 되는 짧은 글을 적어두었는데, 이 또한 대가의 생각을 엿볼 수 있는 좋은 파트라 생각된다.

 

 테스트 주도 개발 시 생각해볼 점들

TDD에서는 심리적 부담감을 줄이기 위해 "극단적인 악행"을 수행하기도 한다.

예를 들어 1+3의 결과를 반환해야 하는 함수를 구현해야 한다면, 논리적 계산을 통해서 가 아닌, 직접적으로 해당 상수 4를 반환해버리는 것이다.

 

이렇게 까지 해서 통과시키는 테스트가 의미가 있을까?

 

충분한 의미가 있다! TDD에는 개발자의 심리적 요소 또한 중요하다.

빠른 시간 안에 초록 막대를 확인하려 노력하는 것 또한 중요하다. 너무 오랜 시간 동안 빨간 막대 상황에 있으면 안 된다.

 

이를 극복하기 위한 가장 간단하고도 효과적인 방법은 가짜로 구현하기, 즉 그냥 직접 상수를 반환해버리는 방식일 것이다.

이후 삼각 측량법 등을 통해 일반화시키고, 리팩터링을 진행해 나가면 된다.

 

이렇게 TDD의 호흡 과정에서 생각해볼 점들을 배울수 있는 좋은 책이다!

 

단점

단점은 음... 이게 단점은 아닐 거 같은데, 2단원이 Python으로 되어있다는 점이 좀....

그냥 전부다 Java 코드면 좋았으려 만... 아쉽게도 이 책의 저자인 켄트 벡은 스크립트 언어(명시적 타입 언어가 아닌)를 좋아하신다고 하셨다.

예를 들어 Python, JavaScript에 해당될 것이다.

 

저자 또한 비행기에서 Python을 처음 배워가면서 동료와 함께 xUnit을 처음 개발하셨다고 한다.

 

어떤 언어를 배우기 위해 좋은 방법으로 xUnit을 만들어 보는 것이라 책에 적혀있기는 한데...

 

그냥 전부 Java로 책을 작성해주지.... 싶다...

 

아 마지막으로 내용이 조금 어렵다.

이 리뷰를 읽는 분은 아닐 수도 있지만... 적어도 나에게는 좀 어려운 부분이 있었다.

 

한마디로 명서는 명서다. 나중에라도 꼭 읽어보길 권장한다.

댓글