켄트 벡(Kent Beck)23 테스트 주도 개발(Test-Driven Development:By Example) - 2부 : xUnit 예시 (18 ~ 19장) [18장] xUnit으로 가는 첫걸음 테스트 툴을 만드는 과정에서 만들어지는 테스트 툴 자체를 사용한다는 것은 스스로 자신의 뇌를 수술하는 것과 비슷할 것 같다. 때때로 괴상해지기도 할 것이다. 테스트 케이스를 만들고 테스트 메서드를 실행할 수 있어야 한다. 우린 테스트 케이스를 작성하기 위해 사용할 프레임워크를 테스트하기 위한 테스트 케이스를 작성해야 하는 것이다. 아직 프레임워크가 없기 때문에 첫 번째 작은 단게는 수동으로 검증해야 할 것이다. -테스트 메서드 호출하기 -먼저 setUp 호출하기 -나중에 tearDown 호출하기 -테스트 메서드가 실패하더라도 tearDown 호출하기 -여러 개의 테스트 실행하기 -수집된 결과를 출력하기 테스트 메서드가 호출되면 true, 그렇지 않으면 false 테스.. 2020. 2. 9. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (17장) [17장] Money 회고 다음에 할일 -메타포:설계 구조에 미치는 메타포 -JUnit 사용도 -코드 메트릭스(metrics) -프로세스:빨강/초록/리팩토링 -테스트의 질 [다음에 할일은 무엇인가] 지저분한 중복 처리 보통 클래스가 인터페이스로 바뀌는 일이 잦은데, 그 반대로 바뀌는 것은 일반적인 방향이 아니다. 난 “끝났다”는 말을 믿지 않는다. TDD를 완벽을 위한 노력의 일환으로 사용할 수도 있겠지만 그건 TDD의 가장 효과적인 용법이 아니다. 만약 시스템이 크다면, 당신이 늘 건드리는 부분들은 절대적으로 견고해야 한다. 그래야 나날이 수정할 때 안심할 수 있기 때문이다. 작업을 끝낸 후에 스몰토크의 스몰린트(SmallLint) 같은 코드 감정(code critic) 프로그램을 실행하길 좋아한다. .. 2020. 2. 8. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (15 ~ 16장) [15장] 서로 다른 통화 더하기 처음 코드 수정이 다음으로 계속해서 퍼져나갈 수 있도록 할 것이다. 앞으로 나아갈 수 있는 두 갈래 길이 있다. 좁은 범위의 한정적인 테스트를 빠르게 작성한 후에 일반화하는 방법도 있고, 우리의 모든 실수를 컴파일러가 잡아줄 거라 믿고 진행하는 방법도 있다. 컴포지트(Composite) 패턴 [정리] -좀더 추상적인 선언을 통해 가지에서 뿌리(애초의 테스트 케이스)로 일반화했다. -변경 후, 그 영향을 받은 다른 부분들을 변경하기 위해 컴파일러의 지시를 따랐다. [16장] 드디어, 추상화 우리가 이 테스트들을 작성하는 것은 단지 자신의 프로그래밍 경험을 더 재미있고 보람차게 하려고 하는 것만이 아니고, 후대가 우리의 천재성을 감상할 수 있는 로제타석이 되도록 하기 위함이.. 2020. 2. 7. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (13 ~ 14장) [13장] 진짜로 만들기이 코드는 다음 두 가지 이유로 지저분하다.-캐스팅(형변환). 이 코드는 모든 Expression에 대해 작동해야 한다.-공용(public) 필드와 그 필드에 대한 두 단계에 걸친 레퍼런스.클래스를 명시적으로 검사하는 코드가 있을 때에는 항상 다형성(polymorphism)을 사용하도록 바꾸는 것이 좋다. [정리]-모든 중복이 제거되기 전까지는 테스트를 통과한 것으로 치지 않았다.-앞으로 필요할 것으로 예상되는 객체의 생성을 강요하기 위한 테스트를 작성했다.-일단 한 곳에 캐스팅을 이용해서 코드를 구현했다가, 테스트가 돌아가자 그 코드를 적당한 자리로 옮겼다.-명시적인 클래스 검사를 제거하기 위해 다형성을 사용했다. [14장] 바꾸기하지만 지금은 리팩토링하는 중에 코드를 작성하는 .. 2020. 2. 6. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (11 ~ 12장) [11장] 모든 악의 근원이 테스트를 지워도 될 정도로 다른 곳에서 동치성 테스트를 충분히 하고 있는가? 다른 동치성 테스트를 한번 보자. [정리]-하위 클래스의 속을 들어내는 걸 완료하고, 하위 클래스를 삭제했다.-기존의 소스 구조에서는 필요했지만, 새로운 구조에서는 필요 없게 된 테스트를 제거했다. [12장] 드디어, 더하기가지고 있는 객체가 우리가 원하는 방식으로 동작하지 않을 경우엔 그 객체와 외부 프로토콜이 같으면서 내부 구현은 다른 새로운 객체(imposter, 타인을 사칭하는 사기꾼)를 만들 수 있다.TDD는 적절한 때에 번뜩이는 통찰을 보장하지 못한다. 그렇지만 확신을 주는 테스트와 조심스럽게 정리된 코드를 통해, 통찰에 대한 준비와 함께 통찰이 번뜩일 때 그걸 적용할 준비를 할 수 있다... 2020. 2. 5. 테스트 주도 개발(Test-Driven Development:By Example) - 1부 : 화폐 예제 (9 ~ 10장) [9장] 우리가 사는 시간자, 그렇다면 통화 개념을 어떻게 구현하길 원하는가? 아차, 실수. 다시 해보자. 회초리가 나오기 전에 말을 바꿔야 겠다. 자, 그렇다면 통화 개념을 어떻게 테스트하길 원하는가? 됐다. 일단 매는 피했다.객체들이 필요한 만큼만 만들어지도록 하기 위해 경량 팩토리(flyweight factories)를 사용할 수 있을 것이다.우린 두 클래스를 모두 포함할 수 있는 동일한 구현을 원한다.이제 두 currency()가 동일하므로 변수 선언과 currency() 구현을 둘 다 위로 올릴(push up) 수 있게 됐다.정적 팩토리 메서드로 옮긴다면 두 생성자가 동일해질 것이고, 그렇다면 공통 구현을 만들 수 있을 것이다.보통 짧은 중단이 필요할 경우에 이를 흔쾌히 받아들이는 편이다. 물론.. 2020. 2. 4. 이전 1 2 3 4 다음