테스트 중심 개발 (TDD) 테스트는 항상 단위 테스트입니까?

나는 테스트 중심 개발을 이해하여 실패한 (빨간색) 단위 테스트가있을 때만 생산 코드를 작성할 수 있습니다. 이를 바탕으로 테스트 중심 접근 방식을 다른 형태의 테스트에도 적용 할 수 있는지에 대한 의문이 있습니다.

모든 TDD는 실패한 테스트를 작성한 다음 코드를 수정하여 통과하도록 요구합니다.

일반적으로 "단위 테스트"는 작고 빠르며 코드의 일부를 개별적으로 테스트합니다. 빠르기 때문에 빨강 / 녹색 / 리 팩터 루프도 빠릅니다. 그러나 부품을 단독으로 테스트하는 것만으로 어려움을 겪고 있습니다. 따라서 다른 테스트 (통합, 수락 등)도 필요합니다. 동일한 원칙을 따르는 것이 좋습니다. 실패한 테스트를 작성한 다음 코드를 수정하여 작동 시키십시오. 일반적으로 속도가 느리므로 빨강 / 녹색 / 리 팩터 사이클 시간에 영향을 줄 수 있습니다.

적색 녹색 리 팩터 사이클은 하나의 매우 건전한 원리에 기반합니다.

합격과 불합격을 모두 본 신뢰 테스트 만.

예, 자동화 된 통합 테스트에서도 작동합니다. 또한 수동 테스트. 자동차 배터리 테스터에서 작동합니다. 이것이 테스트를 테스트하는 방법입니다.

어떤 사람들은 단위 테스트를 테스트 할 수있는 가장 작은 것을 포함한다고 생각합니다. 일부는 테스트하기에 빠른 것을 생각합니다. TDD는 빨강 녹색 리 팩터 사이클 이상의 것이지만 그 부분에는 매우 특정한 테스트 세트가 있습니다. 변경 모음을 제출하기 전에 한 번 이상 실행하는 테스트는 아닙니다. 변경 할 때마다 실행되는 테스트입니다. 나에게, 그것은 당신의 단위 테스트입니다.

그러나 테스트 중심 접근 방식이 다른 형태의 테스트에도 적용될 수 있는지 궁금합니다.

그렇습니다.이를 수행하는 잘 알려진 접근 방식은 행동 중심 개발 입니다. BDD의 공식 스펙에서 생성 된 테스트는 "단위 테스트"라고 할 수 있지만 일반적으로 실제 TDD에서와 같이 낮은 수준은 아니지만 "수락 테스트"라는 용어에 더 적합 할 것입니다.

나는 테스트 중심 개발을 이해하여 실패한 (빨간색) 단위 테스트가있을 때만 생산 코드를 작성할 수 있습니다.

아닙니다. 테스트 메시지를 변경할 수있는 가장 간단한 코드 만 작성할 수 있습니다. 어떤 종류의 테스트에 대해서는 아무 것도 말하지 않습니다.

사실, 당신은 아마도 합격 기준에 대해 실패한 (적색) 합격 시험을 작성하는 것으로 시작할 것입니다.보다 정확하게는, 아마도 실패 할 수있는 가장 간단한 합격 시험을 작성합니다. 그런 다음 테스트를 실행하고 실패한 것을보고 올바른 이유로 실패했는지 확인하십시오. 그런 다음 해당 승인 기준의 일부 기능에 대해 실패한 기능 테스트를 작성하고 다시 실패, 실행, 실패를보고 올바른 이유로 실패했는지 검증 할 수있는 가장 간단한 기능 테스트를 작성합니다. 그런 다음 실패 할 수있는 가장 간단한 단위 테스트 인 실패한 단위 테스트를 작성하여 실패한 것을 확인하고 올바른 이유로 실패했는지 확인합니다.

이제 오류 메시지를 변경할 수있는 가장 간단한 프로덕션 코드를 작성합니다. 테스트를 다시 실행하고 오류 메시지가 변경되었고 올바른 방향으로 변경되었으며 코드가 올바른 이유로 메시지를 변경했는지 확인하십시오. (이상적으로, 오류 메시지는 이제 지나갔고 테스트는 통과해야하지만, 그렇지 않은 경우보다 한 번에 테스트를 통과 시키려고 시도하는 대신 메시지를 변경하는 작은 단계를 수행하는 것이 좋습니다. 그 이유입니다. 테스트 프레임 워크 개발자가 오류 메시지에 많은 노력을 기울이는 이유!)

