원근법:
한 걸음 물러서서 TDD가 무엇을 도와 주려고하는지 물어 봅시다. TDD는 코드가 올바른지 판단하는 데 도움을 주려고합니다. 그리고 맞습니다. "코드가 비즈니스 요구 사항을 충족합니까?" 판매 포인트는 향후 변경이 필요하다는 것을 알고 있으며, 변경 한 후에도 코드가 올바르게 유지되도록하려는 것입니다.
세부 사항을 잃어 버리고 달성하려는 목표를 놓치기 쉽다고 생각하기 때문에 이러한 관점을 제시합니다.
원칙-SAP :
TDD의 전문가는 아니지만 단일 어설 션 원칙 (SAP)이 가르치려고하는 부분이 빠진 것 같습니다. SAP는 "한 번에 한 가지만 테스트"로 재구성 할 수 있습니다. 그러나 TOTAT는 SAP만큼 쉬운 방법은 없습니다.
한 번에 한 가지만 테스트하면 한 가지 경우에만 집중할 수 있습니다. 하나의 경로; 하나의 경계 조건; 하나의 오류 사례; 한 어떤 시험 당. 그리고 그 배후의 추진 아이디어는 테스트 사례가 실패했을 때 무슨 일이 일어 났는지 알아야하므로 문제를 더 빨리 해결할 수 있습니다. 테스트 내에서 여러 조건 (예 : 둘 이상의 것)을 테스트했는데 테스트가 실패하면 더 많은 작업이 필요합니다. 먼저 여러 사례 중 실패한 사례를 식별 한 다음 해당 사례가 실패한 이유를 파악해야합니다 .
한 번에 한 가지만 테스트하면 검색 범위가 훨씬 작아지고 결함이 더 빨리 식별됩니다. "한 번에 한 가지만 테스트"한다고해서 한 번에 둘 이상의 프로세스 출력을 볼 수있는 것은 아닙니다. 예를 들어, "알려진 올바른 경로"를 테스트 할 때 특정 결과 값 foo과 다른 값 을 볼 것으로 예상 할 수 있으며이를 테스트의 일부로 bar확인할 수 있습니다 foo != bar. 핵심은 테스트중인 사례에 따라 출력 검사를 논리적으로 그룹화하는 것입니다.
원칙-PMP :
마찬가지로, PMP (Private Method Principle)가 우리에게 무엇을 가르쳐야하는지에 대해 조금 빠져 있다고 생각합니다. PMP는 시스템을 블랙 박스처럼 취급하도록 권장합니다. 주어진 입력에 대해 주어진 출력을 가져와야합니다. 블랙 박스가 어떻게 출력을 생성하는지는 중요하지 않습니다. 출력이 입력과 정렬되도록주의하십시오.
PMP는 코드의 API 측면을 볼 때 정말 좋은 관점입니다. 또한 테스트해야 할 범위를 파악하는 데 도움이 될 수 있습니다. 인터페이스 포인트를 식별하고 계약 조건을 충족하는지 확인하십시오. 인터페이스 뒤 (일부 개인용) 방법이 어떻게 작동하는지는 신경 쓸 필요가 없습니다. 그들이해야 할 일을했는지 확인하면됩니다.
적용 TDD ( 귀하 )
따라서 상황은 일반적인 응용 프로그램을 넘어 약간의 주름을 나타냅니다. 앱의 메소드는 상태 저장이므로 출력은 입력뿐만 아니라 이전에 수행 된 작업에 따라 결정됩니다. 나는 <insert some lecture>끔찍한 상태에 대해 여기에 있어야한다고 확신 하지만, 그것은 당신의 문제를 해결하는 데 도움이되지 않습니다.
다양한 잠재적 상태와 전환을 트리거하기 위해 수행해야 할 작업을 보여주는 일종의 상태 다이어그램 테이블이 있다고 가정합니다. 그렇지 않은 경우이 시스템의 비즈니스 요구 사항을 표현하는 데 도움이되므로 필요합니다.
테스트 : 먼저 상태 변경을 시행하는 일련의 테스트로 끝납니다. 이상적으로는 발생할 수있는 전체 상태 변경 범위를 테스트하는 테스트가 있지만 그 정도까지 다룰 필요가없는 몇 가지 시나리오를 볼 수 있습니다.
다음으로 데이터 처리를 검증하기위한 테스트를 구축해야합니다. 이러한 상태 테스트 중 일부는 데이터 처리 테스트를 만들 때 재사용됩니다. 예를 들어, 및 상태에 Foo()따라 다른 출력을 갖는 메소드 가 있다고 가정하십시오 . " 가 "에 있을 때 출력을 테스트하기 위해 테스트를 설정 단계로 사용하려고합니다 .InitState1ChangeFooToState1Foo()State1
내가 언급하고 싶은 접근 방식에는 몇 가지 의미가 있습니다. 스포일러, 이곳은 내가 순수 주의자들을 화나게 할 곳입니다
우선, 어떤 상황에서는 무언가를 테스트로 사용하고 다른 상황에서는 셋업으로 사용한다는 것을 받아 들여야합니다. 한편으로 이것은 SAP를 직접 위반 한 것으로 보입니다. 그러나 논리적으로 ChangeFooToState1두 가지 목적을 가지고 있다고해도 여전히 SAP가 우리에게 가르치고있는 정신을 만나고 있습니다. Foo()변경 상태를 확인해야하는 ChangeFooToState1경우 테스트로 사용합니다. 그리고 "에 Foo()있을 때 State1" " 출력의 유효성을 검사해야 할 때 ChangeFooToState1설정으로 사용 하고 있습니다.
두 번째 항목은 실제적인 관점에서 시스템에 대해 완전히 무작위 화 된 단위 테스트를 원하지 않을 것입니다. 출력 유효성 검사 테스트를 실행하기 전에 모든 상태 변경 테스트를 실행해야합니다. SAP는 이러한 주문의 기본 원칙입니다. 명백한 사항을 설명하기 위해 테스트로 실패하면 무언가를 설정으로 사용할 수 없습니다.
함께 정리 :
상태 다이어그램을 사용하여 전환을 다루는 테스트를 생성합니다. 다시 다이어그램을 사용하여 상태에 의해 구동되는 모든 입력 / 출력 데이터 처리 사례를 포괄하는 테스트를 생성합니다.
이 방법을 따르면 bloated, complicated, long, and difficult to write테스트를 좀 더 쉽게 관리 할 수 있습니다. 일반적으로 결과는 더 작아야하고 더 간결해야합니다 (즉, 덜 복잡해야 함). 테스트가 더 분리되거나 모듈화되어 있음을 알아야합니다.
좋은 테스트를 작성하는 데 약간의 노력이 필요하기 때문에 프로세스가 완전히 고통받지 않을 것이라고 말하는 것은 아닙니다. 그리고 일부 경우에 두 번째 매개 변수 (상태)를 매핑하기 때문에 일부는 여전히 어려울 것입니다. 게다가, 상태 비 저장 시스템이 테스트를보다 쉽게 구축 할 수있는 이유는 조금 더 분명해야합니다. 그러나이 접근 방식을 응용 프로그램에 적용하면 응용 프로그램이 올바르게 작동하고 있음을 증명할 수 있습니다.