'TDD'에 해당되는 글 8건

  1. 2009.02.14 오늘 발표한 TDD, 페어프로그래밍 발표자료 링크합니다. 4
  2. 2009.02.11 저도 야구 게임 리뷰 요청합니다. 4
  3. 2009.02.04 세 번째 퀴즈 입니다. 볼링 게임~
  4. 2009.01.21 퀴즈 프로젝트 이름 규약 8
  5. 2009.01.15 코드 리뷰 해주세요~ 4
  6. 2009.01.06 퀴즈 풀 때 주의 할 것 16
  7. 2009.01.05 TDD 퀴즈 1. 비디오 샵 7
  8. 2008.11.21 3기 스터디 제안 - TDD 6
2009. 2. 14. 23:17

오늘 발표한 TDD, 페어프로그래밍 발표자료 링크합니다.


참고하세요~

TDD
http://mercu.tistory.com/5

페어프로그래밍
http://mercu.tistory.com/4
2009. 2. 11. 19:53

저도 야구 게임 리뷰 요청합니다.

keesun/KeesunBaseballGame 프로젝트 입니다.

지난 번에 여자친구랑 같이 페어 했던 코드에서 조금 만 추가했습니다. 막상 해보니까 30분 정도로 마무리 됐는데 그 동안 미루다 미루다 이제 겨우 올리네요. 아무래도 좀 나태해진것 같습니다. @_@ 큰일이네요.

스터디에는 잘하면 늦지 않을 것 같은데 혹시라도 늦으면 친척 결혼식에 다녀오느라 늦는 것이오니 성윤이 진행에 따라주세요~


2009. 2. 4. 20:50

세 번째 퀴즈 입니다. 볼링 게임~

목표

볼링점수를 계산하는 프로그램을 작성

볼링점수계산

계산법참고

  • Stike인 경우는 다음 두번 투구수의 점수를 합한다. 따라서 이후 두번 더 투구할 때까지 strike한 프레임의 점수는 계산되지 않는다.
  • Spare인 경우는 다음 한번 투구스의 점수를 합한다. 따라서 이후 한번 더 투구할 때까지 spare한 프레임의 점수는 계산되지 않는다.
  • 마지막 프레임의 경우는 위의 두가지 조건을 만족하기 위해서 Stike이면 2번, Spare면 한번의 투구가 가능하다.

요구사항

  • 볼링게임(BowlingGame)클래스의 인스턴스를 만들면 새 게임이 시작한 것으로 간주한다.(명시적인 start는 필요없음)
  • 현재 몇번째 프레임의 몇번째 투구(첫번~세번째)를 할 차례인 조회해 볼 수 있다. 게임이 끝났으면 GameOverException을 던진다.
    (Frame번호 + 그 프레임의 시도횟수)
  • 현재까지 진행된 프레임결과와 각 프레임 점수를 보여준다. 확정되지 않은 점수는 표시하지 않아도 된다.
    결과는 현재프레임을 포함해서 진행한 프레임(Frame)갯수만큼의 리스트를 리턴하도록 한다.
    각 프레임에는 프레임번호와 결과스트링(X/-1~9)과 그 프레임의 점수를 돌려준다.

ex)
Frame(1, 08, 8)
Frame(2, X, 15)
Frame(3, 5-, 5)
...
Frame(10, XXX, 30)

기호)
Stike : X
Spare : /
Gutter: -
그외 : 0~9

  • 한번 투구를 하는 메소드(roll)를 만들고 쓰러뜨린 핀의 수를 파라메터로 넘긴다. 게임이 끝났으면 GameOverException을 던진다.
2009. 1. 21. 09:22

퀴즈 프로젝트 이름 규약

보통 프로젝트 이름이 비슷 비슷해서 여러 프로젝트를 체크 아웃 받을 때 조금 번거로웠습니다.

접두어로 자기 ID를 붙이는것이 어떨지 생각해봤습니다.

keesunBaseballGame 이런 형태가 되겠죠.

ㅇㅋ?
2009. 1. 15. 10:52

