TDD와 함께 그렇습니다 (몇 가지 예외가 있음)

논란의 여지가 있지만, 나는이 질문에 ‘아니오’라고 대답하는 사람은 TDD의 기본 개념이 누락되었다고 주장합니다.

나를 위해, 대답은 울려 퍼지는이다 예 는 TDD를 수행합니다. 그렇지 않다면 그럴듯한 대답은 없습니다.

TDD의 DDD

TDD는 종종 주요 이점이 있다고 인용됩니다.

• 방어
  • 코드가 변경 될 수 있지만 동작 은 변경 되지 않는지 확인하십시오 .
  • 이것은 리팩토링의 매우 중요한 관행을 허용합니다 .
  • 이 TDD를 얻거나 얻지 못합니다.
• 디자인
  • 당신은 지정 이 작동하는 방법, 뭔가해야 할 일 구현하기 전에 그것을.
  • 이것은 종종보다 현명한 구현 결정을 의미 합니다.
• 문서
  • 테스트 스위트는 사양 (요구 사항) 문서 로 사용되어야합니다 .
  • 그러한 목적으로 테스트를 사용한다는 것은 문서와 구현이 항상 일관된 상태임을 의미합니다. 하나의 변경은 다른 변경을 의미합니다. 별도의 워드 문서에서 요구 사항과 디자인을 유지하는 것과 비교하십시오.

구현과 별도의 책임

프로그래머로서, 속성을 중요하고 게터로 생각하고 일종의 오버 헤드로 세터를 생각하는 것은 대단히 유혹적입니다.

그러나 속성은 구현 세부 사항이며 세터와 게터는 실제로 프로그램을 작동시키는 계약 인터페이스입니다.

객체가 다음과 같이 철자를 작성하는 것이 훨씬 더 중요합니다.

클라이언트가 상태를 변경하도록 허용

과

클라이언트가 상태를 쿼리하도록 허용

그런 다음이 상태가 실제로 저장되는 방법 (속성이 가장 일반적이지만 유일한 방법은 아닙니다).

다음과 같은 테스트

(The Painter class) should store the provided colour

TDD 의 문서 부분에 중요합니다 .

테스트를 작성할 때 최종 구현이 사소한 (속성) 방어 이점 이 없다는 사실을 알 수 없습니다.

왕복 공학의 부족 …

시스템 개발 세계의 주요 문제 중 하나는 왕복 공학 의 부족입니다. ^1- 시스템의 개발 프로세스가 분리 된 하위 프로세스로 분할됩니다 (문서, 코드).

_{¹ Brodie, Michael L. “John Mylopoulos : 개념적 모델링의 씨앗 봉제.” 개념 모델링 : 기초 및 응용. Springer Berlin Heidelberg, 2009. 1-9.}

… 그리고 TDD가이를 해결하는 방법

시스템 및 해당 코드의 스펙이 항상 일관되도록 TDD 의 문서 부분입니다.

먼저 디자인하고 나중에 구현

TDD 내에서 먼저 합격 합격 테스트를 작성한 다음 통과시키는 코드 만 작성하십시오.

높은 수준의 BDD 내에서 시나리오를 먼저 작성한 다음 통과시킵니다.

왜 세터와 게터를 제외해야합니까?

이론적으로 TDD 내에서 한 사람이 테스트를 작성하고 다른 사람이 테스트를 통과시키는 코드를 구현할 수 있습니다.

스스로에게 물어보십시오.

클래스에 대한 테스트를 작성하는 사람이 getter 및 setter를 언급해야합니다.

getter와 setter는 클래스에 대한 공용 인터페이스이므로 대답은 명백히 yes 이거나 객체의 상태를 설정하거나 쿼리 할 방법이 없습니다.

분명히 코드를 먼저 작성하면 답이 명확하지 않을 수 있습니다.

예외

이 규칙에는 명백한 구현 세부 사항이며 시스템 설계의 일부가 아닌 기능인 몇 가지 명백한 예외가 있습니다.

예를 들어 로컬 메소드 ‘B ()’:

function A() {

    // B() will be called here

    function B() {
        ...
    }
}

또는 square()여기 개인 기능 :

class Something {
private:
    square() {...}
public:
    addAndSquare() {...}
    substractAndSquare() {...}
}

또는 public시스템 구성 요소 설계에서 철자를 필요 로하는 인터페이스의 일부가 아닌 다른 기능 .

---

답변