XP - 해당되는 글 3건

TDD 를 이용한 클래스 디자인

오늘 Test Driven Development에 대한 한가지 질문을 받았다.

"프로그램이 어떻게 돌아 가는지 만들어 지지도 않았는데 어떻게 테스트부터 작성해요?"

"너무 테스트를 작성하기가 힘들어요!"


난 TDD를 설명하기 보다는 IDE를 열고 TDD를 이용한 간단한 프로그램 개발을 같이 수행했다.

30분 정도의 설명이 곁들여진 짝 프로그래밍으로 그 사람은 어렴풋이 짐작이 간다는 투로 오늘 많이 배운 것 같다고 했다.

그의 질문처럼 제작 되지도 않은 프로그램을 테스트 할 수 있을까?

클래스 조차 생성되지 않았고, 심지어 클래스의 명 조차 정의 되지 않았는데 뭘 테스트 한다는 것 인가?

아마도 프로그램의 실제 제작(구현)에 관한 관점에서 테스트를 생각한다면 불가능하고 비효율적이라고 생각 할 것이다.

하지만 난 다시 질문을 하고 싶다.

'Test Driven Development 구현에 관한 것 일까?'

테스트를 작성한다는 것이 어떤 의미 일까?


Unit Test 먼저 작성 할 때 마다 나의 뇌는 클래스의 구조와 디자인 부분에 대해 집중한다는 것을 느낀다.

테스트를 작성할 때 클래스가 담당해야 하는 인터페이스에 집중 하게 된다.

먼저 나는 테스트 해야 하는 스토리(또는 요구 사항)를 하나 선택 한 후 적당한 클래스의 이름과 인스턴스 이름을 생각한다.

그리고 생각한 이름의 클래스를 생성하는 테스트를 작성한다.


User _myUser = new User();

Assert.IsNotNull(_myUser);


테스트를 수행 한다.

오류가 발생해서 빌드가 안 된다. User 클래스를 찾을 수 없다고 한다.

User 클래스를 만든다. 클래스에 아무것도 구현하지 않는다.


Public Class User{


}


테스트를 수행한다.

오 이제 오류가 없이 빌드 된다. 거기다 녹색 불 재수!


이제 다시 스토리를 본다.

'사용자의 생일이 오늘인지 확인할 수 있어야 합니다'


오늘이 사용자 생일인지 확인해주는 메서드가 필요 하겠군, 메서드 명을 뭐라고 한다.?

그냥 메서드 이름은 'BirthdayCheck'로 할까 ?

아님 'TodayIsBirthdayCheck'로 할까?

두 번째 것이 모호 하지 않고 좋을 것 같다.

테스트를 작성 한다.


_myUser.Birthday = ToDay();

Assert.IsTrue(_myUser.TodayIsBirthdayCheck());


테스트를 수행한다.

젠장! 빌드 오류다. Birthday 프로퍼티를 찾을 수 없다고 한다.


User 클래스로 가서 'Birthday' 프로퍼티를 만든다.


Public DateTime Birthday

{

    Set{

     _birthday = value;

    }

}


다시 테스트 수행 또 오류다.

_birthday 필드를 찾을 수 없다고 한다.

_birthday 필드를 선언한다.


Private DateTime _birthday;


다시 테스트를 수행한다.

지겨운 오류! 이번엔 TodayIsBirthdayCheck() 를 찾을 수 없다고 한다.

User에 TodayIsBirthdayCheck() 메서드를 만든다.


Public bool TodayIsBirthday()

{

    Return null;

}


다시 테스트 오! 이제 빌드 오류는 발생하지 않는다.

하지만 빨간불! 자 여기서 목표는 로직의 완성이 아니다.

빨리 녹색불 을 보는 것 테스트를 통과 하는 것이 우리가 할 일 이다.

그래서 난 그냥 TodayIsBirthday() 메서드에 True를 반환하게 한다.


Public bool TodayIsBirthday()

{

    Return true;

}


다시 테스트

신이여 감사합니다. 통과 다!


여기까지다 여기까지가 TDD의 끝이다.

'사용자의 생일이 오늘인지 확인할 수 있어야 합니다' 스토리에 대한 TDD 가 끝난 것이다.

ㅋㅋㅋ 말도 안 된다고 ?

TDD가 끝난 것이지 프로그램을 만들기 위한 구현이 완전 끝난 것이 아니라는 것을 알기를 바란다.

내가 말하고 싶은 것은 TDD는 구현의 도구가 아니라는 것이다.


이제 가상으로 만든 메서드의 로직을 실제 동작하게 구현 하여야 하며, 그런 중 다른 클래스와 관계를 가지고 작업을 하게 될 것이다.

가령 데이터를 저장소로부터 가져오는 Mapper 클래스나 시간을 나타내는 DateTime 등등 외부와 관계를 맺기 시작하며, 클래스의 내부는 점점 복잡해 지며, 우리는 그런 내부의 복잡함을 관리 하기 위해 리팩토링을 하며, 점진적으로 클래스를 완료해 나갈 것이다.


자! 이제 잘 생각 해보자

내부 구현과 리팩토링을 하기 위해 방금 만들어진 테스트를 변경 할 필요가 있을까?

결코 그런 일은 발생 하지 않는다.