단위 테스트를 통과하면 테스트 보호하에 생산 코드를 리팩터링합니다. (현재 승인 테스트 및 기능 테스트는 여전히 실패하지만, 단위 테스트에서 다루는 개별 단위 만 리팩토링하므로 괜찮습니다.)

이제 기능 테스트가 통과 할 때까지 다음 단위 테스트를 작성하고 위의 단계를 반복하십시오. 기능 테스트의 보호하에 이제 여러 장치에서 리팩토링을 수행 할 수 있습니다.

이 중간주기는 이제 승인 테스트가 통과 될 때까지 반복되며, 이제 전체 시스템에서 리팩토링을 수행 할 수 있습니다.

이제 다음 수락 기준을 선택하면 외부 사이클이 다시 시작됩니다.

TDD의 "발견 자"인 켄트 벡 ( "발명가"라는 용어는 마음에 들지 않으며, 사람들이이 모든 것을 함께 해왔으며 이름을 지어주고 책을 썼다)는 사진의 비유를 사용한다. 이것을 "확대 / 축소"라고합니다.

참고 : 항상 세 가지 수준의 테스트가 필요한 것은 아닙니다. 어쩌면 때로는 더 필요할 수도 있습니다. 더 자주, 당신은 덜 필요합니다. 기능이 작고 기능 테스트가 빠르면 단위 테스트없이 (또는 더 적은 단위 테스트로) 얻을 수 있습니다. 종종 승인 테스트와 단위 테스트 만 필요합니다. 또는 합격 기준이 너무 세밀하여 합격 시험 이 기능 시험입니다.

켄트 벡 (Kent Beck)은 빠르고, 작고, 집중적 인 기능 테스트를 가지고 있다면 먼저 단위 테스트를 작성하고 단위 테스트를 통해 코드를 구동 한 다음 코드를 포함하는 단위 테스트를 다시 삭제합니다 (일부). 빠른 기능 테스트에 포함됩니다. 테스트 코드는 유지 관리 및 리팩토링해야하는 코드이기도하며, 코드가 적을수록 좋습니다.

그러나 테스트 중심 접근 방식이 다른 형태의 테스트에도 적용될 수 있는지 궁금합니다.

테스트에 TDD를 실제로 적용하지는 않습니다. 전체 개발 프로세스에 적용합니다. 이것이 바로 Test- Driven -Development 의 "구동"부분이 의미하는 바입니다. 모든 개발은 테스트에 의해 주도됩니다. 테스트는 단지 그들은 또한 운전, 당신이 작성한 코드를 운전하지 무엇을 하는 코드를 다음 쓰기에 쓸 수있는 코드. 그들은 당신의 디자인을 운전합니다. 그들은 당신이 완료되면 알려줍니다. 다음에해야 할 일을 알려줍니다. 코드에서 디자인 결함에 대해 알려줍니다 (테스트하기 어려운 경우).

Keith Braithwaite는 TDD As If You Meant It 이라고하는 운동을 만들었습니다 . 그것은 엄격하게 따라야하고 TDD를보다 엄격하게 적용하도록 당신을 조종하도록 설계된 일련의 규칙 ( Bob Martin 삼촌의 TDD 규칙에 기반 하지만 훨씬 더 엄격함)으로 구성됩니다. 페어 프로그래밍 (페어가 규칙을 위반하지 않도록 할 수 있도록) 및 강사와 함께 사용하는 것이 가장 좋습니다.

규칙은 다음과 같습니다.

1. 솔루션의 방향을 가리키는 것으로 보이는 가장 작은 테스트를 정확히 하나만 작성하십시오.
2. 실패를 참조하십시오. 컴파일 실패는 실패로 계산
3. 테스트 방법에서 가능한 최소 구현 코드를 작성하여 (1)에서 테스트를 통과 하십시오 .
4. 중복을 제거하기 위해 리팩터링하고 그렇지 않으면 디자인을 개선하는 데 필요합니다. 이 동작을 사용하는 것에 대해 엄격해야합니다.
   1. 새로운 방법이 필요합니다. 리팩토링 시간까지 기다렸다가 다음 중 하나를 수행하여 테스트하지 않은 새로운 방법을 작성하십시오.
      • 선호 : 테스트 클래스에서 새 메소드를 작성하려면 (3)에 따라 작성된 구현 코드에서 메소드 추출을 수행하십시오.
      • 필요한 경우 : (3)에 따라 구현 코드를 기존 구현 방법으로 이동
   2. 새로운 클래스를 원합니다. 리팩토링 시간까지 기다렸다가… 테스트 방법 이외의 클래스를 만들어 Move Method의 목적지를 제공합니다.
   3. Move Method를 수행하여 다른 방법으로 구현 클래스를 메소드로 채 웁니다.

