These are my links for October 15th through October 19th:

• Jeff Offutt home page –
• Gojko Adzic » Mocks are not about isolation, but about responsibilities – 인터페이스는 호출할 메소드만을 나타내기 때문에 객체를 명세하는데 충분하지 않다. 언제 어떻게 호출하는지는 알려주지 않는다. 그래서 목 객체가 필요한 것이다.
• 애플 아이맥 분해 ( Apple iMac Teardown ) – BLOG by TONYSTYLE –
• 애플과 출판업의 미래 1/2 – AppleForum –
• Lim,GeunSik(invain)’s Blog world :: 2009 LLVM Developer Meeting – 향후 대부분은 LLVM으로 갈 것 같다.
• Visual Presentation – 시각적 프리젠테이션 –
• EclEmma – Java Code Coverage for Eclipse – 이클립스에서 코드 커버리지 측정하는데 좋은 녀석…
• TEDxSeoul – 희망과 아이디어는 전염됩니다 – 희망과 아이디어는 전염된다… 좋다…
• paperinz™ 특정 키워드가 포함된 트위터의 글을 이메일로 받아보기 – tweetalarm – 마케팅이나 기업 트위터들이 사용하면 좋을 듯 하다.
• 한국 developerWorks : developerWorks Column : 교육과 애자일, Part 2: 변화에 대한 책임 –

Related posts:

1. Bookmarks for October 19th through October 23rd
2. Bookmarks for October 15th from 14:06 to 14:06
3. Bookmarks for October 14th through October 15th

TestCrunch에 올라온  “테스트는 누가해야 하는가?”에 대한 트랙백을 위한 글 입니다.

Nikkei Electronics 2007년 4월 23일 자에 나온 “공들여 만드는 소프트웨어, 검증하기 쉬운 설계로“라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다.

” 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!”
- 테스터

아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다.

“아니 이렇게 생산하기 어렵게 설계하면 어떻게 해요!”
- 생산담당자

생산하기 힘드니 다시 설계하라는 이야기를 하는 곳은 있을 수도 있을 겁니다.
생산을 고려해서 설계를하고 개발하라는 것입니다.

Application/Game 개발자분들은… 디자이너분들과 이런 이야기 자주 나누지 않습니까?

“이런 디자인/컨셉은 개발하기 힘들다… 당신들이 개발을 안해봐서 그런가 본데… 이건 너무 힘들어요…”
- 개발자

테스트도 개발의 한 부분이고 중요하다는 것을 개발자가 더 잘 알고 있을 것입니다.
그러나 오랜 관습과 바쁘다는 현실에서 변화하기가 쉽지 않은 것 같습니다.

개발자 테스트하면 자주 등장하는 TDD는 테스트보다는 Design적인 측면이 더 중요하게 생각되는 것 같습니다.
Test Driven Development 보다는 Design의 의미가 강하다고 생각됩니다.
TDD에 의해서 모든 테스트가 끝나지 않습니다. TDD는 품질에 대한 최소한의 요구사항이라고 생각합니다.

“Clean code that works!"- Test Driven Devlopment 에서 Kent Bect

TDD는 분석/설계 도구이지 테스트 도구가 아닙니다. TDD를 통해서 얻는 Code Coverage는 TDD의 목적이 아니라고 생각됩니다. 부수적인 이득이라고 봐야겠죠.
TDD의 궁극의 목적은 “Clean Code That Works”라고 봅니다.

테스트를 위하여 API 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.

Related posts:

1. Test-Driven Development, A Year Later
2. 게임 업계에서의 Agile과 TDD
3. 테스터가 바라본 크롬(Chrome)

어제 SQE 업무를 함께하고 있는 팀원들과 이런 저런 이야기를 하다가 TDD가 진짜로 필요한지에 대한 논의(논쟁?)을 잠시 했다. 그 중에는 개발 경험이 많은 친구도 있었고 그렇지 않은 친구도 있었다.
 - 필요하다.
 - 필요없다.
 - 바쁘면 일단 구현하고 나중에 시스템 테스트를 하는 게 더 효율적이다.
 - 정답은 없다. 팀 상황과 능력에 따라 다르다.
이런 내용들이었지만 담배피는 잠깐동안의 이야기였기 때문에 이렇게 정리가 되었다.

우선 나는 어떠한 형식이던지 테스트는 꼭 필요하고 TDD는 그 중 개발팀에서 주도적으로 할 수 있는 훌륭한 것 중의 하나라고 생각한다. 즉, 나는 믿는다. 이제 그 필요성을 사람들에게 느끼기 해 주기 위해서 앞 선 글에서도 이야기했지만 좀 더 깊게 공부와 사례 연구를 해서 Expert가 되고 싶은 거다.

