Test drive Development - 해당되는 글 2건

녹색 성장과 소프트웨어


마전의 우리 정부는 연 7% 의 고속 성장 목표에서 환경을 생각하는 녹색성장 정책으로 국가의 정책을 변경하였습니다.

녹색성장이란 저탄소 산업을 육성하여 경제와 산업 성장에 있어서 탄소 연료 소비를 최소화하고 이산화 탄소 등 환경 공해 물질을 억제하여 지구를 환경 파괴로 부터 지키기 위한 산업 성장을 말합니다.

물론 현 정부가 녹색성장의 동력으로 원자력에 의존하는 부분 등 미숙한 부분도 있지만, 심각한 수준에 있는 지구의 환경 파괴 상태를 본다면, 정말 기쁘고 반가운 소식이 아닐 수 없습니다.

TV,인터넷, 라디오, 신문, 잡지, 영화 등 모든 미디어들은 현재의 지구 상태를 매우 심각한 상태로 보고 하며, 우리에게 경고를 주고 있습니다.

하바드, 캠브리지 등 세계의 대학과 그곳의 석학들도 우리에게 심각하게 경고합니다.

하지만 아직 아무도 지구 환경에 대한 긍정적인 영향을 소프트웨어가 큰 부분에 있어 작용한다는 것에 대해서 이야기하지 않는 것 같습니다.

물론 제가 업으로 삼고 있는 것이 소프트웨어 개발이라 좁은 관점에서 사고한 이론인지 모르겠습니다.

하지만 지구의 심각한 문제가 인류가 그동안 사용한 화석 연료로 인한 것이였다면, 현 위기를 벗어날 길은 소프트웨어의 극단적 사용이라고 생각합니다.


류는 산업 혁명 이후 양적 성장과 크기의 확장에만 매달려 왔습니다. 더 많이, 그리고 더 빠르고, 더 높고, 더 무겁고, 더 크고 등 팽창 위주의 성장이였습니다.

아인슈타인의 진리적 이론인 E=MC^2 에 따르면 질량이 무거우면 에너지의 양이 크다, 즉 인류가 그동한 추구한 확장적 성장에 따라 계속 발전한다면 점점 사용하는 에너지의 양은 늘어나며, 지구의 파괴는 더욱 빨리 질 것입니다.

결국 우리는 지금까지의 관습을 모두 버리고 더욱 작고, 더욱 느리고, 더욱 가벼운 축소의 성장을 이루어야 지금의 위기에서 벗어 날 수 있을 것입니다.

축소의 성장에는 너무나 많은 난관이 있습니다. 크게 만드는 것 보다 작게 만드는 것은 너무나 많은 노력이 들어 갑니다. 또 한 물리적으로 사물을 축소한다는 것은 한계가 있습니다.

자동차를 생각해보십시오. 가끔 모토 쇼에 1인승 미래 자동차가 나옵니다. 실제 오토바이 크기 만큼 작은 차들이지요. 그럼 자동차를 그이상 작게 만들려면 가능할까요?

사람도 타야 하고, 엔지도 있어야 하고, 짐도 실어야 하니까 아마 힘들것 같습니다.

그럼 어떻게 탈것을 더욱 축소 시키면서 발전 시킬 수 있을까요?

여기서 우리는 확장적성장의 패러다임을 버려야 합니다. 자동차를 가볍고 작게 만들것이 아니라 자동차의 목적인 이동을 작고 가볍게 만들어야 한다는 생각을 해야 합니다.


10년 사이에 홈쇼핑, 인터넷 쇼핑이 몇 백배 성장하며, 우리의 생활 양식마저 바꿔 놓고 있습니다.

모든게 It기술과 소프트웨어의 눈부신 발전 때문이지요. 그런데 그런점 생각해보셨습니까? 홈쇼핑과 인터넷 쇼핑 때문에 차량 운행량이 얼마나 줄었을까?

과거 홈쇼핑, 인터넷 쇼핑이 아예 없던 시절 우리는 물건을 사기 위해 시장이나, 백화점 등 물건을 판매하는 곳까지 직접 이동하여야 했습니다.

심지어 지역 특삼물이나, 특별한 물건을 사기 위해 몇십 몇백 킬로미터를 이동해야 할때도 있었습니다.

하지만 지금은 어떻습니까? 저의집에서 제주도의 옥돔을 구매할 수 있습니다.

얼마 전에는 수천 킬로미터가 떨어진 미국의 상점에서 책을 주문 했습니다.

만약 그 책을 사기 위해 비행기를 타고 차를 타고 직접 이동했다면 어마어마한 에너지를 사용하여 그 책을 구매한 것이 될 것입니다.

위에서 말한 아인슈타인의 E=MC^2의 법칙으로 생각 해보면 제가 몸무게가 90kg 정도나가고, 위 법칙에 적용받을 수 있는 속도로 이동한다면 에너지의 양은 음....상상을 초월 하는 (참고로 답을 구할 수 있는 분은 구해 보세요 공식은 : E = 90 kg * (3 * 10^8 m/s) ^2) 에너지 양이 나옵니다.

그럼 집에서 그 책을 인터넷을 통해 구매했다고 한다면, 실제 이동한 것은 저희 집에서 미국의 그 상점의 서버까지 연결된 라인을 통해 이동한 전자들 뿐 일 것입니다. 물론 초당 몇 MB 이상씩 이동을 시켜겠지만, 전자의 개당 무게는1 kg * (3 * 10^8 m/s) ^2 이 정도이니 아무리 수많은 전자를 이동시켜 이용했다고 하더라도 사용에너지의 양은 비교가 되지 않습니다.

물론 지금의 말은 검증된 것도 아니고 또 현실적이지도 않습니다. 단순히 아인슈타인의 E=MC^2 이라는 이론을 이용하여 극단적으로 이야기 한 것 뿐입니다.

하지만 우리는 소프트웨어를 사용하므로 기존에 비효율적이었고 낭비의 요소가 많았던 이동을 개선한 것은 사실입니다.

우리 주변에는 이런 것 뿐 아니라 소프트웨어를 이용하여 에너지를 훨씬 작게 사용하여 기존의 방식과 동일한 효과를 보는 일들이 많을 것입니다.


구가 위기에 처해진 것은 분명한 사실 인 것 같습니다. 작년에 충격적이었던 엘고어의 “불편한 진실” 이라는 영화가 생각납니다.

우리에게 불편한 진실이지만, 진실은 진실 입니다. 인류 모두가 힘을 모아 지금의 위기를 슬기롭게 해결 해야 합니다.

여기에 소프트웨어 개발을 담당하고 있는 우리도 역시 동참하여 우리의 힘으로 지구를 구할 수 있는 길을 연구하고 고민하여 위기에 처한 지구를 구하는 일에 힘을 보태어야 할 것 입니다.




|
blog comments powered by Disqus

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

matrim's Blog is powered by Daum & tistory