본문 바로가기

책읽기

 (31)
TDD_7 12장 드디어, 더하기 $5 + 10CHF = $10 (1:2의 환율일 경우) $5 + $5 = $10 더하기의 전체기능을 구현하기 어렵다. 그래서 먼저 5+5=10이라는 쉬운 기능 먼저 해본다. 사실 이 이후의 설명들이 잘 와닿지가 않는다. 편하게 여러 환율을 표현할 수 있으면서도 산술연산 비슷한 표현들을 여전히 산술 연산처럼 다룰 수 있는 해법이 있으면 좋을 것 같다. 객체가 이 역할을 한다고 한다... [가지고 있는 객체가 우리가 원하는 방식으로 동작하지 않을경우엔 그 객체와 외부 프로토콜이 같으면서 내부 구현은 다른 새로운 객체를 만들 수 있다.] => Money와 비슷하게 동작하지만 사실은 두 Money의 합을 나타내는 객체를 만드는 것 이 메타포가 나오기 전의 다른 메타포의 예) Money를 ..
TDD_6 10장 흥미로운 시간. 10장에서는 공용 times를 제거하게 된다. 현재 두 클래스의 times는 비슷하다. 하지만 어떻게 처리해야 할 지 명백한 방법이 떠오르지 않는다. 그래서 팩토리 메서드를 적용하기 전으로 돌아가 본다. Franc에서는 currency가 항상 "CHF", Dollor에서는 "USD"이므로 변수를 이용하도록 바꾼다. 이 때, 각 times()에서 Money를 반환할지, Dollor나 Franc를 반환 할 지 결정해야 한다. 우리는 Money로 공통되게 하고 싶다. 고민하는 대신 그냥 넣어보자. 현재는 Money가 추상클래스로 정의되어 있다. 추상클래스는 인스턴스를 반환할 수 없으므로 concrete클래스로 바꿔주라는 오류 메세지이다. 추상 메소드로 Money에 선언한 times() ..
TDD_5 7장 사과와 오렌지 You can't compare apples and oranges. 영어권 속담, 다른 것을 비교할 수 는 없다. $5 + 10CHF = $10(환율이 2:1 인 경우) // 해결 // $5 x 2 = $10 // 해결 // amount를 private로 만들기 // 해결 // Dollor 부작용? Money 반올림 // 해결 // equals() hashCode() Equal null Equal object //해결// 5CHF x 2 = 10CHF Dollor,Franc 중복 //해결// 공용 equal 공용 times //추가// Franc와 Dollor비교하기 최근에 추가한 Franc와 Dollor를 비교하기 위해 testEquality()에 새로운 테스트코드를 작성한다. 실패..
TDD_4(값 객체 패턴) 3장 모두를 위한 평등. Dollor 객체를 값 객체 패턴으로 설명한다. 값 객체 - immutable : (생성자에 의해 생성된 후)변경 불가능한 객체이다. - 값 객체는 [두개의 값 객체의 동일성(equality) 은 Identity에 기반하지 않고 그들의 컨텐츠로 한다]로 정의된다. ==> Identity : 데이터베이스의 인덱스 처럼 자신을 나타내는 요소, 컨텐츠가 같을 때 두 객체를 구분하는 요소 - 별칭문제를 해결할 수 있다. (dollor가 $5일때 영원히 5의 값을 가짐을 보장, $7을 만들고 싶다면 새로운 객체를 만들어야함.) 이를 통해 값 객체가 암시하는 것을 알 수 있다. 1. 모든 연산은 새 객체를 반환해야 한다. 2. equals()를 통해 같음을 보장받아야 한다. 값 객체는 다음..
TDD_3 1장에서 진행하는 다중화폐예시는 워드가 와이캐시에서 만든 달러로 관리되던 채권을 다중통화로 관리될 수 있게 하는 개발과정에서 테스트를 연습한다. 책에서 제시하는 TDD의 리듬은, 1. 재빨리 테스트 하나 추가 2. 모든 테스트를 실행하고 추가한 테스트가 실패하는지 확인 3. 코드 수정 4. 모든 테스트를 실행하고 전부 성공하는지 확인 5. 리펙토링을 통해 중복제거 이다. 이 부분을 생각하며 예제를 진행할 것이다! 먼저 다중통화를 이용하는 보고서를 만드려면 다음의 일을 해야한다. $5 + 10CHF = $10(환율이 2:1 인 경우) $5 x 2 = $10 첫 번째 할 일은 환율에 맞게 각 화폐를 더한 값을 출력해야 한다. 두 번째 할 일은 통화에 주가의 수 만큼을 곱한 값을 출력해야 한다. 비교적 두 번..
TDD_2 테스트 주도 개발의 궁극적인 목표는 clean code that wroks(작동하는 깔끔한 코드)이다. 이것이 훌륭한 이유를 몇가지 알게 되었다. - 발생할 버그와 오류를 예측 가능한 개발 방법이다. - 코드를 그냥 생각나는 대로 짜버리고 마는 것 보다 코드가 주는 모든 것을 생각할 수 있다. - 소프트웨어의 질을 높인다. TDD의 규칙 1. 오직 자동화된 테스트가 실패할 때에만 새로운 코드를 작성한다. 2. 중복을 제거한다. 이 규칙에 의해서 다음의 개발순서가 정해진다. 1. 빨간색 - 실패하는 작은 테스트 작성. 컴파일조차 되지 않을 수 있다. 2. 초록색 - 빨리 테스트가 통과하게 만든다. 어떤 수단과 방법을 가리지 않는다. 3. 리펙토링 - 테스트를 통과하게 만드는 과정에서 발생한 중복을 제거한다..
TDD_1 예전에 사놓고 읽다가 만 켄트 백의 Test Driven Development를 다시 읽기로 했다. 하루 20페이지씩 꾸준히 읽을 것이다..! 처음은 역자의 말과 저자의 인터뷰가 실려 있었다. TDD 수련법 1. 수 - 간단한 문제를 TDD로 시도. - 초록 막대 주기를 가능한 짧도록 한다. (초록 막대 주기란 테스트를 돌릴 때, 초록 막대가 나오는 시점에서 다음 초록 막대가 나오는 시점까지의 시간) - 초록 막대 주기의 최대를 정하고, 넘으면 다시 짠다. - 같은 문제를 반복해서 푼다. 2. 파 - 새로운 영역에서 TDD를 시도한다. 이에 대해 잘 되는가? 어려운가? 왜 어려운가? 의 고민을 끊임없이 한다. - 자신에게 맞는 속도를 찾는다. - 일주일정도의 개발기간으로 작은 TDD 애플리케이션을 개발한..

티스토리툴바