켄트 벡(Kent Beck)23 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (7 ~ 8장) [7장] 사과와 오렌지 : You can’t compare apples and oranges. 서로 다른 걸 비교할 수 없다.[정리]-우릴 괴롭히던 결함을 끄집어내서 테스트에 담아냈다.-완벽하진 않지만 그럭저럭 봐줄 만한 방법 (getClass( ))으로 테스트를 통과하게 만들었다.-더 많은 동기가 있기 전에는 더 많은 설계를 도입하지 않기로 했다. [8장] 객체 만들기한번에 큰 단계를 밟는 것은 TDD를 효과적으로 보여주기에 적절하지 않을 것 같다.팩토리 메서드(factory method)모든 테스트가 실행되므로 최소한 뭔가를 깨트리진 않았다.하위 클래스의 존재를 테스트에서 분리(decoupling)함으로써 어떤 모델 코드에도 영향을 주지 않고 상속 구조를 마음대로 변경할 수 있게 됐다. [정리]-동일.. 2020. 2. 3. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (5 ~ 6장) [5장] 솔직히 말하자면1.테스트 작성.2.컴파일 되게 하기.3.실패하는지 확인하기 위해 실행.4.실행하게 만듦.5.중복 제거.각 단계에는 서로 다른 목적이 있다. 다른 스타일의 해법, 다른 미적 시각을 필요로 한다. 처음 네 단계는 빨리 진행해야 한다. 그러면 새 기능이 포함되더라도 잘 알고 있는 상태에 이를 수 있다. 거기에 도달하기 위해서라면 어떤 죄든 저지를 수 있다. 그동안 만큼은 속도가 설계보다 더 높은 패이기 때문이다. [정리]-큰 테스트를 공략할 수 없다. 그래서 진전을 나타낼 수 있는 자그마한 테스트를 만들었다.-뻔뻔스럽게도 중복을 만들고 조금 고쳐서 테스트를 작성했다.-설상가상으로 모델 코드까지 도매금으로 복사하고 수정해서 테스트를 통과했다.-중복이 사라지기 전에는 집에 가지 않겠다고 .. 2020. 2. 2. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (3 ~ 4장) [3장] 모두를 위한 평등 어떤 계약에 새로운 보상 항목을 추가하면 그 계약 자체가 변하게 된다. 객체를 값처럼 쓸 수 있는데 이것을 값 객체 패턴(value object pattern)이라고 한다. 값 객체에 대한 제약사항 중 하나는 객체의 인스턴스 변수가 생성자를 통해서 일단 설정된 후에는 결코 변하지 않는다는 것이다. 값 객체를 사용하면 별칭 문제에 대해 걱정할 필요가 없다는 아주 큰 장점이 있다. 값 객체가 암시하는 것 중 하나는 2장에서와 같이 모든 연산은 새 객체를 반환해야 한다는 것이다. 삼각측량을 이용하려면 예제가 두 개 이상있어야만 코드를 일반화할 수 있다. 테스트 코드와 모델 코드 사이의 중복을 잠깐만 무시하자. 두 번째 예가 좀더 일반적인 해를 필요로 할 때, 오로지 그때만 비로소 일.. 2020. 2. 1. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (1 ~ 2장) 1.재빨리 테스트를 하나 추가한다. 2.모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다. 3.코드를 조금 바꾼다. 4.모든 테스트를 실행하고 전부 성공하는지 확인한다. 5.리팩토링을 통해 중복을 제거한다. ⇒ -각각의 테스트가 기능의 작은 증가분을 어떻게 커버하는지 -새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지 -얼마나 자주 테스트를 실행하는지 -얼마나 수 없이 작은 단계를 통해 리팩토링이 되어가는지 [1장] 다중 통화를 지원하는 Money 객체 어떤 테스트들이 있어야(이 테스트들이 모두 통과할 경우) 코드가 완성됐다는 걸 확신할 수 있을까? 앞으로 어떤 일을 해야 하는지 알려주고, 지금 하는 일에 집중할 수 있도록 도와주며, 언제 일이 다 끝나는지 알려줄 수 있게끔 .. 2020. 1. 31. 테스트 주도 개발(Test-Driven Development:By Example) (서문) [역자의 글] 켄트백 - 테스트 주도 개발은 하나의 기술이지만 그 이면에는 사고의 근원적 변화가 있습니다. 데밍(W.E Deming)은 품질에 대한 책임을 그 누구보다도 작업자에게 맡겨야 한다고 주장했습니다. ... 프로그래머가 자기 작업의 품질에 대한 우선적 책임을 져야 한다는 깨달음이죠. TDD를 실천법으로 적용하는 것은 도움이 될 수 있습니다만, 책임을 맡는 방법으로 사용하면 강력해질 것입니다. 김창준 - ... 자신의 생각과 컴퓨터가 보여주는 것이 서로 다르다고 해서 절대 낙심하지 마세요. 다름을 느끼고 즐기려고 하세요. 빨리 테스트를 통과시키려고, 혹은 프로그램을 빨리 작성하려고 너무 조바심 내지 마세요. 자신감을 가지세요. TDD를 쫓아가려고 하지 마시고 TDD가 자신을 따라오게 하세요. .... 2020. 1. 30. 이전 1 2 3 4 다음