코드 리뷰 해주세요~


밑줄 그어진 폴더를 열고 프로젝트를 확인해주세요.

아직 시간은 좀 남아있습니다. 오늘(목), 내일(금), 모래(토) 오전.. 그 전에 써니님 코드가 올라올지 기대되는데요~ 금요일 밤까지 올려주시면 토요일 오전에 리뷰하고 가겠습니다. ^^

그전까지 하루에 3~4 개씩 보면 되겠네요. 이야~ 드뎌 다른 분들 코드를 볼 수 있어서 얼마나 신나는지 모릅니다. 같은 문제를 두고 다른 사람은 어떻게 생각하고 어떻게 코딩했을지 궁금하지 않으세요? 캬캬캬
2009. 1. 6. 09:46

퀴즈 풀 때 주의 할 것

1. task 먼저 작성할 것.

- 미리 자신이 테스트 하고자 하는 것을 한 문장으로 작성하세요. 그걸로 작업 단위를 조절할 수 있습니다. 미리 모든 task를 정리하진 않으셔도 됩니다. 조금씩 계속 점진적으로 수정하고 추가해 나가세요.

- 퀴즈에 있는 요구 사항이 task로 1:1로 맵핑 되진 않습니다. 각자가 요구 사항을 읽고 자신만의 task를 만들어 보세요.

2. 절대로 머리속으로 미리 설계하지 않는다.

- 테스트를 성공시키기 위한 코드만 작성하세요. 그리고나서 리팩터링을 하다보면 자연스럽게 멋진 설계가 나온다나... 어쩐다나~

- 그래야 TDD의 묘미를 맛 볼 수 있다고 하네요. 아마 이 것이 가장 힘든 일이 아닌가 싶습니다. 기존에 경험이 많으신 분들은 딱 보면 딱 뭔가 떠오르기 때문에.. 생각을 많이 하지 않는 연습이 필요할 것 같습니다.

3. 한 task가 끝나면 커밋한다.

- 그래야 과정을 볼 수 있습니다. 중간 중간 어떤 단위로 작업을 했는지 코드가 어떤 식으로 발전했는지 말이죠. 물론 더 세세하게 커밋을 해도 됩니다. 테스트 코드만 작성한 다음 커밋한다던지.. 리팩터링 하기 전이랑 후의 코드를 볼 수 있게 커밋한다던지..

- 어쨋든 최소한 한 task 마다 커밋 한 번은 꼭 해주세요.

4. 퀴즈를 여러번 풀어보세요.

- 매번 비슷하지만 약간 다른 코드가 나오거나 전혀 다른 코드가 나올 수도 있습니다. 피드백을 받은 다음에 다시 해봐도 좋지만 그 전에도 여러번 해보면 해볼 수록 새로운 맛을 느낄 수 있을 겁니다.

5. 퀴즈를 다 풀었다!

- 글을 올려주세요. 요즘 댓글이 너무 많이 달려서 댓글을 다 챙겨보기가 힘듭니다. 아예 새로운 글을 올려서 자신이 어떤 퀴즈를 풀었으며 느낌이 어땠는지 저장소 주소가 어떻게 되며 프로젝트 이름은 무엇인지 프로젝트 빌드에 필요한 정보가 있다면 그런 정보도 알려주시면 좋겠죠?(메이븐 프로젝트라면 메이븐이 필요하다고 알려주시구요. 프로젝트에서 사용한 인코딩이 무엇인지 UTF-8인지 EUC-KR인지. 등등)


2009. 1. 5. 09:34

TDD 퀴즈 1. 비디오 샵

목적

비디오방에서 고객이 대여하는 비디오의 대여정보를 조회할 수 있는 프로그램을 작성

