테스트 주도 개발 독서 후기 (feat. TDD)
안녕하세요. yeTi입니다.
오늘은 테스트 주도 개발을 읽은 후기를 기록하려고 합니다.
저자에게 테스트란?
최근 이력서를 정리하다가 잊혀졌던 기억이 상기되는 경험이 있었습니다.
4년전에 K-MOOC에 대해 소개하는 글을 남긴적이 있습니다.
그 당시에 해당 플랫폼으로 다양한 강의를 청강했는데요. 소프트웨어 공학 : 왜, 무엇을, 어떻게?라는 강의는 들은 기억이 있는데 소프트웨어 테스팅 강의는 들은 기억이 없었습니다.
기억에 없는것을 보니 스스로 얻은 것은 없었구나. 하는 회의적인 기분도 들면서 한편으로는 어떻게 테스트 하는 것이 의미가 있는 활동인지에 대해 고민했었구나. 하는 생각이 들기도 했습니다.
아무튼 이후에
저비용 고품질의 서비스를 만들자.
라는 생각으로 JUnit을 활용하여 테스트라는 것을 만들어 나가기 시작했지만 테스트라는 활동을 어떤식으로 해야하는지는 여전히 숙제였습니다.
Driven 이 무슨 의미일까?
막연하게 접한 단어들이 있었습니다.
OOP(Object-Oriented Programming), TDD(Test-Driven Development), DDD(Domain-Driven Design), EDA(Event-Driven Architecture)
보면, Oriented, Driven 이라는 단어로 설명을 하는데 지향한다, 주도한다가 실제 개발이라는 활동에 어떻게 활용해야하는지 알 수가 없었습니다.
오랜 방황끝에 우연히 알게된 개발자이신 유영모님께서 TDD에 대해 명료하게 해석을 해주셨습니다.
테스트가 개발을 주도한다는 의미는 테스트 코드를 만드는 행위를 통하여 설계도 정의하고 구현 범위도 정의하며 품질관리도 하게되기 때문에 개발 전반의 행위를 주도하게 된다.
비로소 주도한다라는 단어가 가지는 개발활동에서의 의미가 해석되는 순간이었습니다.
그나마 저렇게 설명해주시는 것을 이해할 수 있게 된 배경도 시기적으로 XP를 읽으면서 테스트가 가지는 힘을 실무적으로 느끼고 있던 시기라 쉽게 받아들일 수 있었던거 같습니다.
테스트 주도 개발을 읽게 된 배경
스스로 개발자적인 성장을 위해 OOP(Object-Oriented Programming) -> TDD(Test-Driven Development) -> DDD(Domain-Driven Design) -> EDA(Event-Driven Architecture) 순으로 공부를 해나가야 겠다고 계획하고 있었습니다.
그런데 유영모, 안영회님께서 OOP(Object-Oriented Programming) 보다 TDD(Test-Driven Development)가 개발활동에 실질적인 도움이 많이 된다는 가이드를 주셔서
스스로 가지고 있던 공부 순서였던 OOP(Object-Oriented Programming) -> TDD(Test-Driven Development) 를 변경하게 되었습니다.
리팩토링을 통하여 모든 중복을 제거한다.
빨강/초록/리팩토링은 TDD의 주문과도 같은 것이다.
실무에서 테스트 코드를 작성하면서 경험적으로 빨강/초록이 의미하는 것은 이해가 됐습니다. 하지만 초록을 봤다는 것은 이미 의미있는 수준에서 구현이 되었다는 것인데 리팩토링을 진행한다는 것이 현실적으로 가능할까? 라는 의구심이 들었습니다.
왜냐하면, 저조차 작업 목표를 달성하면 성취감과 빠른 성과의 욕구에 의해 기존 코드를 다시 보려고 하지 않고 다음 작업을 진행하려고 합니다.
그러한 상황에서 이미 테스트를 통한 검증까지한 작업을 더 나은 방법을 위해 고민할 수 있는 여유와 생각의 깊이를 어떻게 만들어갈 수 있을지가 의문이었습니다.
하지만 책을 다 읽은 후 받은 느낌은 리팩토링이라는 의미가 불합리하게 만들어진 레거시를 효율적으로 만드는 것과 같이 거창한 느낌이 아니고,
현재 가지고 있는 테스트 코드와 테스트 코드를 해결하기 위해서 만들어진 코드가 중복을 가지고 있는지에 대한 고민을 하는 수준으로 느끼게 되었습니다.
다만 내가 생성한 코드에서 중복이 있다는 것을 간파할 수 있는 역량을 쌓는것은 개발자의 몫입니다.
문제를 해결하기 위한 접근방식의 변화가 효율적인 코드를 남기는게 된다.
접근방식의 변화 라는 표현을 사용했습니다.
제가 경험한 개발은 공급자(개발자) 입장에서 요구하는 기능을 완수하기 위해 고민한 결과였습니다.
그러다 보니 대화 혹은 코드리뷰를 하다보면 본인이 작성한 코드를 왜 그렇게 사용했는지 명확히 설명하지 못하는 경험이 있었고, 작성한 코드가 어떠한 이유로 목표를 달성했는지 검증하지 못했으며, 사용성을 고려한 설계가 이뤄지지 않았고, 본인의 상상력을 포함한 구현체가 만들어져있었습니다. (확장성이라는 표현아래)
그런데 테스트를 먼저 생각하는 것만으로도 상당 부분이 보완되는 경험을 가졌습니다.
테스트 코드를 작성하려다 보니, 구현의 목표를 명확히 설정해야 어떠한 이유로 본인이 작성한 코드의 검증 목표를 설정했는지 설명할 수 있었으며, 사용자 입장에서 사용성을 고려한 설계가 도출되었고, 상상력이 필요한지 논의를 할 수 있는 기회가 제공되었습니다.
접근방식의 변화 밖에 바뀐것은 없지만 사고의 틀을 바꿀수도 있는 힘을 가지고 있습니다.
가짜로 구현하기
프로그래머들은 모든 종류의 미래 문제를 상상하는 데에 탁월하다. 하나의 구체적인 예에서 시작해서 일반화하게 되면, 쓰잘데기 없는 고민으로 때 이르게 혼동하는 일을 예방할 수 있다.
책을 읽으면서 놀랐던 부분입니다.
빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다.
자동화를 추구하고 중복을 제거해 나가는 프로그래밍의 활동에서 하드 코딩을 하는 죄악을 저지르라는 말이 신선하게 다가오기도 하면서 무슨 의미를 가지는지 이해가 가지 않았습니다.
하지만 책을 읽어나가면서 저는 두 가지로 의미를 해석하게 되었습니다.
- 이쁘게 구현하려고 하지말고 테스트의 정합성과 설계적 타당성을 먼저 고민하라.
- 미래에 발생할 여지가 있는 불확실성에 에너지를 낭비하지 마라.
개발자에게 태스크를 할당하게 되면 직관적으로 구현에 대한 부분이 떠올라 신나게 타이핑을 먼저하려는 습성이 있습니다. 이를 목표를 검증하기 위한 적합성을 고민해보고 그것을 해결하기 위한 설계가 타당한지를 먼저 생각해보라는 의미로 받아들이게 되었습니다.
또한, 개발자들은 흔하게 확장성, 재사용성이라는 단어아래 불확실한 미래에 대한 고민을 상상력에 근거하여 하는 습성이 있습니다. 이를 현실에 필요한 만큼만 에너지를 사용하고 남은 에너지를 보다 유용한 곳에 사용하라는 의미로 받아들이게 되었습니다.
테스트 fixture를 사용하여 테스트 코드의 중복을 제거할 것인가?
테스트 코드를 작성하다보면 다음과 같은 질문을 하게 됩니다.
테스트 fixture 를 사용하여 테스트 코드의 중복을 제거할 것인가?
일반적인 프로그래머라면 당연히 yes 라고 대답할 것입니다. 중복은 제거 대상이니까요.
하지만 XP 에서 테스트의 다른 또 다른 의미로 동일한 문제를 다른 시각에서 볼 수 있는 기회로 설명을 합니다.
그리고 이상한 나라의 수학자 를 보면 수학적 공식을 검증할 수 있는 방법은 원초적인 계산으로 동일한 답이 나오는지 확인하는 것입니다.
실무에선 코드리뷰를 하다보면 기억력이 좋지 않은 이상 왜 해당 테스트가 그러한 결론에 도달하는지를 알기위해 별도의 fixture 분석을 해야하는 경우도 있습니다.
저는 이와 같은 이유들에 의해 테스트 코드를 작성할 때 테스트 fixture를 생성하기 보다는 중복을 허용하여 원초적으로 작성하도록 가이드를 해왔습니다.
하지만 kentbeck은 테스트 fixture를 적극적으로 만든다고하니 생각에 변화를 시도해야하지 않을까 라는 생각이 듭니다.
TDD에서 디자인패턴
객체를 적용해서 계산을 조직화하는 것은, 내부 생성된 공통적이고 부차적인 문제(subproblem)들을 역시 공통적이고 예측 가능한 방법들로 해결하는 가장 좋은 예 중 하나가 된다. 디자인 패턴의 엄청난 성공은 객체 프로그래머들이 보는 공통성에 대한 증거다. 하지만 'Design Pattern'이라는 책의 성공은 이런 패턴들을 표현하는 어떠한 다양성도 모두 억압하고 말았다. 이 책(Design Pattern)은 설계를 독립된 단계로 바라보는 성향을 어렴풋이 띤다. 이 책(Design Pattern)은 확실히 리팩토링을 설계의 일종으로 보는 것에 동의하지 않는다. TDD에서는 설계를 디자인 패턴과는 조금 다른 관점으로 본다.
프로그래밍을 공부하다보면 자연스럽게 접하는 개념이 OOP(Object-Oriented Programming)과 Design Pattern입니다.
하지만 개인적으로 두 개념을 이해하고 실무에 적용하는 것이 쉽지 않은 과정이라고 느껴왔습니다. 왜냐하면 개념적인 설명과 현실의 문제를 대응하는 과정이 실질적으로 와닿게 느껴지지 않았기 때문이라고 생각합니다.
그러나 TDD의 예제를 따라오면서 느꼈던 부분은, 실질적인 객체의 경계와 역할이 자연스럽게 필요에 의해서 정의되어 간다는 것이 느껴졌고, 지금 가지고 있는 작은 중복의 문제를 해결하기 위해서 design pattern을 자연스럽게 적용해가는 과정이 좀 더 현실적이고 실질적이라고 느껴졌습니다.
커멘드
간단한 메서드 호출보다 복잡한 형태의 계산 작업에 대한 호출이 필요하다면 어떻게 해야 할까?
OOP의 아버지 앨런 케이(Alan kay)는 객체지향 프로그램의 가장 중요한 아이디어는 클래스나 상속, 객체가 아니라 메시지 보내기라고 말한 적이 있습니다.
객체의 함수 호출에 대한 의미를 다른 관점에서 해석해볼 수 있는 문장입니다.
객체의 함수를 정의한다는 것을, 저는 함수를 사용하는 인터페이스를 정의한다 라는 추상적인 개념으로 이해하고 있는데요.
이를 메시지라는 개념으로 바라보니 객체간 관계를 맺음에 있어 메시지를 주고 받는다는 개념을 구현하는 가장 쉬운 방법이 함수 호출이라는 생각으로 다가왔습니다.
더하여 OOP에서 강조하는 객체간 loose coupling을 달성할 수 있는 가장 근본적인 개념이 객체와 메시지를 분리하는 것이 아닌가라는 추측을 해봅니다.
값 객체
2장 타락한 객체
처음 책을 읽기 시작하면서 빠르게 인상깊게 다가왔던 내용이 타락한 객체였습니다. (값 객체 패턴(value object pattern))
널리 공유해야 하지만 동일성(identity)은 중요하지 않을 때 객체를 어떤식으로 설계할 수 있을까?
참조하고 있는 객체의 상태 변화로 인해 나타나는 별칭 문제(aliasing problem) 를 객체 에서 시간에 흐름에 따라 변할 수 있는 상태를 제거하여 불변의 값 객체를 사용하면 비용 측면에서 비효율성은 발생할 수 있을지라도 코드 가독성을 높이고 디버깅의 난이도를 줄이는 장점을 가져갈 수 있다는 것입니다.
이러한 상태 변경에 따른 불확실성에 대한 문제를 해결하기 위해 언어적으로 불변(immutable) 객체를 지원합니다. 자바에서는 14부터 record라는 data class를 지원하기 때문에 LTS(Long Term Support) 버전인 17부터 안정적으로 사용할 수 있습니다.
널 객체
영국의 컴퓨터 과학자이자 퀵 정렬을 고안한 것으로 유명한 Tony Hoare 가 2009년 소프트웨어 컨퍼런스에서 null reference를 발명한 것은 billion-dollar mistake 라고 표현했을 정도로 java에서 null pointer는 다루기 까다로운 문제 중 하나입니다.
필자 또한 Java에서 NullPointerExceptions을 예방하는 방법 (feat. Optional) 을 작성했을 정도로 자바 개발자라면 한번쯤 고민해볼법한 문제이기도 합니다.
객체의 특별한 상황을 표현하고자 할 때 어떻게 해야 할까?
Null object pattern 으로 널 상태를 가진 객체를 활용하면 코딩의 난이도가 줄어든다고 가이드 합니다.
템플릿 메서드
Template method pattern은 제가 동일한 행동 순서를 가진 다양한 특성을 나타내고자 할 때 주로 사용하는 패턴입니다.
주로 strategy pattern과 비교가 많이 되는데요. 저 스스로 이해하기 편한 template method pattern을 사용하고 있습니다.
작업 순서는 변하지 않지만 각 작업 단위에 대한 미래의 개선 가능성을 열어두고 싶은 경우 이를 어떻게 표현할 것인가?
앞서 언급한 내용과 같이 순서를 보장하면서 각 작업 단위에는 변화를 주고 싶은 경우에 사용합니다.
TDD를 접하기 전에는 직관에 의해 순서와 각 작업이 가지는 개성이 나타난다면 설계 단계에서 template method pattern을 적용했는데요.
템플릿 메서드는 초기의 설계에 의해서 얻어지는 것보다는 경험에 의해 발견되는 것이 좋다.
설계에 의해 얻어지는 것보다는 경험에 의해 발견되는 것이 좋다고 가이드합니다.
플러거블 객체
변이를 어떻게 표현할 것인가?
객체의 변형에 따른 조건문의 표현은 빠른 속도로 중복을 만들어 냅니다.
if (circle) then {
... circley stuff.
} else {
... non circley stuff.
}이러한 조건문을 두 번째로 볼 때가 바로, 객체 설계시 가장 기초적인 플러거블 객체를 끄집어낼 때입니다.
if (circle) then {
circle = new Circle();
} else {
circle = new NonCircle();
}
circle stuff.단순히 중복을 제거하기 위해 얻은 플러거블 객체는 종종 반직관적입니다.
플러거블 셀렉터
인스턴스별로 서로 다른 메서드가 동적으로 호출되게 하려면 어떻게 할까?
큰 변이를 다루기 위해서라면 상속을 사용하여 서로 다른 특징을 구현하면 되겠지만 작은 변이를 다루기에는 너무 무거운 기법입니다.
따라서 작은 변이를 위한 동적 호출 방식은 하나의 클래스로 만든 후 리플랙션을 이용하여 동적 메서드를 호출하는 방법입니다.
팩토리 메서드
개 객체를 만들 때 유연성을 원하는 경우 객체를 어떻게 생성하는가?
일반적으로 객체를 생성할 때는 생성자를 사용하면 되지만 자바에서 생성자는 유연함과 표현력이 떨어집니다.
이 때, 팩토리 메서드를 사용하여 유연한 표현력을 얻을 수 있습니다. 다만 사용자가 이 존재를 알 수 있도록 명시해야하는 번거로움이 존재합니다.
관련 내용은 백기선님의 이펙티브 자바 완주 후기벽 공략 1부 완주 후기 (feat. Inflearn) 의 한 부분으로 기록되어 있습니다.
임포스터 (사칭 사기꾼)
기존의 코드에 새로운 변이를 도입하려면 어떻게 해야 할까?
TDD에서의 설명은 다형성을 사용한다로 이해가 되는데 책속의 맥락에서는 사기꾼을 의미합니다. 어떤 것을 말하고 싶은지 잘 이해가 되지 않습니다.
예시로 널 객체와 컴포지트 를 제시하고 있는데요. 필요에 의해 개념적으로는 맞지 않지만 변이가 기존 코드에 주는 영향도를 낮추기 위해 사용하는 것으로 이해하는 되는지 모르겠습니다.
컴포지트
하나의 객체가 다른 객체 목록의 행위를 조합한 것처럼 행동하게 만들려면 어떻게 해야 할까?
객체 집합을 나타내는 객체를 단일 객체에 대한 임포스터로 구현합니다.
수집 매개 변수
여러 객체에 걸쳐 존재하는 오퍼레이션의 결과를 수집하려면 어떻게 해야할까?
결과가 수집될 객체를 각 오퍼레이션의 매개 변수로 추가합니다.
싱글톤
전역 변수를 제공하지 않는 언어에서 전역 변수를 사용하려면 어떻게 해야 할까?
사용하지 마세요.
TDD에서 리팩토링
리펙토링시 관측상의 동치성 이 성립되려면 충분한 테스트를 가지고 있어야 합니다.
여기서 관측상의 동치성이란 테스트에 기반하여 의미론이 유지되는 것을 의미하고, 충분한 테스트란 추측 가능한 모든 테스트를 의미한다.
개인적으로 추측 가능한 모든 테스트의 범위가 모호하게 다가왔습니다. 가령 입력 변수에 integer형이 존재한다면 –2,147,483,648 ~ 2,147,483,647까지 테스트 케이스를 만들어야 하는가? 라는 의문이 들기 때문입니다.
차이점 일치시키기
비슷해 보이는 두 코드 조각을 합치려면 어떻게 해야 할까?
두 코드 조각이 단계적으로 닮아가게끔 수정하여 결국 완전히 동일해지면 둘을 합칩니다.
변화 격리하기
객체나 메서드의 일부만 바꾸려면 어떻게 해야 할까?
수술시 수술부위만 노출하는 것과 같이 바꾸어야할 부분만 격리합니다.
격리를 위한 방법으로는 메서드 추출하기, 객체 추출하기, 메서드 객체 등이 있습니다.
데이터 이주시키기
표현 양식을 변경하려면 어떻게 해야 할까?
일시적으로 데이터 중복을 허용하여 기존 포맷을 사용하는 부분에 새로운 포맷을 사용하도록 중복 시키고 기존 포맷을 제거하는 방식입니다.
메서드 추출하기
길고 복잡한 메서드를 읽기 쉽게 만들려면 어떻게 할까?
긴 메서드의 일부분을 별도의 메서드로 분리해내고 이를 호출한다.
메서드 인라인
너무 꼬여있거나 산재한 제어 흐름을 단순화하려면 어떻게 할까?
호출받은 메서드의 내용을 호출하는 메서드의 본문으로 교체합니다. 이 활동은 제어 흐름을 다양한 시각에서 봄으로 인해서 통찰을 얻는 방식입니다.
인터페이스 추출하기
자바 오퍼레이션에 대한 두 번째 구현을 추가하려면 어떻게 해야 할까?
공통되는 오퍼레이션을 담고 있는 인터페이스를 만들면 됩니다.
메서드 옮기기
메서드를 원래 있어야 할 장소로 옮기려면 어떻게 해야 할까?
한 메서드에서 다른 객체에 두 개 이상의 메시지를 보내는 것을 보면 kent beck은 의심을 한다고 합니다. 그리고 메시지를 받는 객체로 메서드를 옮긴다고 합니다.
이렇게 하면 코드에 대한 깊은 이해가 없더라도 언제 이 리팩토링이 필요한지 쉽게 알아낼 수 있습니다.
메서드 객체
여러 개의 매개 변수와 지역 변수를 갖는 복잡한 메서드를 어떻게 표현할까?
간혹 한 단위의 코드가 여러 개의 임시 변수와 매개 변수들로 얽혀있어서 이 부분을 추출하려고 할 때마다 서명부가 너무 길기 때문에 원래의 코드보다 좋아지지 않을 수 있습니다.
이 때 매서드 객체를 생성하면 아무 것도 전달할 필요가 없는 새로운 이름공간을 얻게 됩니다.
매개 변수 추가
메서드에 매개 변수를 추가하려면?
메서드에 매개 변수를 추가하고 컴파일 에러를 활용합니다.
메서드 매개 변수를 생성자 매개 변수로 바꾸기
하나 이상의 메서드에 매개 변수를 생성자로 옮기려면 어떻게 할까?
해당 행위는 동일한 매개 변수를 가지는 같은 객체의 서로 다른 몇몇 메서드로 전달하는 경우 한 번만 전달 할 수 있도록 API를 단순화 할 수 있습니다.
이름을 테스트 주도 개발이라고 한 이유는?
주도한다(driven) 라는 단어를 받아들이는데 힘든 시간이 있었습니다.
표준국어대사전에는 다음과 같은 해석이 있습니다.
주동적인 처지가 되어 이끌다
테스트가 개발을 이끈다??? 어떻게??? 무슨 의미일까?
글자는 읽히는데 이해가 되지 않았습니다.
이를 명쾌하게 해석해주신분은 유영모 님입니다.
테스트가 개발을 주도한다는 의미는 테스트 코드를 만드는 행위를 통하여 설계도 정의하고 구현 범위도 정의하며 품질관리도 하게되기 때문에 개발 전반의 행위를 주도하게 된다.
이를 TDD에서 말하는 어휘들로 재해석해보면 다음과 같습니다.
자동화되고 구체적이며 명확한 테스트는 개발의 모든 활동을 구조화하는 기술인데 이 기술을 활용해서 개발 전반에 걸친 활동을 할 수 있도록 주도하는 것이다. (추정이나 상상에 의한 개발을 하지 않는다.)
유영모 님께서 전달해주신 문장이 좀 더 쉽게 이해가가는 문장인거 같습니다.
애자일(Agile)의 모호함
마지막으로 TDD를 읽고 애자일에서 모호했던 설계 활동에 대해 확실한 답을 얻을 수 있었던 경험을 말해보고자 합니다.
애자일을 받아들이면서 가장 어려운 부분이 설계의 시점 및 방식이었습니다.
Big Design Up Front 에 따르면 구현이 시작되기 전에 프로그램의 디자인을 완성합니다.
제가 경험했던 대부분의 개발 환경에서는 WBS라는 일정 표를 만들고 설계 기간 동안 할 수 있는 만큼의 설계를 진행한 후 구현을 수행합니다.
이러한 방식을 기반으로 애자일을 받아들이게 되면 의문이 생깁니다.
설계는 어떻게 어느 시점에 해야하지?
이를 해결하기 위해서 스크럼 전에 설계 기간을 별도로 계획하거나 스토리를 구체화할 때 설계 활동에 시간을 할애하는 방식을 취합니다.
TDD를 읽으면서 설계 활동이라는 것을 바라보는 시각을 변화할 수 있는 계기가 되었습니다.
애자일(Agile)의 완성 (feat. TDD)
애자일을 완성하는 TDD
TDD(Test-Driven Development)를 읽고 나서 크게 시각이 바뀐 부분은 애자일(Agile)에서의 설계 방식입니다.
애자일 매니페스토에는 다음과 같은 활동을 제시합니다.
Working software over comprehensive documentation
제가 가지고 있던 관념중에 하나 또한 설계 활동을 수행한다고 하면 문서라는 산출물(output)을 기대합니다.
또한, 설계 리뷰를 하기로 했다면 산출물(output)을 기반으로 서로의 생각을 공유하는 활동을 합니다. 그나마 실질적인 대화의 도구로 설계를 활용하기 위해 도메인 스토리텔링이라는 방식을 활용하고 있는데요. 어찌되었든 사전 설계 활동의 하나입니다.
하지만, TDD에서는 작고 반복적인 테스트를 통하여 필요한 중복만 제거하여 설계를 확장시켜 나가는 방식을 취합니다. 이는 반복적인 리펙토링이라는 활동을 통해 보장합니다.
이 책(Design Pattern)은 설계를 독립된 단계로 바라보는 성향을 어렴풋이 띈다. 이 책(Design Pattern)은 확실히 리펙토링을 설계의 일종으로 보는 것에 동의하지 않는다. TDD에서는 설계를 디자인 패턴과는 조금 다른 관점으로 본다. p.268
템플릿 메서드는 초기의 설계에 의해서 얻어지는 것보다는 경험에 의해 발견되는 것이 좋다. p.277
TDD에서는 리펙토링을 통해 중복을 제거하는 과정에서 설계의 지속적인 변경을 추구합니다.
이는 앞서 언급한 설계 활동을 독립된 단계로 보지 않고 구현 활동의 일부로 간주합니다. 따라서 설계가 확정되는 순간은 특정 태스크가 완료되어 PR되는 단계라는 뜻입니다.
이로써 애자일에서 모호했던 설계라는 활동이 독립된 단계를 가지지 않고도 구체화될 수 있다는 것을 알 수 있습니다.
샘플 코드
Git 저장소에 화폐 예제와 xUnit 예제를 공유합니다.