Quick and Nimble을 사용하는 것은 BDD 코드에 대한 강력한 지원이지만, 이것은 도구일 뿐이며, 모든 것을 XCTEst로 작성할 수 있다는 것을 기억하십시오.공구를 공구로 삼아라, 정말.BDD가 당신의 태도를 격려하는 것에 주의하세요.

소개하다.

iOS의 BDD는 제목에 의도적으로 사용되는 이중관어를 제외하고는 더 빨리 작동하는 방법이다.또는 더 빠르지 않을 수도 있지만 iOS 개발에서 일정한 속도를 유지하는 것이 무통 개발을 실현하는 방식이다.본고에서 저는 행위 구동의 개발, 그에 대한 신속한 이론 소개, 그리고 몇 가지 전형적인 장면에서quick and Limble를 사용하여 진행한 실천 시범을 소개하고자 합니다.자, 시작합시다.

의사 일정

BDD란 무엇입니까?

BDD와 TDD의 관계는 어떻습니까?

XCTEst 구문의 질문

신속(유연)구조!

확장 유연성

결론

BDD란?

Cucumber docs에 따르면 BDD는 "소프트웨어 팀이 업무 인원과 기술자 간의 격차를 줄이는 일종의 업무 방식이다[...]우리는 협업 업무의 중점을 구체적이고 진실한 예에 두어 이 점을 실현한다. 이런 예들은 우리가 시스템을 어떻게 운영하기를 원하는지 설명한다."
따라서 보다 구체적인 방법으로

우리는 사용자 이야기에서 정의한 검수 기준부터 시작한다.

승인 기준에서 실제 세계의 예제를 정의하기 위해 템플릿 "[초기 상태]를 [이벤트]로 지정하고 [최종 상태]로 정의합니다.

일반적으로 DSL을 사용하여 승인 기준을 시스템 실행 코드로 변환합니다.

BDD랑 TDD랑 무슨 상관이야?

BDD와 TDD는 예상 결과를 정의하는 것에서 시작하고 코드를 작성하기 전에 예상 결과를 테스트하는 방법과 비슷하다.차이점은 그들이 예상한 결과를 어떻게 정의하는가에 있다.
TDD에서는 다음과 같은 테스트를 작성했습니다.

func test_userHasBeenSaved() {
    // Arrange
    let userRepository = UserRepository(mode: .inMemory)
    userRepository.deleteAll()
    userRepository.populateTestUsers()
    let currentUsersCount = usersRepository.currentCount

    // Act
    let user = User()
    user.email = "[email protected]"
    userRepository.save(user)

    // Assert
    XCTAssertEqual(
        usersRepository.currentCount, 
        currentUsersCount + 1,
        "The users count should have increased in one."
    )
}

TDD의 일반적인 테스트입니다.구조Arrange - Act - Assert에 따라 초기 setuo(Arrange)를 만들고 동작(Act)을 실행한 다음 최종 상태가 우리가 원하는 상태(Assert)인지 확인합니다.
BDD에서는 과정이 유사하지만 우리가 주목하는 것은 응용 프로그램 행위이지 대상 상태가 아니다.
BDD 방법을 사용하여 예제를 검토합니다.

func test_userHasBeenSaved() {
    // Arrange
    let userRepository = UserRepository(mode: .inMemory)
    userRepository.deleteAll()
    userRepository.populateTestUsers()

    // Act
    let user = User()
    user.email = "[email protected]"
    userRepository.save(user)

    // Assert
    XCTAssertNotNil(
        usersRepository.findOne(email: "[email protected]"),
        "The user we have saved should be recoverable."
    )
}

면책 성명: 이 예는 거의 완전히 Quick documentation에서 추출한 것이니 강력히 추천합니다.

질문

이전 예는 유효하며 원래대로 사용할 수 있다.더 중요한 것은 대다수의 사람들이 그것을 사용하고 그들에게 효과가 있다는 것이다.그럼, 그것은 무슨 문제가 있습니까?설마 우리가 그것을 사용해서 방해를 멈춰야 하는 것은 아니겠지?
그래, 너도 나와 같고, 더 좋은 방법이 있을 거라고 의심한다면, 개선할 수 있는 것들을 알려줄게.

BDD는 검수 기준을 바탕으로 해야 하고 업무 인원과 상호작용하는 방법이어야 하기 때문에 XCTEst 문법은 기계를 대상으로 하는 것이지 사람을 대상으로 하는 것이 아니다.

XCTEst에서 서로 다른 관련 장면을 묘사하기 어렵다.같은 테스트를 하고 싶지만 조건이 다르다고 가정해 보세요.XTest에서 이렇게 하는 것이 가장 즐거운 체험이 아니거나 적어도 부자연스럽다고 느끼는 것은 아니다.

