TDD 방법론에 따라 깨끗하고 간결하며 정확한 코드를 작성할 수 있습니다. 이 챕터에서는 기본 사항을 살펴보겠습니다.
일부 TDD 명명법 및 이름 지정 모범 사례가 이러한 테스트에 따라 수행되었습니다. 두 번째 테스트 라인별:
1.
func testAppModel_whenStarted_isInInProgressState() {
테스트 함수 이름에는 테스트가 설명되어야 합니다. 테스트 이름은 테스트 네비게이터 및 테스트 로그에 표시됩니다. 연속적인 통합 장치 안에서 실행되는 대형 테스트 제품군을 사용하면 테스트 실패만 보고 문제가 무엇인지 알 수 있습니다. 명명된 테스트를 생성하지 않음 test1, test2, 등
여기서 사용되는 명명 체계는 최대 네 부분으로 구성됩니다.
1.
모든 테스트는 다음에서 시작해야 합니다. test
.
2.
AppModelAppModel
이것은 다음과 같다.
테스트 대상 시스템(종료)입니다.
3.
whenStarted
테스트의 촉매인 상태 또는 상태 변화입니다.
4.
isInInProgressStatewhen
그 다음에 어떤 상태여야 하는지에 대한 주장입니다.
일어난다
또한 이 명명 규칙은 테스트 코드를 특정 조건에 초점을 맞추는 데 도움이 됩니다. 테스트 이름에서 자연스럽게 흐르지 않는 코드는 다른 테스트에 속합니다.
1.
let sut = AppModel()
이렇게 하면 테스트 대상 시스템의 이름을 지정하여 명시적으로 지정할 수 있습니다. sut. 이 시험은 시험이다. AppModelTests 테스트 케이스 서브클래스 그리고 이것은 에 대한 AppModel. 약간 중복될 수도 있지만, 멋지고 노골적이다.
1.
sut.start()
이것이 테스트해야 할 행동입니다. 이 경우 테스트는 언제 발생하는지를 다루고 있습니다. start() 라고 한다.
1.
let observedState = sut.appState
응용 프로그램 코드를 실행하는 동안 관찰한 값을 저장하는 속성을 정의합니다.
2.
XCTAssertEqual(observedSate, AppState.inProgress)
마지막 부분은 무슨 일이 있었는지에 대한 주장입니다. sut 처음 시작했을 때. 명기된 논리적인 주장은 다음과 직접 일치한다. XCTest 로 XCTAssert 기능들
이러한 시험 방법의 구분을 주어진/시/시라고 한다.
•
시험을 위한 첫 번째 부분은 주어지는 것이다.
그것이 시스템의 초기 상태이다.
•
두 번째 부분은 시스템에 작용하는 동작, 이벤트 또는 상태 변화입니다.
•
세 번째 부분, 또는 그 다음에 시기 이후에 예상되는 상태를 테스트하는 것입니다.
TDD는 프로세스이지 명명 규칙이 아닙니다. 이 책은 여기에 설명된 규칙을 사용하지만 원하는 이름을 사용하여 TDD를 따를 수 있습니다. 중요한 것은 쓰기 실패 테스트, 테스트 합격 코드 추가, 애플리케이션이 완료될 때까지 리팩터 및 반복합니다.