TDD에서 테스트중인 기능을 구현 한 사람이 테스트를 작성해야합니까?

Question

우리는 테스트 중심 개발로 해결하고자하는 프로젝트를 운영합니다. 프로젝트를 시작할 때 제기 된 몇 가지 질문에 대해 생각했습니다. 한 가지 질문은 다음과 같습니다. 기능의 단위 테스트를 작성해야하는 사람은 누구입니까? 기능 구현 프로그래머가 단위 테스트를 작성해야합니까? 또는 단위 테스트는 다른 프로그래머가 작성해야합니다. 프로그래머는 메소드가 수행해야하는 작업을 정의하고 기능 구현 프로그래머는 테스트가 실행될 때까지이 메소드를 구현해야합니다.
올바른 방법으로 TDD의 개념을 이해하면 기능 구현 프로그래머가 직접 테스트를 작성해야합니다. TDD는 미니 반복을 사용하는 프로 시저이기 때문입니다. 그래서 다른 프로그래머가 작성한 테스트를 수행하는 것은 너무 복잡할까요?
무엇을 말씀 하시겠습니까? TDD의 테스트는 프로그래머가 직접 작성해야합니까? 아니면 다른 프로그래머가 메소드가 수행 할 수있는 작업을 설명하는 테스트를 작성해야합니까?

Answer 1

TDD에서 개발자는 먼저 실패한 단위 테스트를 작성하고 테스트를 통과하기 위해 프로덕션 코드를 수정합니다. 아이디어는 실제로 작은 단계로 변경된다는 것입니다. 따라서 존재하지 않는 메소드를 호출하는 테스트를 작성한 다음 빈 메소드를 추가하여 테스트를 수정 한 다음 메소드에 대한 일부 어설 션을 추가하십시오 그래서 다시 실패합니다. 그런 다음 메서드의 첫 번째 잘라 내기 등을 구현합니다. 이러한 단계가 너무 작기 때문에 별도의 사람이 테스트를 작성하는 것이 현실적이지 않습니다. 다른 한편으로는, 나는 당신이 코드가 의미가 있는지 확인하는 몇 가지 추가 안구를 얻을 수 있도록, 페어링을 권장합니다.

다른 사람/팀/클라이언트 (피트니스와 같은 도구를 사용하는 경우)가 수용 테스트를 작성하고 상위 수준에서 전체 기능을 테스트 할 수 있다고 생각합니다.

Answer 2

단위 테스트는 코딩하기 전에 작성해야하며 단위가 요구 사항을 충족하는지 테스트해야하므로 코드를 구현하는 개발자가 단위 테스트를 작성하는 것이 좋습니다.

Answer 3

TDD의 장점 중 하나는 빠른 피드백주기입니다. 다른 개발자가 테스트를 작성하면 프로세스 속도가 느려집니다. 같은 개발자가 양쪽 모두를 작성해야합니다.

Answer 4

두 가지 방법으로 수행 할 수 있습니다. 직접 단위 테스트를 작성하거나 다른 개발자가 단위 테스트를 작성하고 쌍을 이루는 경우 구현을 작성하는 탁구 방식으로 진행할 수 있습니다. 올바른 솔루션은 귀하와 귀하의 팀에 적합한 솔루션입니다. 필자는 테스트를 직접 작성하는 것을 선호하지만 핑퐁 접근법과 관련하여 행운을 빕니다.

Answer 5

Justin의 답변에 따르면 구현 개발자가 테스트를 작성하는 것은 괜찮을뿐만 아니라 사실상의 표준입니다. 이론적으로 다른 프로그래머가 테스트를 작성하는 것도 허용됩니다. 필자는 "기능"개발자를 지원하는 "테스트"프로그래머라는 아이디어를 가지고 놀았지만 예제는 발견하지 못했습니다.