테스트를 작성한 후 테스트가 의미가 있습니다.분명히 코드를 작성하는 순서는 다음과 같다. 너는 이렇게 생각할 수 있다.

내가 해결 방안을 보여줄게.🙌

신속(민첩) 구원!

언뜻 보기에, 이전 테스트는 어떻게 신속하고 유연하게 작성되었는가:

describe("Given the User repository") {
    var userRepository: UserRepository!

    beforeEach {
        userRepository = UserRepository(mode: .inMemory)
    }

    context("When a user is saved") {
        beforeEach {
            userRepository.deleteAll()
            userRepository.populateTestUsers()

            let user = User()
            user.email = "[email protected]"
            userRepository.save(user)
        }

        it("Should be recoverable") {
            let recoveredUser = usersRepository.findOne(
                email: "[email protected]"
            )

            expect(recoveredUser).toNot(beNil())    
        }
    }
}

그럼, 이것은 무엇입니까?

Quick은 이러한 테스트를 위한 구조를 제공하는 라이브러리입니다.다음과 같은 세 가지 주요 기능이 있습니다.

describe 모듈 또는 모듈 내부의 기능을 설명합니다.이것은 네가 테스트에 추가해야 할 가장 중요한 함수다.이것은 검수 표준에서 제시한 표준이다.

context 모듈의 특정 장면을 설명하는 데 사용됩니다.이것은 검수 기준 중의 시간이다.

it 마지막으로 이 장면의 테스트 용례를 설명하는 데 사용한다.이것은 검수 기준 중 가장 중요한 부분이다.

Quick은 beforeach 함수와 afterEach 함수도 제공합니다.범위 내의 모든 하위 규범이 실행되기 전이나 이후에 실행될 수 있도록 테스트 중인 모든 단계에서 호출할 수 있습니다.

민첩함은 빠른 속도와 함께 오는 매칭기다.

함수에 일치하는 요소를 입력합니다.expect 함수가 유효한지 알고 싶다면, 언제 sum 같은 것을 쓸 수 있습니까?

구성expect(sum(2 + 2)) 기능은 특정 컨텐츠와 일치해야 합니다.너는 쓰기expect나 .to(...)를 통해 실현할 수 있다.

마지막으로 오른쪽.toNot(...)/to에 기대치를 설정합니다.

함수의 한 예는toNot이다.

다시 한 번 주의하십시오. 당신은 모든 빠른 코드를 작성할 수 있으며, 어떠한 유연한 코드도 작성할 필요가 없습니다.
예를 들어, 이 코드는 완전히 유효합니다.

describe("Given the User repository") {
    context("When a user is saved") {
        it("Should be recoverable") {}
    }
}

QA 또는 업무 담당자와 대화를 나누고 기능을 정의할 때 의미가 있습니다.

연장이 민첩하다

민첩함은 매우 좋은 도구다.더 놀라운 것은 맞춤형 매칭기를 통해 그것을 확장할 수 있다는 것이다.사용자 정의 매칭기를 작성하는 가장 기본적인 방법을 찾아보자.만약 우리가 하나의 숫자가 홀수인지 짝수인지 검사하기 위해 일치기가 필요하다고 가정한다면.

func beOdd() -> Predicate<Int> {
    return Predicate<Int>.simple("be odd") { actual in
        let value = try actual.evaluate()!
        return PredicateStatus(bool: value % 2 == 1)
    }
}

func beEven() -> Predicate<Int> {
    return Predicate<Int>.simple("be even") { actual in
        let value = try actual.evaluate()!
        return PredicateStatus(bool: value % 2 == 0)
    }
}

간단하죠?
주어진 sum 이런 표현식은 expect(sum(2 + 2)).to(equal(4))의 일반 매개 변수가 표현식 유형이다.
위의 예에서 우리는 expect(EXPRESSION).to(PREDICATE) 표현식과 간단한 테스트를 일치시킬 것이다.예시의 테스트는 매우 간단하다. 우리는 단지 Predicate<T> 2로 정제될 수 있는지 검사할 뿐이지만, 이 Int 함수를 사용해도 훨씬 복잡할 수 있다.
마지막으로 EXPRESSION/simple 표현식이 일치하지 않을 때의 오류를 설명합니다.

테스트 코드의 가독성을 높일 수 있다면 맞춤형 유연 매칭기를 사용하세요.어떤 걸음이든지 자연을 느낄 필요가 있다.

결론

BDD는 자연스럽고 읽기 쉬운 방식으로 코드를 작성하고 행위를 정의하는 기술/업무 상호작용에 관한 것이다.