TDD에 대해서 경험에 의한 솔직 담백 글이 있다. 기대도 이야기했지만 이런 변화를 SE, SQE팀에서 주기는 힘든 것 같다. 조금 더 내공을 쌓은 후 개발팀으로 복귀하는 것이 좋겠다는 생각을 다시 한 번 해 본다. 그러나 현재의 팀(SQE)에서도 얻는 것은 많다. 다양한 개발팀을 만날 수 있다는 것이다. 연구 과제, 상품과 과제, 프로세스를 잘 따르는 팀, 마구잡이? 개발 팀 등… 많은 사례를 볼 수 있는 것이 장점이다.

저는 프로그래머가 아닌지라, 제가 직접 TDD를 해본 적은 없습니다. 그저 지속적인 통합으로 인한 혜택들을 누리고 있을 따름이지요.
 - 김기웅님의 “테스트 주도 개발 ,1년째” 중

하지만, TDD 를 하기 위해서 테스트 코드를 짜다보면
‘내가 제대로 이해하지 못한 상태로 필요한 코드를 copy & paste 해서 쓰고 있었구나’ 라는 느낌을 받게 됩니다.
그리고 원하는 부분을 집중 연구해 보기가 훨씬 쉬워집니다.
마치 실험실 속에 가운을 입고 연구하고 있는 듯한 느낌이 들기도 하죠.
그리고 원하는 코드를 break point 걸고 싶을 때도
간단하게 테스트 코드만 추가함으로서 몇 초안에 각 변수들이 실행시점에 어떤 값을 가지는지를 눈으로 직접 확인할 수 있습니다.
 - 박피디님의 “Test-Driven Development, A Year Later” 중

나는 아직 그런 혜택도 못 받았고 그런 경험도 없지만 믿고 더 깊게 파고 들어 봐야겠다.

Related posts:

1. Test 관련 Groups & Blog

평소에 Agile과 TDD에 관심이 많았다.
Agile 중에서는 XP에 대해서 관련 프로젝트도 참여해 보았다. 충분한 가능성을 본 프로젝트이다.
TDD는 김창준 씨도 우리 팀에 오셔서 세미나를 하셨으나 그 당시에 우리 팀의 현실(수준?)에 맞지 않아 실천을 못 했다.
지금도 회사 내 다른 프로젝트에는 TDD를 적용하는 과제도 있을지 모르나 아직 대부분의 PL들은 큰 관심을 두지 못하는 것 같다. 앞선 글에서도 이야기했지만 지금 우리 회사는 변화고 있다. 그것이 느껴진다. 그래서 내가 열심히 해 보려고 하는 이유이다.(아~ 긍정적인 마인드..ㅋㅋ ㅡㅡ;)

Agile 중에 최근에 관심을 두게 된 것이 Scrum이고 TDD는 조금 더 깊게 들어보고 싶어 이리저리 검색을 해 보았다.
나만 몰랐는지는 모르겠지만 게임업계에서  Agile과  TDD 적용 사례에 관한 많은 글이 포스팅되고 있었다.
아래는 그 포스트 중 관심 있게 본 글 들이다.
우리가 회사에도 적용을 위해서는 많은 이들의 공감대와 Best Practice가 필요하다.
회사 블로그에 명준이가 적은 말이 공감된다.

    어떤 방법론을 맹신하는 것은 바보같은 일이다. XP를 해도 실패할 건 실패하고,
    Waterfall 모델로도 성공하는 프로젝트도 있다.

    하지만 만약 유연한 변화 관리 모델과 명시적이고 간단 명료한 성과확인이

    자주 이루어져서, 개발 업무에 도움을 준다면??

    RUP를 경험해본 나로서는 Agile의 간단하면서도 직관적인 추적과 표기법이

    무척 맘에 든다.

- 명준

Agile :
http://mypage.sarang.net/tt/143
마이에트라는 게임 개발사에서 적용한 애자일 방법을 소개함

http://betterways.tistory.com/9
High Moon 스튜디오에서 게임 개발시 애자일 방법을 이용함

http://betterways.tistory.com/183
애자일 게임 개발: 최전선의 이야기(Agile Game Development:Tales from the Trenches)

http://twiny.tistory.com/1654
기민한 방법론을 사용한 게임개발 (Paper Burns: Game Design With Agile Methodologies)

http://betterways.tistory.com/51
실전 애자일 게임 개발 (Agile Game Development From The Trenches)

TDD :
http://betterways.tistory.com/96

Related posts:

1. Test-Driven Development, A Year Later
2. Food For Thought – Agile Musings from the Blogosphere
3. Agile OST 2007