필자가 예상 한 입력과 출력 외에도 개체에 대한 테스트를 작성하면이 인터페이스가 노출되는 인터페이스를 알아야합니다. 다시 말해 개발중인 클래스와 메소드는 개발이 시작되기 전에 결정되어야합니다. 12 년 동안 나는 개발을 시작하기 전에 그 세분성을 달성 한 가게에서 한 번만 일했습니다. 나는 당신의 경험이 무엇인지 모르지만, 그것은 나에게 매우 민첩 해 보이지 않습니다.

Answer 6

자동화 된 단위 테스트를 테스트 기반 개발과 분리해야한다고 생각합니다. (IMHO 여기에서 중요한 구별을해야하는 것은 아닙니다.)

AUT는 TDD가 먼저 테스트를 작성해야한다고 강력히 권고합니다.

TDD는 또한 테스트를 필기 코드 프로세스의 필수 부분으로 만듭니다. TDD는 품질 보증의 방법이 아니라 코드에 대해 생각할 수있는 방법이므로 별도의 책임은 TDD의 철학에 위배됩니다. 그들은 또한 비실용적입니다. 새로운 테스트/새로운 코드 사이클은 대개 아주 짧습니다. 내 이해, 시험 구동 디자인 더 나은 설명이 될 것입니다.

AUT는 기존 코드 기반에 맞출 수 있지만 (코드베이스의 크기와 구조에 따라 다르긴하지만). 별도의 책임은 여기에 몇 가지 장점이 있습니다. 그럼에도 불구하고 AUT는 디자인에 약간의 압박을 가하고 있습니다 - 그래서 분리는 레벨을 입력하는 에있을 것입니다.

---

구별 : 나는 자유롭게 내가 TDD의 아이디어를 좋아하지 않는다는 것을 인정한다. 특정 시장에서 특정 응용 프로그램 용 코더의 특정 유형에 대해서는 잘 작동 할 수 있습니다. 그러나 지금까지 보았던 모든 예제, 데모 및 연습을 통해 저를 떨리게 만듭니다. OTOH, 저는 AUT가 품질 보증을위한 가치있는 도구라고 생각합니다. 하나 유용한 도구.

Answer 7

나는 조금 혼란스러워.

당신은 TDD를 사용하기를 원한다고 말하면 프로그래머가 테스트를 작성했다는 것을 정확히 이해하고있는 것처럼 보일 수 있습니다. 그런 다음 동일한 프로그래머가 테스트를 작성한 후 몇 초/몇 분 안에 구현을 작성합니다. 이것이 TDD의 정의의 일부입니다. (btw '동일한 프로그래머'는 쌍 프로그래밍을 연습 할 때 '쌍의 다른 프로그래머'를 의미합니다).

뭔가 다른 것을하고 싶다면 그것을 찾아 가서 블로그 나 기사에 경험을 적어 라.

당신이하지 말아야 할 것은 당신이하는 일이 TDD라고 말하는 것입니다.

'같은 프로그래머' 구현을 작성하고, 곧 테스트가 빠른 피드백의 목적을위한 후를 작성 하는 이유, 좋은 테스트를 작성하는 방법을 발견하고, 잘 소프트웨어를 설계하는 방법을하는 방법 좋은 구현을 작성하십시오.

The Three Rules Of Tdd을 참조하십시오.

Answer 8

단위 테스트 및 수락 테스트는 두 가지로 모두 TDD에서 수행 할 수 있습니다. 단위 테스트는 개발자의 입장에서 코드가 예상 한대로 수행되는지 확인하기 위해 작성됩니다. 수락 테스트는 고객의 관점에서 작성되어 코드가 적절한 필요를 충족시키는 지 확인합니다. 수락 테스트가 다른 사람 (보통 약간 다른 사고 방식과 도메인 지식을 필요로하기 때문에 그리고 병렬 처리가 가능하기 때문에)에 대해 많은 의미를 가질 수 있지만 단위 테스트는 개발자가 작성해야합니다.

TDD는 실패한 테스트에 대한 응답을 제외하고는 코드를 작성하면 안되므로 다른 사람이 Unit Tests를 작성하기를 기다리지 않으면 꽤 비효율적 인 것으로 보입니다.