요구사항

  • 고객(Customer)은 이름을 가지고 있다.
  • 고객은 한번에 여러개의 비디오를 대여할 수 있으나 각각의 대여(Rental)기간은 다를 수 있다.
  • 비디오(Video)는 영화,스포츠,다큐멘타리의 세종류가 있다.
  • 각각의 비디오는 독립적인 일일 대여요금을 가지고 있다.
  • 영화는 대여기간이 2일 이상되면 3일째 부터는 대여요금이 1/2로 할인된다.
  • 다큐멘타리는 3일 이상 대여하면 4일째 부터는 1/3로 할인된다.
  • 스포츠는 장기대여 할인이 없다.
  • 비디오 1개 대여할 때 마다 보너스포인트는 1포인트씩 올라간다. 단, 스포츠는 2포인트씩 올라간다.
  • 과거의 대여기록을 가지고 있을 필요는 없으나 고객이 얻은 총 보너스 포인트 정보는 알고 있어야 한다.
  • 고객(Customer)의 현재 대여정보를 구할 수 있는 기능을 작성하라
    • 총 대여비디오 수
    • 대여정보: 비디오(종류 + 제목 + 가격), 대여기간 리스트
    • 총대여가격
    • 현재 대여하고 있는 비디오로 인해서 추가된 포인트수

조건

  • 예외상황에 대한 처리는 필요없다.
  • 반드시 TDD의 순서에 따라서 작업할 것
  • 테스트할 목록을 직접 정의한다(txt파일에 정리할 것)
  • 한개의 테스트 메소드 작업이 끝날때마다 commit하도록 한다. 이때 테스트 목록에서 작업한 내용은 체크해서 올린다.



2008. 11. 21. 09:37

3기 스터디 제안 - TDD

2기 스터디를 연장할 것이냐. 정리하고 다음 주제로 넘어갈 것이냐. 고민의 기로에 서있습니다. 저희가 목표로 삼은 것은 "페이지 처리가 가능한 게시판" 입니다. 그 이 외의 주제(로그인, 정렬. 댓글, 태그, 덩덩덩)는 번외로 다루기로 했습니다. 목적은 스프링 활용법에 익숙해 지자는 것이었죠.

아마 아직 두 번이나 남았으니까 충분히 기능 구현하는데 일정상 무리는 없을 것으로 생각합니다. 대신 기능 구현 이외에 "테스트를 어떻게 할 것인지?", "어떤 구조로 설계 해야 하는지?", "스프링 2쩜 대에서는 어떻게 구현했는지?", "스트럿츠와 iBatis로는 어떻게 했는지?". "인터셉터를 어디서 어떤 용도로 사용했는지?" 등등을 보느 재미가 쏠쏠해서 스터디를 계속 이어가고 싶어집니다.

하지만 그렇게 계속 이어 나가다 보면 끝이 없을 것같고 스터디도 자칫 루즈 해지기 마련이니까, 원래 계획대로 스터디를 끝내고 차기 스터디를 진행하면 좋겠습니다.

오늘 아침 토비님의 글 알면서 왜 안할까? TDD를 보면서 든 생각인데, TDD 연습을 해보는 건 어떨까요? 예전에 사부님한테 볼링 점수 계산이나, 양파 껍질 까기 같은 TDD 훈련을 받을 적이 있는데 정말 재밌었습니다. 단순하게 재미만 있었던게 아니라 "어떤걸 테스트 해야 하는지", "테스트를 어떻게 만들것인지" 에 대해 많은 고민을 하게 되고 그런 것에 익숙해지면 실전 개발에서도 TDD까진 아니여도 개발 후에 테스트 코드를 작성할 때 유용하게 써먹을 수 있었습니다.

스터디 방식은 각자가 동일한 문제를 TDD로 풀어오고 코드를 비교해 보는거죠. TDD를 훈련을 하기 전에 필독서로 "Test Driven Development(테스트 주도 개발)"를 반드시 읽기로 하고(금방 읽습니다. 실습까지 하면서 해도 후딱..), 스터디를 하면서는 xUnit Patterns나 JUnit Recipe를 보면서 테스트 기법들을 개인적으로 학습하시다 보면 많은 도움이 될 것 같습니다.

어떤가요? 재밌겠죠? ㅋㅋ 의견을 주세요. 전 청소하러 갑니다~