TDD

1002/Journal . . . . 25 matches
     DDD 하니까 XP 방법론과 잘 맞는다는 말이 생각이 났었고, 그러다가 TDD 생각이 나고, 그러다가 Calvin & Hobbes 가 생각이 나고 (여기까지 한줄기)
     이전에 TDD 할때 초기 Library 클래스에 대해 Mock 클래스 만들었다가 없애버렸는데, 다시 Library Mock 클래스를 만들어야 할 것 같다. 리팩토링 할때 Fail 난 테스트로 리팩토링을 할 수는 없을테니.
     Prometheus 코드를 다시 checkout 하고 UnitTest 깨진 부분을 보면서 기존의 TDD 진행 보폭이 얼마나 컸는지가 보였다. (다시 Green Bar 를 보이게끔 하기에 진행해야 할일이 많았으니까. Extractor Remote Test 가 no matched (정규표현식에서 매칭 실패)로 깨졌을때 생각해야 할 일이 두가지이다. 하나는 HTML 이 제대로 받아졌는가(또는 HTML 이 도서관에서의 에러코드를 반환하는가), 하나는 extractor 가 그 구실을 제대로 하는가. 그런데, 테스트 코드를 보면 저 두가지가 묶여있다.
     그리고 정규표현식을 이용한 extract 가 과연 'The Simplest Thing' 일까라는 생각을 하게 되었다. 올바른 정규표현식을 찾아내야 하고, 그러다보면 데이터 코드와 정규표현식이 일종의 Duplication 을 만들어낸다. (파싱하려는 문서의 일부가 정규표현식에 들어가므로) 그리고 RE 는 RE 문법을 아는 사람이라면 모르겠지만, 그렇지 않고 막연한 경우에 TDD 할 경우 Try and Error 식으로 접근해버릴 수 있다. (나의 경우는 이걸 점진적으로 하기 위해 표본이 되는 데이터를 작게 시작한다.) extract 의 'Simplest Thing' 는 find & substring 일것이란 생각을 해본다.
     Extract 부분에 대해 너무 테스트의 단위가 크다고 판단, 이 부분을 처음부터 다시 TDD로 작성하였다. Bottom Up 스타일로 작은 단위부터 차근차근 진행하였다. 그런데 To Do List 를 작성을 안하니까, 중간에 잠깐 집중도가 풀어졌을때 똑같은 일을 하는 다른 메소드들을 만들어버린 것이다.
     Python 이용. 적당히 TDD 와 중간 UP Front를 섞었다. (CRC와 UML을 이용) 거의 정규표현식이나 find 등을 이용한 스트링 파싱 노가다급이지만, 하루 작업치곤 생각보다 많이 나간 것 같다.
     1차적으로 CRC 를 이용하여 간단한 Conceptual Model 을 만든뒤, TDD 로 개개 모듈을 작업했다.
     중간 개개의 모듈을 통합할때쯤에 이전에 생각해둔 디자인이 제대로 기억이 나지 않았다.; 이때 Sequence Diagram 을 그리면서 프로그램의 흐름을 천천히 생각했다. 어느정도 진행된 바가 있고, 개발하면서 개개별 모듈에 대한 인터페이스들을 정확히 알고 있었기 때문에, Conceptual Model 보다 더 구체적인 Upfront 로 가도 별 무리가 없다고 판단했다. 내가 만든 모듈을 일종의 Spike Solution 처럼 접근하고, 다시 TDD를 들어가고 하니까 중간 망설임 없이 거의 일사천리로 작업하게 되었다.
      * TDD의 테스트들은 마치 모래주머니 같다. 묵직한 느낌을 주면서 프로그래밍 한 것들을 이해하게 하니까. 그리고, 갈수록 느끼는 것이지만, 테스트 없는 리팩토링은 정말 상상하기 어렵다. 요새는 중간중간 테스트를 작성하지 않는 코드들도 이용하고 있다. 조심스럽긴 하지만, 모듈의 복잡도,중요도에 따라 적당히 골라쓸 수 있을 것 같다.
     17, 18 일 (목, 금): TDD 기사 진행.
     16 일 (수): TDDBE 다시 정독. 기사 진행.
     TDDBE를 PowerReading 에서의 방법을 적용해서 읽어보았다. 내가 필요로 하는 부분인 '왜 TDD를 하는가?' 와 'TDD Pattern' 부분에 대해서 했는데, 여전히 접근법은 이해를 위주로 했다. WPM 은 평균 60대. 이해도는 한번은 90% (책을 안보고 요약을 쓸때 대부분의 내용이 기억이 났다.), 한번은 이해도 40%(이때는 사전을 안찾았었다.) 이해도와 속도의 영향은 역시 외국어 실력부분인것 같다. 단어 자체를 모를때, 모르는 문법이 나왔을 경우의 문제는 읽기 방법의 문제가 아닌 것 같다.
     14 일 (월): TDD 기사작성 Start, 일주일 할일 설정.
     이번에는 TDD 로 하되, TDD쪽보다는 PBI 에 더 주안을 두고 했다. 이런 수학공식 구하기 스타일의 문제의 경우는 StepwiseRefinement 와도 같은 PBI가 굉장히 유용하다는 생각이 든다. 첫번째 문제 풀때 코드-테스트-재정의 식으로(중복보다는 재정의에 더 신경썼기 때문에) 넘어가는게 거의 1분을 넘어가지 않았다.
     두번째 문제에 대해서는 ["STL"] 에 익숙하지 않아서 시간이 1시간 18분이 걸렸다. -_-; 앞의 문제가 거의 20분 내에 끝난것에 비하면 꽤 오래걸린 셈인데. 처음 문제 이해는 굉장히 간단했고, 접근 방법도 문제 읽자 마다 2가지 정도가 보였다. 문제는 내가 permutation 을 구하는 알고리즘을 모른다는 것이였고, 직접 만들어야 했다. 뭐 그래도 별로 안어렵겠다 싶어서 TDD 식의 간단한 접근을 해 보았다. (헉, 소스를 학교에 두고 왔군. -_-;)
     역시 접근은 TDD, PBI
     11 일 (금): TDD ClassifyByAnagram, 르네상스 클럽
     아직은 나에겐 '~한 점에서 결국은 다 같다' 라는 말보다는 '~한 점에서 다르다' 란 말로 배울 수 있는게 더 많은 것 같다. 아는 선배는 '결국 SE 의 큰 틀 내에서의 범주로 놓고 보면 RUP나 XP나 같은게 아니냐' 식으로 이야기한다. 나는 XP의 다른점(지극하게 가벼운 곳부터 시작하여 필요할때 테스크나 스토리로서 추가하는)으로 장점을 얻고자 한다. 아는 선배는 TDD로 하건 뭘로 하건 결국 빠르게 좋은 프로그램을 만들면 된다고 한다. 나는 TDD를 끝까지 해봄(디버깅 툴로 돌리는 시간이 거의 0라는 점, 내가 제어할 수 있는 좋은 질문 & 좋은 답을 만들어내기)으로서 장점을 얻고자 한다. 아직까지는 守의 단계이라 생각하기때문에.
     결국 코드를 만들어가면서 '학습된' 코드 - 각 단어의 요소들 sort index 를 만들고 해쉬테이블을 이용하는 식으로 - 로 바로 팍 하고 진행했는데, 여전히 TDD 보폭이 크다는 생각이 드니 그리 기분이 좋지 않다. (단어들 요소 sort & hash 저장은 처음 개발할때부터 떠올랐던 아이디어여서..)
      ''PBI와 TDD를 잘 버무려서 적용해 보는 실험을 해보아라. 장점이 나름대로 있다. 단점은, 군더더기가 생기거나 완전히 포기하고 새로짜야 할 일이 종종 있다는 점. 내가 중요하다고 생각한 도메인 오브젝트가 사실은 필요없는 것인 경우가 많다. 시간이 나면 DDD도 공부해 보길. --JuNe''
ZP&COW세미나 . . . . 9 matches
     || 4:00 - 4:45 || TDD 시연 ||
     || 4:45 - 5:30 || TDD 연습 ||
      * TDD가 아직은 어렵다. 로보코드는 재미있었다.
      * TDD를 좀더 알게 된 듯하다. 로보코드는 의외로 간단하다.
      * TDD는 하나도 모르겠다. 로보코드 재미있었다.
      * TDD는 이런거다. 로보코드 성적은 아쉽지만 재미있었다.
      * 늦게 와서 TDD는 보지 못하고 로보코드만 재미있게 했다. 다음부터 시간을 잘 지켜야 겠다.
      * TDD는 좋은 방법인 듯 하다. 로보코드는 재미있다.
      * C에서는 프로그램 짜는 것 보다 에러 잡는데 시간이 더 오래 걸리는데, TDD는 덜 걸려서 2학년 1학기 자바 수업에 많이 도움이 될 것 같다.
ExtremeBear/VideoShop/20021105 . . . . 7 matches
      * PairProgramming 을 하며 TDD 에 몰두할 수 있었다.
      * TDD 를 상대적으로 초보인 사람과 PairProgramming 을 해서인지 페이스를 느리게 한다는 의미를 실감할 수 있었다. (세부적으로 전부 테스트)
      * 주니어 입장에 있는 사람이 TDD 를 해보도록 유도했다.
      * 5분 PairProgramming 이 좋았다. TDD 가 쉽고 재미있었다.
      * PairProgramming 과 TDD 덕분에 자기절제가 되어(독단을 방지) 그다지 큰 버그는 없었다.
      * TDD는 어려웠다.
      * 11월 13일까지 TDD와 PairProgramming 을 익숙하게 단련한다.
SeminarHowToProgramItAfterwords . . . . 6 matches
      * TDD를 어설프게나마 시도하면서 느낀점이 'TDD 에서의 Product Code 는 오직 테스트 까지만 만족하는 코드인가' 였었는데. 한편으로는 이렇게 해석할 수 있겠더군요. '해당 스케일에 대해 더욱더 정확하게 작동하는 프로그램을 만들고 싶다면 그만큼 테스트 코드 양을 늘려라.' 테스트코드 자체가 일종의 Quality Assurance 를 위한 도큐먼트 역할도 된다는 점을 다시 생각하게 되었습니다.
      * '테스트코드의 보폭을 조절하라. 상황에 따라 성큼성큼 보폭을 늘릴수도 있지만, 상황에 따라서는 보폭을 좁혀야 한다. 처음 TDD를 하는 사람은 보폭을 좁혀서 걸어가기가 오히려 더 힘들다' wiki:Wiki:DoTheSimplestThingThatCouldPossiblyWork. 이것이 훈련이 아직 덜된, TDD를 하는 사람에게는 얼마나 힘든지는 이번 RDP 짜면서 느꼈었는데. 열심히 훈련하겠습니다.
      * 아까 발표때에도 이야기했지만, Code Review 를 위한 reverse-TDD (정도로 해둘까요? 이것도 관련 문서가 있을텐데. ) 를 해보는 것도 좋을 것 같네요. 코드 분석을 위한 test-code 작성이요. 즉, 이미 만들어져있는 코드를 테스트 코드라고 상정하고, 자신이 제대로 이해했는가에 대한 검증과정을 Test-Code 로 만드는 것이죠. 시간 있었으면 오늘 마저 시도해봤을텐데, 시간에 마음 쫓긴게 아쉽네요.
      * 안녕하세요? 참관자였던 사람입니다. Feedback이 좀 늦었네요. 색다른 경험이었던것 확실했는데, 다만 시간이 한시간 정도만 길었더라면, 훨씬더 많은건 느꼈을것 같아서 아쉽습니다. TDD나 CRC카드 둘다 접하기엔 좀 짧은 시간이었던것 같습니다. 앞으로도 이런기회가 많았으면 좋겠네요. 그럼 이만... --김정준
JTDStudy/첫번째과제/원명 . . . . 5 matches
      * 처음에는 Test-Driven Development 에 입각하여 만들어 보려고 했으나, Java를 거의 처음 시작하고 프로그래밍 경험의 공백기간이 길었던게 큰 타격이었습니다ㅠㅠ. 결국에는 문법과 알고리즘에만 신경을 쓰다보니 TDD방식으로 다루기가 쉽지 않네요. 개선 조언을 해 주신 류상민 선배님 감사합니다 ㅎㅎ -[문원명]
      * 오해가 있을 것 같아서 코멘트 합니다. TDD는 별로 중요하지 않습니다. 결정적으로 저는 '''TDD로 하지 않았습니다.''' 그냥 Refactoring시 Regression Test를 위해서 JUnit 을 썼을 뿐이에요.--NeoCoin
      * 네, 제가 TDD의 의미를 확실히 하지 못한 것 같습니다. TDD책의 앞부분만 읽어 보았는데, 계속해서 더 읽어야 나가야겠다는 다짐이 드네요. 관심 가져주셔서 고맙습니다 ㅋ -[문원명]
ProjectPrometheus/Journey . . . . 5 matches
     이 부분도 일종의 Architecture 의 부분일것인데, 지금 작성한것이 웬지 화근이 된것 같다는. Architecture 부분에 대해서는 Spike Solution 을 해보던지, 아니면 TDD 를 한뒤, Data Persistence 부분에 대해서 내부적으로 Delegation 객체를 추출해 내고, 그녀석을 Mapper 로 빼내는 과정을 순차적으로 밟았어야 했는데 하는 생각이 든다.
     DB 쯤 되고 나니, Test 들의 보폭을 줄이는게 힘들어지는것 같다. (그리고..; 사람들이 잘 안줄이려고 하는것 같다;) TDD 가 좀 더 활성화되러면 학교 컴퓨터들이 더 빨라져야 한다고 개인적으로 생각중 -_-;
      * 중간 알고리즘부분에 대해서 혼란상황이 생겼다. 처음 TDD로 알고리즘을 디자인할때 view / light view / heavy view 에 대한 point를 같은 개념으로 접근하지 않았다. 이를 같은 개념으로 접근하려니 기존의 알고리즘이 맞지 않았고, 이를 다시 알고리즘에 대해 검증을 하려니 우리의 알고리즘은 그 수학적 모델 & 증명이 명확하지 않았다. 우리의 알고리즘이 해당 책들간의 관계성을 표현해준다라고 우리가 주장을 하더라도, 그것을 증명하려니 할말이 생기질 않았다. 수학이라는 녀석이 언제 어떻게 등장해야 하는가에 대해 다시금 느낌이 오게 되었다.
     일단 알고리즘부분을 대강 생각한뒤 Python 으로 TDD 를 했다. ([http://zeropage.org/browsecvs/index.php?&dir=ProjectPrometheus%2FPythonProject%2F&file=RSSpike.py&rev=1.1&cvsrep=ZeroPage 소스]). CRC 세션을 먼저하여 시나리오를 시각화해두고 프로그래밍을 했었다면 좀 더 빨리 작성할 수 있지 않았을까 하는 생각을 해본다.
      * TestDrivenDevelopment 의 경우를 추구했다면 어떠했을까. TDD 의 특성상 꼭 필요한 메소드들만 있는 단순한 디자인을 유도한다라는 점에서. 이번의 경우도 Scenario 를 생각하여 프로그램 뼈대를 만들어서인지 주 Interface가 되는 메소드들외에 불필요한 메소드는 적었긴 한데, 그 대신, 신기하리만치 처음 짠 시나리오가 완벽하게 먹히었다란 생각도 든다;
TdddArticle . . . . 5 matches
     http://groups.yahoo.com/group/testdrivendevelopment/files/ 중 TDDD.pdf
     TDD 로 Database TDD 진행하는 예제. 여기서는 툴을 좀 많이 썼다. [Hibernate] 라는 O-R 매핑 툴과 deployment DB는 오라클이지만 로컬 테스트를 위해 HypersonicSql 이라는 녀석을 썼다고 한다. 그리고 test data 를 위해 DBUnit 쓰고, DB Schema 제너레이팅을 위해 XDoclet 와 Ant 를 조합했다.
     여기에서의 TDD 진행 방법보다는 Reference 와 사용 도구들에 더 눈길이 간다. XDoclet 와 ant, O-R 매핑 도구를 저런 식으로도 쓸 수 있구나 하는 것이 신기. 그리고 HSQLDB 라는 가벼운 (160kb 정도라고 한다) DB 로 로컬테스트 DB 를 구축한다는 점도.
     Xper:XperSeminar 를 보니 일단 셋팅이 되고 익숙해지면 TDD 리듬이 덜 흐트러지는 방법 같았다. (재우씨랑 응주씨가 원래 잘하시고 게다가 연습도 많이 하셔서이겠지만;) password 추가되고 테스트 돌리는 리듬이 좋아보인다. 단, 테스트 돌아가는 속도가 역시 Real DB 이면서 [Hibernate] 까지 같이 돌아가서 약간 느려보이는데, 이건 해보고 결정 좀 해야겠군.
XpWeek/20041221 . . . . 5 matches
      === PP + TDD Practices 120m ===
     아침에 TDD하면서 [Refactoring]이 만만치 않다는 생각을 했다. 생각보다 PlanningGame이 오래 걸려 지루한 느낌과 지친다는 느낌을 받았다. 고객의 입장일 때 내가 뭘 원하는지 명확하지 않았다. 그래도 내일은 왠지 잘 될 것만 같다.
     내 TDD의 보폭이 크다는 사실을 깨달았다. 무엇이든 시작하기 전에 팀 전체가 하고자 하는 의욕이 고무되어 있을 때 효율이 높다. 팀이 같이하는 문화를 만들 필요가 있겠다. --[Leonardong]
     TDD 경험하면서 test class의 Refactoring을 어떻게 해야 될지 모르겠다. test 코드라 굳이 할 필요성을 못 느꼈고 테스트만 하면 된다는 생각이 들었기 때문이다. 인원이 적어서 고객과 개발자의 역할을 번갈아가면서 했는데 개발하기 쉬운 방향으로 생각을 이끌어나가는 것 같았다. 입장을 명확히 한 후 생각을 정리하고 표현해야겠다. 회의가 길어지면서 나타난 의욕상실이 아쉬웠다.
     UserStory와 서버, 클라이언트 프로그램의 진행 방향이 정해졌다. 네트워크 관련 개발과 TDD 진행이 재밌게 이루어졌으면 좋겠다. -- 재선
1thPCinCAUCSE/null전략 . . . . 4 matches
도구는 연습장과 인덱스 카드, assert 문을 이용한 테스트 케이스 등을 이용했습니다. 연습장과 인덱스 카드는 주로 개개인 수식과 중요 변수들을 적기 위해, 또는 그림을 그리기 위해 이용했고 (두 도구의 용도가 구분되어있진 않았음) 문제에 대해서 답이 나왔다하는 가정하에 (문제지에 Sample Input->Output 이 나와있었기에 가능했습니다.) Backward 로 문제가 해결된 상황을 가정하고, 그러기 위해 필요한 변수들을 찾아나가는 방법으로 진행했습니다. 프로그래밍 스타일은 Structured 스타일의 Stepwise Refinement & PBI & assert 를 이용한 TDD 를 사용했습니다.
미리 예제문제로 제시된 5문제중 어려웠었던 뒤의 3문제들을 각자 풀어보고 훈련했었다면 실전에서도 더 여유있고 의식적인 작업을 할 수 있었으리라 생각하며. 그리고, 초반에 바로 TDD 로 나가는 것보다, 문제에 대한 여러 접근방법을 둔 뒤, 하나를 고르고 그에 대해 TDD 로 나가는 것이 더 좋았을 것이라고 생각. (TDD를 바로 문제 Approach 기법으로 적용하는것 보단, 해당 문제 접근방법에 대해 빨리 필요한 변수들을 발견해나가고, 명확하게 해주는데 더 효과가 크다는 생각이 들어서)
ExtremeBear/VideoShop/20021106 . . . . 4 matches
      * TDD 속도가 빨라지고 있다.
      * TDD의 리듬을 조금 더 알게되었다.
      * 입출력 부분의 TDD를 해봤다. 어떻게 해야할지 확실히 알았다.
      * TDD가 익숙해지는 걸 느꼈다.
ProgrammingContest . . . . 4 matches
만약 자신이 K-In-A-Row를 한 시간 이상 걸려도 풀지 못했다면 왜 그랬을까 이유를 생각해 보고, 무엇을 바꾸어(보통 완전히 뒤집는 NoSmok:역발상 으로, 전혀 반대의 "極"을 시도) 다시 해보면 개선이 될지 생각해 보고, 다시 한번 "전혀 새로운 접근법"으로 풀어보세요. (see also DoItAgainToLearn) 여기서 새로운 접근법이란 단순히 "다른 알고리즘"을 의미하진 않습니다. 그냥 내키는 대로 프로그래밍을 했다면, 종이에 의사코드(pseudo-code)를 쓴 후에 프로그래밍을 해보고, 수작업 테스팅을 했다면 자동 테스팅을 해보고, TDD를 했다면 TDD 없이 해보시고(만약 하지 않았다면 TDD를 하면서 해보시고), 할 일을 계획하지 않았다면 할 일을 미리 써놓고 하나씩 빨간줄로 지워나가면서 프로그래밍 해보세요. 무엇을 배웠습니까? 당신이 이 작업을 30분 이내에 끝내려면 어떤 방법들을 취하고, 또 버려야 할까요?
또, Easy Input Set은 직접 수작업으로 풀고 그걸 일종의 테스트 데이타로 이용해서, Difficult Input Set을 풀 프로그램을 TDD로 작성해 나가면 역시 유리할 것입니다. 이렇게 하면 Time Penalty는 거의 받을 일이 없겠죠.
ProjectZephyrus/ClientJourney . . . . 4 matches
* TDD 가 아니였다는 점은 추후 모듈간 Interface 를 결정할때 골치가 아파진다. 중간코드에 적용하기 뭐해서 궁여지책으로 Main 함수를 hard coding 한뒤 ["Refactoring"] 을 하는 스타일로 하긴 하지만, TDD 만큼 Interface가 깔끔하게 나오질 않는다고 생각. 차라리 조금씩이라도 UnitTest 코드를 붙이는게 나을것 같긴 하다. 하지만, 마감이 2일인 관계로. -_- 스펙 완료뒤 고려하던지, 아니면 처음부터 TDD를 염두해두고 하던지. 중요한건 모듈자체보다 모듈을 이용하는 Client 의 관점이다.
간단한 에코서버 관련 프로그래밍을 하는 것인데, 일부러 할일을 주석으로 쓴 뒤, 한단계씩 넘어가는 방법을 써 보았다. TDD 까지는 아니지만, 작은 단계단계를 만들고 확인해보는 것이 더 효과적인 것 같다. [[BR]]
SeminarHowToProgramIt . . . . 4 matches
     ''위의 것을 두시간 동안 다 한다는 것은 -- 세미나 이전과 이후에 사람이 달라지는 수준에서 -- 불가능하고, TDD와 PP, 그리고 DP(RF)를 집중적으로 다루겠습니다. 가능하면 제 구두설명은 짧게 줄이고 나머지 시간은 이 세가지를 직접 실습, 토론하는 시간이 되도록 하겠습니다. 할 것은 많고 시간은 짧습니다. 요즘 저의 "세미나 화두"는 어떻게 하면 "적게 전달"하고 깊이 깨닫게 하거나 혹은 반성하고 또 다양하게 실험해 볼 여지를 많이 제공할 수 있을까 하는 것입니다.''
      * 7:30-7:50 강사 도착. TDD 및 RF 시연(Python). 대형 화면을 보고 원하는 커플은 따라할 수 있음.
      * 8:00-8:10 커플별로 TDD 실습
     하지만 동적 자료형 언어를 접하는 것 자체가 큰 장점일 수가 있습니다. 특히 TDD와 Refactoring은 동적 자료형 언어에서 빛을 발하고, 대다수의 DP는 언어 수준에서 지원이 되거나 아주 간단합니다. 20분 정도면 Python을 간략하게 훑을 수는 있습니다.
TestDrivenDevelopment . . . . 4 matches
     == TDD ==
      === TDD를 하면서 언제 생각을 많이 해야하는지? ===
     === 간단한 C++ 에서의 TDD 참고 함수 ===
      * [http://xper.org/wiki//xp/TestDrivenDevelopment?action=fullsearch&value=TestDrivenDevelopment&literal=1 XPER의 TDD 관련 자료들]
      * [http://wiki.tdd.or.kr/wiki.py tdd.or.kr]
데블스캠프2011/다섯째날/후기 . . . . 4 matches
      * Java를 통한 TDD (비스므리한) 것을 실습했죠. 좀 신기한 방식이라 신기했던거(??) 같습니다. 테스트 케이스를 만족하도록 코드를 만들거어간다라.. 확실히 다른사람의 코드이고 주석이 없는데도 대략적으로 이해할 수 있다는 점은 좋은 거였던거 같습니다. 여러사람들이 한개의 프로젝트를 다루게 된다면 이런식의 것도 필요할거같네요. ..하지만 그럼에도 불구하고 테스트 케이스만 만족하면 된다는 사상도 있어서 어려움이 완전히 해소될것이리라! 라는건 아닌거 같네요. (사실 남의 스펙을 자신이 구현했기 때문에 발생했던 문제겠지마는,.) SVN도 써보고 TDD나 이런 저런 기법들을 데블스에서 처음 접해봐 신선했습니다.
      * 남이 짠 스펙을 보고 구현한다는건 처음이었습니다. 대개는 학교 프로젝트 할 경우에는 무슨 기능이 필요하다는걸 처음부터 생각하고 만드는데 실제 일하는 쪽에서는 그렇지 않을테니 좋은 경험이 됐다고 생각합니다. 유닛 테스트에서 해당 테스트 케이스가 스펙이 될 수 있다는 부분에 대해서도 잘 생각해보고 또 적용해보기 위해 노력해봐야겠습니다. 근데 TDD의 단점에 대해서는 크게 말이 없었던 것 같아서 그 부분이 좀 아쉽습니다.
      * TDD의 단점. 어렵다. 땡. 복합적 의미의 어려움임ㅠㅠ - [서지혜]
데블스캠프2011/첫째날/후기 . . . . 4 matches
      * junit으로 TDD를 해 보았다는 점이 좋았습니다. 다들 자바정도야 이클립스 정도야 해볼수 있겠지만 junit까지는 안해봤을 것 같아서..
      * mock도 해봤으면 좋았으련만, TDD의 꽃은 mock인데 아쉽네요. 엔젤스캠프에서는 한단계 업그레이드된 TDD하고싶어요
      * 앗 이 후기를 쓰지 않았다니! 자바를 처음으로 제가 코딩해볼 수 있었던 시간이었습니다. 전날까지 잘 몰랐던(ㅋㅋㅋㅋㅋㅋㅋ) '박' 성현이 형과 같이 진행했죠. 누구랑 같이 할지 선택하라고 했을때 성현이형을 보자마자 찰나의 고민도 없이 '아! 성현이형이랑 해야겠군!' 이라는 생각이 들엇달까요 ㅎㅎㅎㅎ. 개인적으로 지금은 새발의 피만큼 클래스와 객체의 개념에 대해서 좀 더 이해되는거 같습니다. 책보며 공부하고 있는데도 아직 어려움이 많네요. JUnit이라는 (뒤에가서 TDD도 배웠지만) 분산해서 프로그램 짜는걸 실습해볼 수 있어서 좋았습니다. 세미나가 3시간인게 정말 아쉬웠지요 ㅠㅠ 좀 더 시간이 많아서 많은걸 들을 수 있었다면 좋았을텐데 라는 아쉬움아닌 아쉬움이 남는 지원누나의 최고의 세미나였습니다.
정모/2011.4.4 . . . . 4 matches
      * 도와줘요 ZeroPage에서 무언가 영감을 받았습니다. 다음 새싹 때 이를 활용하여 설명을 해야겠습니다. OMS를 보며 SE시간에 배웠던 waterfall, 애자일, TDD 등을 되집어보는 시간이 되어 좋았습니다. 그리고 팀플을 할 때 완벽하게 이뤄졌던 예로 창설을 들었었는데, 다시 생각해보니 아니라는 걸 깨달았어요. 한명은 새로운 방식으로 하는 걸 좋아해서 교수님이 언뜻 알려주신 C언어 비슷한 언어를 사용해 혼자 따로 하고, 한명은 놀고, 저랑 다른 팀원은 기존 방식인 그림 아이콘을 사용해서 작업했었습니다 ㄷㄷ 그리고, 기존 방식과 새로운 방식 중 잘 돌아가는 방식을 사용했던 기억이.. 완성도가 높았던 다른 교양 발표 팀플은 한 선배가 중심이 되서 PPT를 만들고, 나머지들은 자료와 사진을 모아서 드렸던 기억이.. 으으.. 제대로 된 팀플을 한 기억이 없네요 ㅠㅠ 코드레이스는 페어로 진행했는데, 자바는 이클립스가 없다고 해서, C언어를 선택했습니다. 도구에 의존하던 폐해가 이렇게..ㅠㅠ 진도가 느려서 망한줄 알았는데, 막판에 현이의 아이디어가 돋보였어요. 메인함수는 급할 때 모든 것을 포용해주나 봅니다 ㄷㄷㄷ 제가 잘 몰라서 파트너가 고생이 많았습니다. 미안ㅠㅠ [http://en.wikipedia.org/wiki/Professor_Layton 레이튼 교수]가 실제로 게임으로 있었군요!! 철자를 다 틀렸네, R이 아니었어 ㅠㅠ- [강소현]
      1. 다음번엔 TDD로 CodeRace를 진행해보자는 의견이 있었습니다. 정말 좋은 의견인데 대책없이 적용시킬수는 없겠다는 생각이 드네요. 하지만 굉장히 매력적인 의견이었습니다. 여름방학이나 2학기때 Test-driven CodeRace를 꼭 해보고 싶네요.
      * 음, 이번에 강의실 대여 논의때 "내가 너무 돈을 밝히는 듯한 언행을 해 오진 않았는지"를 생각해볼 수 있었습니다. 답은 "YES"고요....... 자중해야겠습니다. TDD의 경우는, 제가 평소 뭔가를 만들 때(특히 OOPHP Application) 흔히 사용하던 방식이라(클래스를 만들고 밑에 작동 코드를 적은 다음 브라우저로 확인) 조금만 더 노력하면 다른 곳에서도 사용할 수 있을 것 같습니다. 페어 프로그래밍은...... 소현 누님. 결코 누님의 탓이 아닙니다....... <( ºДº)> - [황현]
      * TDD로 레이튼 강건너기 하는중.. 아 짱나게 어렵네 - [서지혜]
EightQueenProblemDiscussion . . . . 3 matches
[이승한]과 PairProgramming을 하며 문제를 풀었습니다. TDD를 하지 않고 30분을 작성했고 나머지 1시간30분을 TDD로 했습니다.
적당한 자료구조를 끝까지 찾지 못해 헤맸다는 느낌입니다. 처음 TDD를 접하는 파트너로서는 테스트를 빨리 이해할 수 없어서 한 동안 페어 사이에 공백이 느껴졌습니다. 속도를 늦추고 파트너에 맞추자, 파트너가 드라이브를 하는 의욕을 보였습니다. 완성하지 못해 다른 이의 코드와 비교하는 시간이 없어서 안타깝습니다.
HowToStudyXp . . . . 3 matches
* ["TestDrivenDevelopmentByExample"] (Kent Beck) : 곧(아마 올해 내에) 출간 예정인 최초의 TDD 서적. TDD를 모르면 XP도 모르는 것. (TDD를 실제 적용하려면 적어도 반년 정도는 계속 훈련해야 함)
PairProgramming . . . . 3 matches
      * 집중 - 이번 경우에는 '시간제한' 이라는 것까지 있어서인지; 석천은 더더욱 프로그래밍 자체에 집중했다. (스크립트 언어 스타일의 접근방법과 이전의 TDD 연습도 한몫 거든듯. 조금씩 만들고 결과 확인해보고 조금 또 만들어보고 결과 확인을 했다. 단, 이번엔 Test Code 를 안만들어서, 뒤에가서 버그가 났을때 대체를 못했다는.-_-; 잘될때는 문제가 아니다. 잘 안될때, 문제상황에 대한 대처가 중요하다고 생각.)
     참고사항 : 몇몇 함수에 대해서만 TDD를 적용시켰다.
     긴 토론 끝에 파트너는 나의 의견에 동의했지만 만약 계속 이런 속도로 작업이 진행된다면 회사에서 가만있지 않을 것이다. (어제도 TDD를 사용했었는데 기존의 코딩시간에 비해 3배정도 더 늦어졌다. 그리고 다 끝내지도 못했고 무엇을 먼저 테스트 해야할지 갈팡질팡했었다. 처음부터 함수단위 테스트만 시도해야겠다는 생각이 원인같다.)
Spring/탐험스터디/2011 . . . . 3 matches
1.3 테스트 가능한 프로그램 : 모듈화가 잘 되어있어야 함(관심사 분리) 모듈을 먼저 만들어서 테스트하고 후에 조립을 한다. TDD 개발시 TDD이전에 테스트 가능한 프로그램을 만들어야 한다.
1.4 TDD : 테스트 주도 개발. 지금 구현하는 것 하나만 테스트해라. 실패하고 바로 성공시켜라 라는 원칙의 개발방법. 1. 무조건 성공시키는 코드 작성. 2. 임시 데이터로 테스트 시 성공하는 코드를 작성. 3. 진짜로 데이터를 넣었을 시 성공하는 코드를 작성. 순으로 구현함.
TddWithWebPresentation . . . . 3 matches
     웹 부분중 표현부분에 대해 어떻게 TDD가 진행될까?
     즉, 현재 action 코드에 다 섞여있는 것이다.이부분을 TDD로 작성하기 위한 테스트는 다음과 같았다.
     하지만, 이건 리팩토링 단계에서의 이야기고, 만일 새 코드를 작성하는 중의 UI 부분 presenter 를 TDD로 구현한다면 어떻게 될까? 아마 저 MockViewPresenter 부분이 먼저 구현되고, 이 인터페이스를 근거로 ViewPresenter 를 만든 뒤 HTML 코드 부분을 작성하면 될 것 같다. 실제 UI 에 어떠어떠한 것이 표현되느냐는 AcceptanceTest 단에 맡기면 되리라.
TestDrivenDatabaseDevelopment . . . . 3 matches
     TDD 로 Database Programming 을 진행하는 방법 & 경험들.
     See Also TdddArticle
     [1002]의 경우 TDD 로 DB 부분을 만들때 어떻게 진행될까 궁리하던중 두가지를 실험해보았다. 보통은 TDD로 DB 부분을 만들때 DB Repository 부분에 대해서 MockObject 를 만들지만, 다음은 Mock 을 안만들고 작성해봤다. 어떤 일이 일어날까를 생각하며.
TestDrivenDevelopmentBetweenTeams . . . . 3 matches
     관련 문서 : http://groups.yahoo.com/group/testdrivendevelopment/files 에 Inter-team TDD.pdf
     팀단위로 TDD를 한다고 한다면?
     일단 각 팀들끼리 TDD 를 하면서 팀들간의 대화를 통해서 일종의 공통 interface 를 빼낼 수 있다. 일단은 일종의 MockObject 로 가짜값을 채워서 테스트를 통과시킨뒤, 실제 Object 가 구현되면, 천천히 하나씩 실제 Object 의 interface 를 끼워가면서 테스트를 통과하는지를 확인한다. 그리고 최종적으로 실제 Object 로 MockObject 를 대체시킨다.
DoItAgainToLearn . . . . 2 matches
TDD 를 연습하고, 워크샵 준비하고 관련 기사글 작성하느냐고 VonNeumannAirport 문제와 kwic 문제를 각각 5번 이상 풀어보게 되었다. (["Python"] 으로, ["CPlusPlus"] 로, ["Java"]로..) 하지만, 풀 때마다 매번 그 결과가 다르게 나왔다. 같은 문제를 계속 풀다 보니, 더 쉽고 더 간단하게 해당 단계를 뛰어넘는 법이 보이는 것이다. 그리고 JuNe 형과 Pair 를 하는중 첫째날때의 진행방법이 달랐고, 둘째날, 셋째날.. 더 좋은 방법들이 계속 보이는 것이였다. 그 문제 사이즈가 크건 작건, 여유를 가지고 다시 해보는 것에서 얻는 점이 많음을 느끼게 되었다. --["1002"]
Seminar:SoftwareDevelopmentMagazine 에서 OOP의 대가 Uncle Bob은 PP와 TDD, 리팩토링에 대한 기사를 연재하고 있다. [http://www.sdmagazine.com/documents/s=7578/sdm0210j/0210j.htm A Test of Patience]라는 기사에서는 몇 시간, 혹은 몇 일 걸려 작성한 코드를 즐겁게 던져버리고 새로 작성할 수도 있다는 DoItAgainToLearn(혹은 {{{~cpp DoItAgainToImprove}}})의 가르침을 전한다.
Favorite . . . . 2 matches
[http://groups.yahoo.com/group/testdrivendevelopment/ TDD 야후그룹]
[http://xper.org/wiki/xp/TestDrivenDevelopmentInCeeLanguage TDD in Cee]
FreechalAlbumSpider . . . . 2 matches
처음에는 모듈에 대해 Remote Test 를 먼저 진행했다가, Local Test 로서 일단 HTML 문서를 받아놓고, 이를 TDD 로 하면서 데이터들을 추출하는것이 낫겠다 판단, Local Html Test 를 작성해나갔다. 이전 ProjectPrometheus 에서 했었던 방법과 비슷했었던지라, 일사천리로 거의 하루동안 관련 작업들이 끝났다.
초반 3일정도는 TDD 를 하고 후반의 PBI 스타일로 테스트 코드이 진행했는데, 후반으로 갈수록 작업 진척도가 떨어지고, 코드에 대한 이해도도 떨어짐을 느꼈다.
JavaStudy2002/진행상황 . . . . 2 matches
* 11/14(목) 오후 1시 - TDD Airport ( See Also ["VonNeumannAirport"]), ["Eclipse"]사용, ["CVS"] 사용
* 11/21(목) 오후 1시 - Airport 다시 공지, ["CVS"] 사용법, TDD 토론, 질문 답변
JollyJumpers/임인택 . . . . 2 matches
      * tdd - 먼가 엉성하다. 기존의 코드를 단지 테스트하는 느낌. 수련이 더 필요하다.
     package ByTDD;
     package ByTDD;
JosephYoder방한번개모임 . . . . 2 matches
* 너무 당연하게 TestDrivenDevelopment라면 테스트부터 작성해야한다고 생각하고있었는데 TDD가 반드시 TestFirstDevelopment일 필요 없다는 말을 듣고 머리를 얻어맞은 것 같았다. 테스트를 언제 작성하는지가 중요한 게 아니라 테스트를 통해 빠르게 피드백을 얻는 것이 중요.
* TDD? TFD?
SpiralArray/Leonardong . . . . 2 matches
하지만 여지껏 그러한 접근법을 알고서도 TDD로 풀지를 못했었다. 매번 나선형 "행렬"에 어떻게 숫자를 새길지만 생각했기 때문이다. 그러다 보니 2차원 배열의 인덱스를 조작하는 수준에서 생각이 벗어나질 못했다. 하지만 사실은 움직임(이전의 인덱스 조작), 움직인 점들, 행렬을 따로 생각할 수 있었다. 아! 이렇게 테스트 하면 되겠구나!
TDD로 풀었다는 점이 기쁘다. 처음부터 너무 메서드를 어디에 속하게 할 지 고민하지 않고 시작한 것이 유용했다. 그 결과로 예전 같으면 생각하지 못했을 Direction클래스와 그 하위 클래스가 탄생했다. 또한 행렬은 최종 결과물을 저장하고 보여주는 일종의 뷰처럼 쓰였다.
TestDrivenDevelopmentByExample . . . . 2 matches
["Java"] 소스(국내에 인기있는;)로 되어있으니 추후 출판뒤 번역이 되지 않을까 하는 희망을; 하지만 지금 진행중인 책의 앞부분을 읽어보긴 했는데. 정말 'Test 로 Driven' 되는 것 같은 느낌이 듬. TDD 진행과정을 예제 하나를 통해 계속 보여주기 때문에 이해하기 편합니다.
개인적으로 TDD 중 빠른 테스트 통과를 위해 가짜 상수로 쌓아나갈때 어떻게 '중복' 이라 하여 ["Refactoring"] 할까 고민했었는데, 이전의 SeminarHowToProgramIt 에서의 예제 이후 이 문서에서의 예제가 깔끔하게 풀어주네요. 인제 한번 들여다 본 중이긴 하지만, 저자가 저자인 만큼 (KentBeck).~
TheTrip/Leonardong . . . . 2 matches
무엇이 잘못 되어도 테스트를 추가해본다는 점은 역시나 TDD가 매력적일 수 밖에 없는 요인이다. 이제는 손으로 테스트를 하려면 너무 귀찮고 시간낭비라고 생각한다. TDD 리듬을 조절해줄 파트너가 옆에 있다면 더욱 좋으련만. :) --[Leonardong]
VonNeumannAirport . . . . 2 matches
* TDD접근 방법의 미숙
||[VonNeumannAirport/1002] || 1002 || VonNeumannAirport TDD 재시도중. ||
XpWeek/20041220 . . . . 2 matches
4시 ~ 6시 : TDD 실습
스피커를 가져오지 않았다. 준비가 덜 되어서 허둥댔다. TDD를 상당히 어려워 하므로 좀더 수준에 맞는 예제가 필요하겠다. --[Leonardong]
XpWeek/20041224 . . . . 2 matches
알바하느라 소홀히 한점이 아쉽다. 또한 MockObjects에 대한 이해가 부족하여 TDD로 진행하지 못한 점이 아쉽다. 5일간 쉼없이 달려왔는데 아직 미흡한 점이 많다. 혼자 리펙토링을 해보았지만 별로 재미 없었다. 구피에서 돌릴 수 있도록 간단한 리펙토링하고 GUI 기능을 추가하고 싶다. 다음주중 하루 잡아서 하는게 어때?? 그리고 나의 최종 목표는 테스트코드를 추가하는 것이다. TDD는 아니지만 네트워크에 대한 MockObjects를 구현해보고 싶다. -- 재선
XpWeek/ToDo . . . . 2 matches
[[HTML(<strike>)]]PP + TDD Practices[[HTML(</strike>)]]
=== PP + TDD Practices ===
[Lovely]boy^_^/Diary/2-2-10 . . . . 2 matches
* XB 진짜로 시작. 재동이가 고객이 되어서, 재동이가 준비해온 네트워크 오델로를 짜기로 했다. 처음에는 기대감에 마구마구 넘쳐서 침을 튀겨가며 얘기를 했지만, 나중에는--; 결국 통합은 실패했다. 기초부터 시작해야 할듯싶다. 하지만 배운것도 많았다. 재미도 있었고.. 글구 혜선이가 고객을 해주기로 했다. 이제 프로젝트가 본격적으로 시작이 된다. 낼부터 2주정도는 간단한 프로그램으로 TDD와 호흡 맞추는데 주안점을 둘 생각이다.
* The XB Project starts really. A customer is Jae-dong. So we determine to programm network othelo, that Jae-dong's preparation. At first, we start hopefully, but..--; after all integration is failed. In our opinion, we start beginner's mind. but we learned much, and interested it. And new customer is Hye-sun. Since now, our project begins really. Since tomorrow, during 2 weeks, we'll focus on TDD and pair programming with simple programming.
[Lovely]boy^_^/Diary/2-2-4 . . . . 2 matches
* TDDB 입수
* TDDB 1/3정도 봄
데블스캠프2003/둘째날/후기 . . . . 2 matches
* TDD와 페어프로그래밍으로 상욱이랑 미로찾기를 만들면서 많은걸 깨달았다. 가장 중요한건 네이밍의 중요성! 이름을 이상하게 지어놓고 이상한걸 호출하다가 자꾸 이상하게 나와서, 나중에는 '미로를 무시하고 이동한다.' 라는 말까지 나왔었다.--; 그러면서 중간에 TDD를 잘못했구나 아직 멀었구나 덜 테스트했구나하면서 좌절을 했지만 이름을 고치고 나니 바로 해결이 되는걸 보면서.. 아.. 더불어 CSP는 아직도 이해가 잘 안간다. --인수
데블스캠프2009/수요일 . . . . 2 matches
|| 송지원 || Simple Java & JUnitTest || Java의 간단한 문법과 개념을 배우고,[[br]]JUnitTest를 통해 TDD 기반의 프로그래밍에 대해 맛보기. || 아무래도 Test가[[br]]메인이다 보니,[[br]]Java를 통한 OOP 개념의 실습은[[br]]시간상 진행하지 않는다. ||
||am 04:00~05:00 || TDD의 개념과 JUnitTest 실습 || 송지원 ||
작은자바이야기 . . . . 2 matches
* TDD로 코드를 짜 보려다 실패해서 -_-;;; 어떻게 TDD로 코딩을 해야 하는지, 어떻게 리팩토링을 해야 하는지 듣고 싶어서.
2002년도ACM문제샘플풀이 . . . . 1 match
* [http://cs.kaist.ac.kr/~acmicpc/problem.html 2002년도 문제 샘플] 풀이입니다. ["신재동"]과 ["상규"]가 '개발 시간 최소화' 라는 문제 때문에 시작부터 TDD와 Refactoring 그리고 OOP를 버렸습니다. 그래서 중복도 심하고 남에게 보여주기 정말 부끄럽지만... 용기내서 올립니다. 리펙토링 후에 변한 모습을 다시 올리도록 하겠습니다.
AOI/2004 . . . . 1 match
오늘은 오래간만에 C++로 코딩해 봤다. 속도 최우선 프로그래밍으로... 다음에 할 때는 다른 언어로, 또는 OOP로, 또는 TDD로 코딩해봐야겠다. --재동
APlusProject . . . . 1 match
TestDrivenDevelopmentByExample - TDD 입문서. 한서 있음. QA와 Eng는 필독.
BoaConstructor . . . . 1 match
5. 정식 버전은 TDD 로 다시 DoItAgainToLearn. WingIDE + VIM 사용. (BRM 을 VIM 에 붙여놓다보니. 그리고 WingIDE 의 경우 Python IDE 중 Intelli Sense 기능이 가장 잘 구현되어있다.)
BuildingWikiParserUsingPlex . . . . 1 match
그러나......~ 후자로 수정하는데 40분도 안걸리다.; 작업으로 본다면 Parser 두개의 lexicon 을 합치는 작업임에도 불구하고, 그 안정성도 보장받으면서 parser 에서 line 단위 자르기 부분까지 수정하였다. 매 번 수정할때마다 테스트를 돌리면서 확인했기 때문에 그 결과가 보장이 되었다. Text Processing 에서 이러한 부분에 대한 TDD의 파워는 정말 크다란 생각이 든다.
DataCommunicationSummaryProject/Chapter9 . . . . 1 match
* TDD + TDMA
DesignPatterns/2011년스터디/1학기 . . . . 1 match
1. JUnit과 EasyMock이 핵심인 프로젝트라 TDD를 하고싶었다.
Eclipse . . . . 1 match
* 기능으로 보나 업그레이드 속도로 보나 또하나의 Platform; 플러그인으로 JUnit 이 아에 들어간것과 리펙토링 기능, Test Case 가 new 에 포함된 것 등 TDD 에서 자주 쓰는 기능들이 있는건 반가운사항. (유난히 자바 툴들에 XP 와 관련한 기능들이 많이 추가되는건 어떤 이유일까. MS 진영에 비해 자바 관련 툴의 시장이 다양해서일까) 아주 약간 아쉬운 사항이라면 개인적으로 멀티 윈도우 에디터라면 자주 쓸 창 전환키들인 Ctrl + F6, Ctrl + F7 은 너무 손의 폭 관계상 멀어서 (반대쪽 손이 가기엔 애매하게 가운데이시고 어흑) ( IntelliJ 는 Alt + 1,2,3,.. 또는 Alt + <- , ->) 단축키들이 많아져 가는 상황에 재정의하려면 끝도 없으시고. (이점에서 최강의 에디터는 [Vi] 이다;) 개인적 결론 : [Eclipse] 는 Tool Platform 이다; --석천
EightQueenProblemSecondTryDiscussion . . . . 1 match
우.. 그리고 여전히 테스트 코드를 생각하기 어려웠던 부분이 실제 Queen 을 놓는 부분인데요. 다음과 같이 코드를 나열하고 재귀호출 부분에 대해서 유도를 하는 방법을 시도해봤습니다. 일종의 수열 찾는 방법이 되더군요. 음.. 이 부분에 대해서는 EightQueenProblem 에 대한 하나의 해를 알아놓고 시작한다면 TDD를 시도할 수 있을것 같다는 생각이 들긴 하는데. (문제는, 답을 구해놓고 나서야 이 생각이 났더라는. --;)
ExtremeBear/VideoShop . . . . 1 match
* 최대한 TDD 등의 XP Practice 를 수행하며 하자.
GuiTestingWithWxPython . . . . 1 match
TDD로 컨트롤을 하나하나 붙이고 위치값을 잡고 리스트박스에 초기값을 설정하는 예제
IpscAfterwords . . . . 1 match
석천군 팀이 B번 문제(Job Balancing)를 풀긴 풀었으나 시간이 너무 걸려서 옵티마이징을 필요로 했습니다. 제가 O(m*n^2)에서 O(m*n)으로 만들어줬는데, 그것으로도 부족했습니다. 집에 돌아와서 잠을 자다가(NoSmok:포앵카레문제해결법 ) 몇 가지 아이디어가 떠오르더군요. 오늘 아침에 일어나서 30분 정도 뚝닥거려서 B Difficult Set을 5초 안에 끝내는 코드를 만들었습니다. 어떻게 사고했냐구요? TDD로 원소 하나 짜리, 두 개 짜리, 세 개 짜리, ... 를 하다보니까 일반해가 보이더군요. 역시 마음에 여유가 있으면 잘 되는 것 같습니다.. see also IpscLoadBalancing
JTDStudy . . . . 1 match
* This page's group study Java , TDD and Design patterns
JTDStudy/첫번째과제/상욱 . . . . 1 match
* TDD로 만들려고 하니 적응도 안되고 해서 시간이 꽤나 많이 걸리네요^^; 프로그램을 위한 테스트라기 보단 테스트를 위한 프로그램이 되어지는 느낌이 팍팍;;; 하지만 장점이 많은 방법이라 앞으로 더 연습을 해 봐야겠네요~ - [상욱]
JTDStudy/첫번째과제/정현 . . . . 1 match
TDD로 진행했습니다.
JavaStudy2002/해온일 . . . . 1 match
* TDD에 대한 느낌에 대한 토론
JollyJumpers/신재동 . . . . 1 match
이번엔 TDD로... 쉬운 알고리즘이라 테스트를 몇 개 안만들고 끝냈다. --재동
MagicSquare/재동 . . . . 1 match
["신재동/PracticeByTDD"]
MineSweeper/Leonardong . . . . 1 match
작은 단계를 밟아가면서 TDD를 적용하다 보니까 시간이 많이 걸렸다. 게다가 모르는 파이선 문법 찾는데도 시간이 걸렸다. 파이선의 새로운 기능을 알게 되어 신기하다. 다음 문제를 풀어볼까나. --[Leonardong]
ObjectWorld . . . . 1 match
Http Unit 에 대해선 좀 회의적인 투로 설명을 하신것 같고, (이정도까지 테스트 할까..에 가까운) ["ExtremeProgramming"] 에서의 TDD 스타일은 따로 취급되었다라는 생각이 들었다는. (XP에서의 테스트를 먼저 작성하라는 이야기에 대해서 그냥 TP를 읽는 수준으로만 넘어간것 보면. 코딩 완료이후 테스트를 기본이라 생각하고 설명하셨다 생각됨.)
PyIde . . . . 1 match
* Prototyping & 외부 공개소스 Review & Copy & Paste 하여 가능한한 빠른 시간내에 원하는 기능 구현법이나 라이브러리들을 연습하여 익힌뒤, Refactoring For Understanding 을 하고, 일부 부분에 대해 TDD 로 재작성.
REFACTORING . . . . 1 match
- VC용 Refactoring 도구는 없나요? C++ 이라는 언어에서 Refactoring 이라는 개념을 적용시키려면 TDD in VC++ 처럼 약간 복잡한 과정이 필요하겠지만요;; - [임인택]
RandomWalk2/재동 . . . . 1 match
["신재동/PracticeByTDD"]
SeparatingUserInterfaceCode . . . . 1 match
전에 TDD 기사 썼을때 읽으면서 굉장히 감명깊었던 구절. 디자인에서 로직/UI 분리가 어떻게 이루어져야 하는가를 아주 간단하면서도 명료하게 말해준다. 개인적으론 RefactoringBook 을 읽었을때보다 이 글을 본 것이 더 충격적이였던것으로 기억된다. (특히, RefactoringBook 을 읽었을때보다 상대적으로 디자인에 대한 지식이 더 있었을때임에도 충격이 더 컸음에.) :
Slurpys . . . . 1 match
이번 문제는 TDD를 강력 추천. --재동
SummationOfFourPrimes/1002 . . . . 1 match
합이 x 인 수 조합리스트에 대해 어떻게 구할까 궁리하던중, 소수리스트를 먼저 만들고 소수리스트에서 4개를 골라서 합을 구한 결과가 n 인지를 비교하는 방법이 더 빨리 구현할 수 있겠구나라는 생각이 들었다. 이에 대해서 TDD로 진행.
SwitchAndCaseAsBadSmell . . . . 1 match
이중에서 두번째 "판단하기"를 TDD와 리팩토링을 통해 다음과 같이 만들었습니다.
VisualAssist . . . . 1 match
[1002] 의 경우 요새는 VC++.NET 이상 되는 녀석을 쓰는 일로 대체중. VA 자체 버그도 많아서 (특히 TDD 할때 아직 선언 안된 변수 먼저 쓰려면 자꾸 이상한 변수로 자동완성시켜버린다.;) 잘 안쓰려는 중. --[1002]
VonNeumannAirport/1002 . . . . 1 match
페이지를 작성하면서 작성해 나갑니다. TDD 연습중이니 아마 중간 삽질도 예상된다는. ^^;
ZeroPageHistory . . . . 1 match
||2학기 ||Extreme Programming 진행 (TDD, [Pair Programming]) ||
ZeroPage성년식/거의모든ZP의역사 . . . . 1 match
||2학기 ||Extreme Programming 진행 (TDD, [Pair Programming]) ||
[Lovely]boy^_^/Diary/2-2-2 . . . . 1 match
* 우리나라에 사람 무는 바퀴벌레가 들어온 기념으로.. TDD를 이용한 RandomWalk2를 해보았다.(Python) 파이썬 문법 자체에서 좀 많이 버벅거렸다는게 좀 아쉽다. 테스트 수십개가 통과하는 것을 보고 있자니 괜시리 기분이 좋아진다는--;
neocoin/Log . . . . 1 match
* 감안 : 임의의 비트맵 파일을 로드할수 있다. 임의 비트맵 파일로 저장할수 있다. MFC Class를 이용해 본다. Api로만 작성해 본다. Java로 작성해 본다. TDD를 생각해 본다. 어떻게 가능한가?
neocoin/SnakeBite . . . . 1 match
* TDD 흉내를 내보자. 특히 GP32에서.
데블스캠프2009/수요일/연습문제 . . . . 1 match
== Java & TDD - 송지원 ==
데블스캠프2011/첫째날/개발자는무엇으로사는가 . . . . 1 match
* 아니면 TDD라던가
몸짱프로젝트/BinarySearchTree . . . . 1 match
* TDD를 쓰긴 썼는데, 테스트가 영 마음에 들지 않는다. 후...
상협/프로젝트관련 . . . . 1 match
* 만약 짜본다면 내가 제일 좋아 하는 AI 오목을 Java로 TDD를 사용해서 한번 다시 짜볼까 한다. 인공지능을 사람이 못이기게 무진장 향상 시켜서.. +_+
서지혜 . . . . 1 match
* ~~4.5 정모에서 한 코드레이스의 코드를 TDD로 짜보려고 하고있어요.~~
시간관리하기 . . . . 1 match
의외로 '간단해보이는', 하지만 인간적인 시스템을 제공한다. TDD 를 하는 사람들이라면 'To Do List 에 등록해놓기' 생각날지도.
오목/인수 . . . . 1 match
* TDD 연습차..
정모/2004.5.21 . . . . 1 match
- TDD
정모/2006.12.20 . . . . 1 match
* TDD/페어
정모/2007.3.6 . . . . 1 match
두 번째 발표자 : 이장길 -> 정현선배와 TDD, JAVA 공부, AI프로젝트 하다가 MFC프로젝트로 전환, 학교에 와서 서든하다가 선배들과 스타를 즐겼다.
정모/2011.4.4/CodeRace/김수경 . . . . 1 match
* [TDD]로 개발하려 했는데 rake aborted! No Rakefile found. 라는 메세지가 뜨면서 테스트가 실행되지 않아 포기함. 한시간동안 계속 찾아봤지만 모르겠다. 영어 문서를 읽으면 답이 있을 것 같은데 더 이상은 영어를 읽고싶지않아ㅜㅜㅜㅜㅜㅜ
정모/2012.4.30 . . . . 1 match
* mock, TDD, unit test, refactoring, maven 등 자바에 대해 깊은 부분까지 다룰 예정.
즐겨찾기 . . . . 1 match
[http://groups.yahoo.com/group/testdrivendevelopment/ TDD 야후그룹]

Found 89 matching pages out of 7555 total pages (5000 pages are searched)

Full text search for "TDD"

You can also click here to search title.