켄트 벡(Kent Beck)23 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (부록 + 마치는 글) (끝) [부록A] 영향도(influence diagram) 영향도의 목적은 한 시스템의 요소들이 서로 어떻게 영향을 끼치는지 보는 것이다. 세가지 요소 -활동 -양적 연결 -음적 연결 영향이 한 방향으로만 작용하지는 않는다. 특정 활동의 결과가 거꾸로 그 활동 자체에 양적, 혹은 음적으로 영향을 미치는 경우가 자주 있다. 시스템 설계의 핵심은 다음과 같다. -양적 피드백 루프가 좋은 활동의 성장을 촉진하는 선순환 만들기 -양적 피드백 루프가 비생산적이거나 파괴적인 활동의 성장을 촉진하는 죽음의 나선 피하기 -좋은 활동의 과용을 예방하는 음적 피드백 주기 만들기 제대로 작용하지 않는 시스템이 있을 때, 다음과 같은 옵션이 있다. -반대 방향으로 양적 피드백 루프가 돌게 하라. 테스트와 자신감 사이에 루프가 있고 .. 2020. 2. 21. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (32장) [32장] TDD 마스터하기 단계가 얼마나 커야 하나? -각 테스트가 다뤄야 할 범위는 얼마나 넓은가? -리팩토링을 하면서 얼마나 많은 중간 단계를 거쳐야 하는가? 시간이 지남에 따라 테스트 주도 개발자의 경향은 분명히 나타난다. 단계가 점점 작아지는 것이다. 자동화된 리팩토링 툴은 리팩토링을 엄청나게 가속화시킨다. 훌륭한 툴의 지원이 있다는 걸 알고 있다면 코드가 어떤 구조를 갖추길 원하는지 보기 위해 여러 가지 실험을 시도하면서 리팩토링에 훨씬 적극적이게 될 것이다. 테스트할 필요가 없는 것은 무엇인가? “두려움이 지루함으로 변할 때까지 테스트를 만들어라.” 다음 것들을 테스트해야 한다. -조건문 -반복문 -연산자 -다형성 당신이 작성하는 것들에 대해서만 테스트해라. 불신할 이유가 없다면 다른 살마이.. 2020. 2. 20. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (31장) [31장] 리팩토링 TDD에서는 리팩토링을 특이한 방법으로 사용한다. 일반적으로 리팩토링은 어떤 상황에서도 프로그램의 의미론을 변경해서는 안 된다. 하지만 TDD에서 우리가 신경 쓰는 부분은 현재 이미 통과한 테스트들뿐이다. 예를 들어 TDD에서는 상수를 변수로 바꾸고 양심에 거리낌 없이 이를 리팩토링이라고 부른다. 왜냐하면 이 행위가 통과하는 테스트의 집합에 아무 변화도 주지 않기 때문이다. ‘관측상의 동치성’이 성립되려면 충분한 테스트를 가지고 있어야 한다. 충분한 테스트란, 현재 가지고 있는 테스트들에 기반한 리팩토링이 추측 가능한 모든 테스트에 기반한 리팩토링과 동일한 것으로 여겨질 수 있는 상태를 말한다. 추론 과정이 길어지면 지금 고치려고 하는 부분이 결과에 영향을 주지 않을 거라고 믿어버리는.. 2020. 2. 19. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (30장) [30장] 디자인 패턴 패턴의 주요한 통찰이 하나 있으니, 우리가 언제나 완전히 다른 문제들을 해결하는 것 같지만 우리가 푸는 문제 대다수는 사용하는 도구에 의해 생기는 것이지 직면한 외부의 문제 때문에 생기는 것이 아니라는 점이다. 이런 이유로, 심지어 외부적 문제 해결 컨텍스트가 엄청나게 다양하더라도 공통의 해결책을 가진 공통의 문제를 발견할 것을 기대할 수 있다. 디자인 패턴의 엄청난 성공은 객체 프로그래머들이 보는 공통성에 대한 증거다. TDD에서는 설계를 디자인 패턴과는 조금 다른 관점으로 본다. -커맨드:계산 작업에 대한 호출을 메시지가 아닌 객체로 표현한다. -값 객체:객체가 생성된 이후 그 값이 절대로 변하지 안헥 하여 별칭 문제가 발생하지 않게 한다. -널 객체:계산 작업의 기본 사례를 .. 2020. 2. 18. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (29장) [29장] xUnit 패턴 불리언(boolean) 수식을 작성해서 여러분 대신 프로그램이 자동으로 코드가 동작하는지에 대한 판단을 수행하도록 하라. 테스트를 완전히 자동화하려면 결과를 평가하는 데 개입되는 인간의 판단을 모조리 끄집어내야 한다. 버튼을 누르면 컴퓨터가 실행하는 코드의 작동이 올바른지 검증하는 데 필요한 모든 판단이 되어야 하는 것이다. -판단 결과가 불리언 값이어야 한다. 일반적으로 참 값은 모든 테스트가 통과했음을 의미하고, 거짓 값은 뭔가 예상치 못했던 일이 발생했음을 의미한다. -이 불리언 값은 컴퓨터에 의해 검증되어야 한다. 단언은 구체적이어야 한다. 코드가 제대로 작동하는지를 판다낳기 위한 용도로 변수를 사용하길 원한다면 언제나 설계를 향상할 수 있는 기회가 있다. 하지만 두려움.. 2020. 2. 17. 테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (28장) [28장] 초록 막대 패턴 코드가 테스트를 통과하게 만들기 위해 이 패턴을 사용하라. 실패하는 테스트를 만든 후 첫 번째 구현은 어떻게 하는 게 좋을까? 상수를 반환하게 하라. 일단 테스트가 통과하면 단계적으로 상수를 변수를 사용하는 수식으로 변형한다. -심리학적:확신을 갖고 거기부터 리팩토링해 갈 수 있다. -범위 조절:하나의 구체적인 예에서 시작해서 일반화하게 되면, 쓰잘데기 없는 고민으로 때 이르게 혼동하는 일을 예방할 수 있다. 추상화 과정을 테스트로 주도할 때 어떻게 최대한 보수적으로 할 수 있겠는가? 오로지 예가 두 개 이상일 때에만 추상화를 하라. 삼각측량이 매력적인 이유는 그 규칙이 매우 명확하기 때문이다. 나는 어떤 계산을 어떻게 해야 올바르게 추상화할 것인지에 대해 정말 감잡기 어려울 .. 2020. 2. 16. 이전 1 2 3 4 다음