이 규칙은 TDD를 행사하기위한 것입니다. 실제로 프로덕션 환경에서 TDD를 수행하기위한 것은 아닙니다. 그들은 실제적인 진전을 이루지 않고 수천 개의 작은 작은 걸음을 내딛는 것처럼 보이기 때문에 좌절감을 느낄 수 있습니다.

TDD는 전통적인 소프트웨어 테스팅 커뮤니티가 "유닛 테스팅"이라고 부르는 것에 제한되지 않습니다. 이 매우 일반적인 오해는 KENT Beck의 TDD 실습을 설명 할 때 불행히도 "장치"라는 용어에 과부하가 걸린 결과입니다. 그가 "단위 테스트"라는 의미는 독립적으로 실행되는 테스트였습니다. 다른 테스트에 의존하지 않습니다. 각 테스트는 필요한 상태를 설정하고 완료되면 정리를 수행해야합니다. 이러한 의미에서 TDD 의미의 단위 테스트는 단위입니다. 자체 포함되어 있습니다. 자체적으로 실행되거나 다른 단위 테스트와 함께 임의의 순서로 실행될 수 있습니다.

참조 : Kent Beck의 "예제 별 테스트 주도 개발"

Kent Beck은 32 장 – TDD 마스터 링에서“단위 테스트”의 의미를 설명합니다.

나는 그것에 관한 책을 읽지 않았고 항상 "표준"TDD 관행을 완전히 따르지는 않지만, 제 생각에 TDD 철학의 요점은 당신이 먼저 성공을 정의해야한다는 것입니다. . "이 프로젝트의 목표는 무엇입니까?"에서 모든 수준의 디자인에 중요합니다. "이 작은 방법의 입력과 출력은 무엇이어야합니까?"

이 성공의 정의를 수행하는 방법에는 여러 가지가 있습니다. 특히 잠재적으로 많은 수의 엣지 사례가있는 저수준 방법에 유용한 방법은 코드로 테스트를 작성하는 것입니다. 추상화의 일부 수준에서는 모듈의 목표 또는 무엇이든에 대한 간단한 메모를 작성하거나 모든 것을 이해하고 정신적으로 자신을 확인하거나 동료에게 물어 보는 것이 유용 할 수 있습니다. 논리적 장소. 때로는 코드로 통합 테스트를 설명하는 것이 도움이되고 (물론 자동화하는 데 도움이 됨) 때로는 모든 시스템이 함께 작동하도록하는 데 사용할 수있는 합리적인 빠른 테스트 계획을 정의하는 것이 도움이 될 수 있습니다 기대하고 있습니다.

그러나 사용중인 특정 기술이나 도구에 관계없이 TDD 철학에서 벗어나야 할 핵심은 성공을 정의하는 것이 먼저 발생한다는 것입니다. 그렇지 않으면 다트를 던지고 불사조가 땅에 닿는 곳 어디에서나 페인트 칠을합니다.

대화에서 테스트 주도 개발 : 이것이 우리가 의미 한 것은 아닙니다. Steve Freeman은 TDD 큰 그림의 다음 슬라이드를 보여줍니다 (아래 이미지 참조). 여기에는 "실패한 엔드-투-엔드 테스트 작성" 단계와 " 실패한 유닛 테스트 작성"단계가 포함됩니다. (오른쪽 상단에 확대하려면 클릭)

따라서 TDD에서 테스트가 항상 단위 테스트는 아닙니다.

그리고 네, 첫 번째 단위 테스트를 작성하기 전에 실패하는 더 높은 수준의 엔드 투 엔드 테스트로 시작할 수 있습니다. 이 테스트는 달성하고자하는 행동을 설명합니다. 이것은 더 많은 레벨의 테스트 피라미드 에 적용 범위를 생성 합니다. Adrian Sutton 은 엔드 투 엔드 테스트가 크고 중요한 역할을 할 수 있음 을 보여주는 LMAX의 경험을 설명합니다 .

아니요, 간단한 실제적인 이유로 다른 종류의 테스트에는 적용 할 수 없습니다. 다른 유형의 테스트는 실행하는 데 너무 오래 걸립니다.

일반적인 TDD주기는 실패한 테스트 작성, 구현, 리 팩터 코드입니다. 그 사이의 단계는 테스트를 빌드하고 실행하는 것이며, 매우 빠르게 진행되어야합니다. 그렇지 않은 경우 사람들은 단계를 건너 뛰기 시작하고 더 이상 TDD를 수행하지 않습니다.