손경욱

UserPreferences

• http://wiki.hailydaily.net
  
• http://wiki.hailydaily.net/wiki.php/TestDrivenDevelopment
  

XP에는 고객에 대한 명시적인 고려가 없다. 내가 고객일 때는 어떻게 해야 될까? 고객에게도 문서가 필요없을까? 고객의 대표는 어떻게 고객을 대표하는 것일까?

테스트들을 자동화하는데 드는 시간은? 리팩토링하는데 드는 시간은? 각각을 UserStory로 만들어야 하나? UserStory 없이도 시간 분배가 가능한가?

UserStory로 팀 속도를 측정한다면, UserStory로 만들 수 없는 작은 일은 누락되는가? 틈틈이 하는가?

두 개의 UserStory가 있었는데, UserStory #1을 작업하면서 UserStory #2까지 만족시켰다면 이 팀은 이번 이터레이션에서 두 개의 UserStory를 한 것일까 아닐까? 팀 속도는 1일까 2일까?

스토리의 크기를 잘 측정했다고 가정하면 예상보다 빨리 작업을 한 것이고 이러한 속도의 변화가 팀 속도에 반영이 되어야 한다. 만약 스토리 크기의 측정 실패라면 UserStory #2의 내용을 UserStory #1에 옮겨 적고 찢어버린다.

TDD

일단, 테스트를 하는 이상, 테스트가 성공한 경우 반드시 결과에 대한 보장이 있어야 할 것입니다. 그런데 랜덤 값의 보장이란 어렵다고 생각합니다. 0부터 100 사이의 값이 나와야 한다는 조건이 있을 때, 100번 성공했다고 해서 조건이 만족되었다고 보기가 어렵습니다. 검사를 충분히 많이 하면 그 숫자만큼 통계적인 확신을 가질 수야 있겠지만, 그것이 보장이 될 수는 없지 않을까요? 오늘 테스트했을 때는 성공했는데, 내일 테스트했을 때는 실패하는 테스트는 테스트라고 할 수 없을 겁니다.

글을 쓰고 잠깐 생각을 해보았는데, TDD 전문가들 사이에서는 이미 랜덤을 테스트하는 패턴이 있지 않을까 싶어요. 예를 들면 보통 사용하는 랜덤 제너레이터가 있고 테스트용으로 사용하는 랜덤 제너레이터 MockObject가 있어서, MockObject는 실제 랜덤 값을 돌려주는 대신 최소값과 최대값만 돌려주는 식이죠. 어떨까요? -- 손경욱

저도 말씀하신 방법대로 pseudo random generator 를 만들어 쓴 적도 있긴 합니다. list 안에 있는 item 에 대해서 렌덤 선택을 하여 일부를 꺼내는 방식인데, 그 경우 pseudo random generator 를 이용해서 꺼낼 item 값들을 만들고 진행을 한 적이 있습니다. 또 다른 방법으로, random 자체에 대한 테스트 대신, random 중 '적절한 값' 혹은 '적절치 못한 값'을 '이미 꺼내었다' 가정하고, 그에 따른 로직 처리에 대해 UT 를 만들었었습니다. 특별한 문제가 없을 때 후자의 방법이 더 좋았던 것 같습니다.
또한, Database 에서의 auto-increment ID를 이용하는 경우나, DB 에서 DB SQL 문으로 저장하는 등록날짜 문제에서 비슷한 경우의 문제를 겪었었습니다. 그리고, 이 테스트를 작성할때 '이 테스트는 UT Coverage 를 높이기 위해서이고, Design 을 위한 방법은 아닐 것 같다'는 고민을 한 적이 있습니다. 다른 사람들의 의견이 궁금하네요. --강석천

후자의 방법도 좋습니다. 그런데 그것은 기능이 예외 처리에 안전하느냐에 대한 테스트에 사용할 방법이라고 생각합니다. 만약에 1과 5를 넣으면 2에서 6 사이의 값을 반환해야 하는 메쏘드가 있다고 칩시다. 아마 인자에 +1을 해서 사이의 무작위 값을 반환하는 메쏘드겠지요. 이 메쏘드가 사용하는 랜덤 제너레이터는 이미 다른 곳에서 테스트가 되었거나 아니면 테스트할 필요가 없는 기능일 것입니다. (예를 들어 built-in) 그러면 우리가 해야할 일은 반환값이 2와 6 사이의 값인가를 검사하는 것입니다. 적절한 값인 4와 적절치 못한 값인 1로 테스트할 수 있는 종류의 문제가 아닌 것이죠.

말씀하신 것은 '범위'라는 개념으로 묶었을 때 input 대비 output가 명확해보이는 경우 같습니다. --강석천

글을 주고 받으면서 정리하다보니 랜덤 이슈가 한 종류가 아닌 것 같습니다. 그러니까 제가 적절치 않은 질문을 한 것이네요. 이제 제가 궁금한 것은 "TestDrivenDevelopment에서의 몇 가지 랜덤 이슈들" 정도로 요약할 수 있겠습니다. -- 손경욱

저라면 '오늘날짜'의 경우 API 로 친다면 GetLocalTime? 과 같은 '안정된 API 호출을 통해 얻어오는 값'이므로 '오늘날짜가 제대로 들어오는지' 에 대한 테스트를 작성하지 않고 진행할 겁니다. 그러다가 거기에 indirection 을 두고 싶다면 (무언가 오늘날짜를 sink 하기 위해서 특정 서버로부터 날짜를 일괄적으로 가져오는 식의 기능이 필요한 경우) ICalendar? 와 MockCalendar? 와 같은 indirection 을 두고 늘 예측가능한 날짜를 가져오는 부분에 대해 구현을 추가합니다.

Dear 손경욱