스토리의 요구 사항이 변경 되지 않으면 테스트 셋의 정의 또한 변경 되지 않는 것이다.


아무런 기능을 하지 않지만 이름과 형태의 정의로 테스트 셋이 완료가 되었다.

즉 TDD의 테스트란 외부와 상호 작용을 하는 것의 정의에 대한 검증이다.

공개 인터페이스 디자인에 대한 검증이라고 말 할 수 있다.


우리는 보통 클래스 디자인을 할때 요구사항 정의서를 이용한 클래스다이어그램을 그리는 것을 상상 한다.

클래스다이어그램을 만드는 것이 어떤 행동인가?

요구상항의 요구조건을 수행하는 공개인터페이스에 대한 예측과 정의 아닌가?

그럼 TDD의 테스트 는 무엇인가?

스토리 또는 요구사항에 대한 공개인터페이스의 검증을 작성 하는 것이다.

검증을 작성하기 위해 예측하고 정의 하여야 하니까 이 부분에서 우리는 클래스의 디자인을 수행 하는 것이다.

또한 절대 정적이고 부자연스러운 클래스다이어그램에서 얻을 수 없는 견고한 테스트까지 얻을 수 있으니 클래스를 잘 디자인 하고 만들기 위해서 TDD을 사용할 가치가 충분이 있지 않을까?


'Implementation' 카테고리의 다른 글

프로그래밍 언어의 타입_1.명령형 언어  (1) 2008.11.20
AOP(Aspect Oriented Programing)란?  (0) 2008.03.12
|
blog comments powered by Disqus

eXtreme 프로그래밍 (리팩토링과 기민한 모델링) –인포북- 에서 발취


Q : 소프트웨어 폭주와 실패에 대해서 읽어보면 엄격한 프로젝트 관리와 통제가 위험을 줄여 줄 것 같은데, 실제 그런가?


A : 프로젝트 관리에 대해 좀더 하는 것은 언제나 좋은 일이고 공부를 하다 보면 통제가 중요한 수단이라는 것을 알 수 있을 것이다. 문제는 정확하게 필요한 일과 해결방안을 확실히 알 경우에만 통제가 유효하다는 것이다. 개발자는 항상 개발이 어떤 방향으로 흘러갈지 모른다는 마음가짐을 가져야 한다. 이렇게 되면 우리는 좀더 유연한 사고 방식을 가지게 된다. XP는 형식이나 여러 규제를 없앤 것이 아니고 고객이 사업적 관리를 하고, 개발자들은 좀더 자동화되고 현명한 방법으로 일을 진행하는 것을 요구하는 것이다. 이런 소프트웨어 공학적인 맥락에서 XP가 폭포수 모델보다 더 엄격한 관리를 가한다고 볼 수 있다.

'Environment' 카테고리의 다른 글

우분투 설치  (2) 2008.09.23
KentBeck 간단한 XP 정의  (0) 2007.08.21
17 장 창조이야기  (1) 2007.08.20
|
blog comments powered by Disqus

아래의 문답 내용은 월간 마이크로 소프트웨어 의 2001년 12월 호 KentBeck 과 인터뷰에서 XP를 어떻게 경영진에게 소개 할까에 대한 KentBeck의 답변 입니다.

Q : XP 예컨대 경영자 같은 사람에게 만에 설명한다면 어떻게 하겠습니까. 그런 사람들에게 수년 XP 설명해 왔으니 이제는 '진화된' 간략한 소개를 있을 같군요.

A : 당신이 소프트웨어가 했으면 하는 모든 (우리는 이걸 '스토리'라고 부릅니다) 적을 있다고 상상해 보세요. 각각의 스토리는 신기하게도 구현하는 일주일이면 됩니다(분명 작은 이야기들이겠죠). 만약 20개의 이야기(스토리) 가진 프로젝트가 얼마나 걸릴지 알고 싶다면, 답은 20주입니다. 만약 15 후에 프로젝트가 완료되길 바란다면, 당신은 가장 중요한 열다섯 개의 이야기만 고르면 됩니다. 만약 유의미한 열다섯 개의 이야기를 추려낼 없다면 당신은 지금 당장 프로젝트를 취소하는 좋을 겁니다(아니면 기적을 바라며 기도하든지요).

1주일에 한번씩 당신은 구현할 이야기 하나를 선택합니다. 1주일에 한번씩 당신은 주의 이야기와 동시에 이전의 이야기 모두를 포함하는, 출하 가능한 완전한 시스템을 얻게 됩니다. 만약 6 후에 새로운 이야기를 발견한다면, 당신은 얼마든지 다음주의 이야기로 그것을 선택할 있습니다만, 다른 이야기 하나는 구현될 없다는 것을 기억하세요.

12 후에 출하할 것을 결정한다면, 당신은 가장 중요한 열두 개의 이야기가 구현될 것을 보장 받습니다. 당신은 나머지 모든 것은 중요하다고 결정한 것이죠.

'Environment' 카테고리의 다른 글

우분투 설치  (2) 2008.09.23
XP의 통제  (0) 2007.08.22
17 장 창조이야기  (1) 2007.08.20
|
blog comments powered by Disqus

matrim's Blog is powered by Daum & tistory