iOS 테스트 / 사양 TDD / BDD 및 통합 및 수락 테스트
iPhone의 행동 중심 개발에 가장 적합한 기술은 무엇입니까? 이러한 기술의 올바른 사용법을 보여주는 오픈 소스 예제 프로젝트는 무엇입니까? 내가 찾은 몇 가지 옵션은 다음과 같습니다.
단위 테스트
테스트 :: 단위 스타일
- iOS 개발 가이드 : 단위 테스트 애플리케이션 및 기타 OCUnit 참조에 설명 된대로 OCUnit / SenTestingKit .
- 예 : iPhoneUnitTests , Three20
- 잡기
- GH 단위
- Mac 용 Google 툴박스 : iPhone 단위 테스트
RSpec 스타일
- 키위 (모의 및 기대와 함께 제공)
- 삼나무
- 재스민 과 UI 자동화 와 같이 교묘 한 '아이폰 OS - 수용 - 테스트 사양
수락 테스트
셀레늄 스타일
UI 자동화 (장치에서 작동)
- UI 자동화 기기 안내서
- UI 자동화 참조 문서
- Tuneup js -UIAutomation과 함께 사용하기위한 멋진 라이브러리.
-
UI 자동화 를 위해 Cucumber (JavaScript로 작성) 를 사용할 수 있습니다 . 이것은 훌륭한 오픈 소스 프로젝트입니다. 그런 다음 Gherkin 을 작성 하여 UI 자동화 테스트를 실행할 수 있습니다. 지금은 Gherkin을 주석으로 작성하겠습니다.
업데이트 : Zucchini Framework 는 Cucumber와 UI 자동화를 혼합 한 것 같습니다! :)
오래된 블로그 게시물 :
UISpecRunner를 사용한 UISpec
오이 스타일
Frank 와 iCuke ( Cucumber를 기반으로 한 iPhone 토크를 만나다 )
- 프랭크 Google 그룹은 보다 훨씬 더 많은 활동이 iCuke Google 그룹을 .
- Frank는 기기와 시뮬레이터 모두에서 실행되며 iCuke는 시뮬레이터에서만 실행됩니다.
- Frank는 iCuke의 단계 정의 보다 더 포괄적 인 단계 정의 세트를 가지고있는 것 같습니다 . 또한 Frank는 Wiki에서 단계 정의 개요를 가지고 있습니다.
- iOS와 같은 공통 목표를 가지고 있기 때문에 iCuke & Frank (Merb & Rails의 병합 방식과 유사)를 병합 할 것을 제안했습니다 .
Zucchini Framework 는 테스트 작성에 Cucumber 구문을 사용하고 단계 정의에 CoffeeScript를 사용합니다.
추가
- 조롱을 위한 OCMock
- OCHamcrest 및 / 또는 Expecta 기대에 대한
결론
글쎄, 분명히이 질문에 대한 정답은 없지만 다음은 현재 내가 선택하고있는 것입니다.
단위 테스트를 위해 XCode 4에서 OCUnit / SenTestingKit 을 사용했습니다 . 간단하고 견고합니다. 그러나 나는 우리의 단어가 세상을 창조하기 때문에 TDD 보다 BDD 언어를 선호합니다 ( RSpec이 Test :: Unit보다 왜 낫 습니까? 이제 ARC & Kiwi 코드 완성 / 자동 완성 과 함께 Kiwi를 사용 합니다. 나는 OCUnit 위에 빌드되고 RSpec 스타일 매처 및 모의 / 스텁과 함께 제공되므로 Cedar보다 Kiwi를 선호합니다. 업데이트 : 현재 OKIock을 조사 중입니다. 현재 키위는 수신자 부담없는 브리지 된 객체를 지원하지 않기 때문 입니다.
승인 테스트를 위해 UI 자동화는 훌륭하기 때문에 사용합니다. 각 테스트 사례를 기록하여 쓰기 테스트를 자동으로 수행 할 수 있습니다. 또한 Apple은이를 개발하여 미래를 약속합니다. 또한 장치 및 기기에서 작동하므로 메모리 누수 표시와 같은 다른 멋진 기능을 사용할 수 있습니다. 불행히도 UI 자동화를 사용하면 Objective-C 코드를 실행하는 방법을 모르지만 Frank & iCuke를 사용하면 가능합니다. 따라서 단위 테스트를 사용하여 하위 레벨 Objective-C 항목을 테스트하거나 빌드 구성에UIButton 대해서만을 작성하여 클릭하면 Objective-C 코드를 실행합니다.TEST
어떤 솔루션을 사용하십니까?
관련 질문
- 현재 iOS4 및 Xcode4에서 잘 작동하는 BDD 솔루션이 있습니까?
- 단위 테스트를 위해 XCode 4의 SenTestingKit (XCode와 통합) 대 GHUnit?
- OCunit을 사용하여 iOS에서 비동기 코드 테스트
- Xcode 4의 SenTestingKit 4 : 비동기 테스트?
- iPhone의 단위 테스트는 어떻게 작동합니까?
tl; dr
Pivotal에서는 Ruby 프로젝트에서 Rspec을 사용하고 좋아하기 때문에 Cedar를 작성했습니다. 삼나무는 OCUnit을 대체하거나 경쟁하기위한 것이 아닙니다. Rspec이 Ruby에서 BDD 스타일 테스트를 개척 한 것처럼 Test :: Unit을 제거하지 않은 것처럼 BDD 스타일 테스트를 Objective C에 제공 할 수 있습니다. 하나 또는 다른 것을 선택하는 것은 스타일 선호의 문제입니다.
어떤 경우에는 OCUnit이 우리를 위해 일하는 방식에서 몇 가지 단점을 극복하도록 Cedar를 설계했습니다. 특히 테스트에서 디버거를 사용하고 명령 줄과 CI 빌드에서 테스트를 실행하고 테스트 결과의 유용한 텍스트 출력을 얻을 수 있기를 원했습니다. 이러한 것들이 당신에게 다소 유용 할 수 있습니다.
긴 대답
Cedar와 OCUnit과 같은 두 가지 테스트 프레임 워크 사이에서 결정하는 것은 선호하는 스타일과 사용 편의성이라는 두 가지로 나뉩니다. 스타일과 함께 시작하겠습니다. 이는 단순히 의견과 선호의 문제이기 때문입니다. 사용 편의성은 일련의 트레이드 오프 인 경향이 있습니다.
스타일 고려 사항은 사용하는 기술이나 언어를 초월합니다. xUnit 스타일 단위 테스트는 BDD 스타일 테스트보다 훨씬 오래 지속되었지만 후자는 Rspec으로 인해 빠르게 인기를 얻었습니다.
xUnit 스타일 테스트의 주요 장점은 단순성과 폭 넓은 채택 (단위 테스트를 작성하는 개발자 중)입니다. 코드 작성을 고려할 수있는 거의 모든 언어에는 xUnit 스타일 프레임 워크가 있습니다.
BDD 스타일 프레임 워크는 xUnit 스타일과 비교할 때 테스트 (또는 스펙)를 구성하는 방법과 어설 션을 작성하는 구문의 두 가지 주요 차이점이 있습니다. 저에게는 구조적 차이가 주요 차별화 요소입니다. xUnit 테스트는 주어진 테스트 클래스의 모든 테스트에 대해 하나의 setUp 메소드가있는 1 차원입니다. 그러나 우리가 테스트하는 클래스는 1 차원이 아닙니다. 우리는 종종 서로 상충되는 여러 상황에서 행동을 테스트해야합니다. 예를 들어 addItem : 메소드가 포함 된 간단한 ShoppingCart 클래스를 생각해보십시오 (이 답변의 목적을 위해 Objective C 구문을 사용하겠습니다). 이 방법의 동작은 카트가 비어있을 때와 카트에 다른 항목이있을 때와 다를 수 있습니다. 사용자가 할인 코드를 입력 한 경우 다를 수 있습니다. 지정된 품목이 가능하면 다를 수 있습니다. 선택한 배송 방법으로 배송되지 않습니다. 이러한 가능한 조건들이 서로 교차 할 때, 당신은 기하학적으로 증가하는 가능한 맥락의 수로 끝납니다. xUnit 스타일 테스트에서 종종 testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies와 같은 이름을 가진 많은 메소드가 생성됩니다. BDD 스타일 프레임 워크의 구조를 사용하면 이러한 조건을 개별적으로 구성 할 수 있으므로 모든 사례를 쉽게 다루고 개별 조건을 쉽게 찾고 변경하거나 추가 할 수 있습니다. 예를 들어 Cedar 구문을 사용하면 위의 방법은 다음과 같습니다. xUnit 스타일 테스트에서 종종 testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies와 같은 이름을 가진 많은 메소드가 생성됩니다. BDD 스타일 프레임 워크의 구조를 사용하면 이러한 조건을 개별적으로 구성 할 수 있으므로 모든 사례를 쉽게 다루고 개별 조건을 쉽게 찾고 변경하거나 추가 할 수 있습니다. 예를 들어 Cedar 구문을 사용하면 위의 방법은 다음과 같습니다. xUnit 스타일 테스트에서 종종 testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies와 같은 이름을 가진 많은 메소드가 생성됩니다. BDD 스타일 프레임 워크의 구조를 사용하면 이러한 조건을 개별적으로 구성 할 수 있으므로 모든 사례를 쉽게 다루고 개별 조건을 쉽게 찾고 변경하거나 추가 할 수 있습니다. 예를 들어 Cedar 구문을 사용하면 위의 방법은 다음과 같습니다.
describe(@"ShoppingCart", ^{
describe(@"addItem:", ^{
describe(@"when the cart is empty", ^{
describe(@"with no discount code", ^{
describe(@"when the shipping method applies to the item", ^{
it(@"should add the item to the cart", ^{
...
});
it(@"should add the full price of the item to the overall price", ^{
...
});
});
describe(@"when the shipping method does not apply to the item", ^{
...
});
});
describe(@"with a discount code", ^{
...
});
});
describe(@"when the cart contains other items, ^{
...
});
});
});
경우에 따라 동일한 어설 션 세트가 포함 된 컨텍스트를 발견 할 수 있으며, 공유 예제 컨텍스트를 사용하여 건조 할 수 있습니다.
BDD 스타일 프레임 워크와 xUnit 스타일 프레임 워크의 두 번째 주요 차이점 인 어설 션 (또는 "매칭 기") 구문은 스펙의 스타일을 약간 더 멋지게 만듭니다. 어떤 사람들은 정말로 그것을 좋아하고 어떤 사람들은 그렇지 않습니다.
그것은 사용하기 쉽다는 문제로 이어진다. 이 경우 각 프레임 워크에는 장단점이 있습니다.
OCUnit은 Cedar보다 훨씬 길 었으며 Xcode에 직접 통합되었습니다. 즉, 새로운 테스트 대상을 만드는 것이 간단하며 대부분 테스트를 수행하고 "정상 작동"하는 것입니다. 반면에 iOS 기기에서 실행하는 등 일부 경우에는 OCUnit 테스트를 수행하는 것이 거의 불가능하다는 것을 알았습니다. Cedar 사양을 설정하려면 라이브러리를 가져 와서 직접 링크하기 때문에 OCUnit 테스트보다 더 많은 작업이 필요합니다 (Xcode의 사소한 작업은 아닙니다). 우리는 설정을 더 쉽게하기 위해 노력하고 있으며 어떤 제안이라도 환영합니다.
OCUnit은 빌드의 일부로 테스트를 실행합니다. 즉, 테스트를 실행하기 위해 실행 파일을 실행할 필요가 없습니다. 테스트가 실패하면 빌드가 실패합니다. 이를 통해 테스트 실행 프로세스가 한 단계 더 간단 해지고 테스트 출력이 빌드 출력 창으로 직접 이동하여 쉽게 볼 수 있습니다. 우리는 몇 가지 이유로 별도로 실행되는 Cedar 사양을 실행 파일로 빌드하도록 선택했습니다.
- 우리는 디버거를 사용할 수 있기를 원했습니다. 다른 실행 파일을 실행하는 것처럼 Cedar 사양을 실행하므로 같은 방식으로 디버거를 사용할 수 있습니다.
- 테스트에서 쉬운 콘솔 로깅을 원했습니다. OCUnit 테스트에서 NSLog ()를 사용할 수 있지만 출력을 보려면 빌드 단계를 펼쳐야하는 빌드 창으로 출력이 이동합니다.
- We wanted easy to read test reporting, both on the command line and in Xcode. OCUnit results appear nicely in the build window in Xcode, but building from the command line (or as part of a CI process) results in test output intermingled with lots and lots of other build output. With separate build and run phases Cedar separates the output so the test output is easy to find. The default Cedar test runner copies the standard style of printing "." for each passing spec, "F" for failing specs, etc. Cedar also has the ability to use custom reporter objects, so you can have it output results any way you like, with a little effort.
OCUnit은 Objective C의 공식 단위 테스트 프레임 워크이며 Apple에서 지원합니다. 애플은 기본적으로 무한한 자원을 가지고 있기 때문에 무언가를 원한다면 끝낼 것이다. 그리고 결국, 이것은 우리가 플레이하고있는 Apple의 샌드 박스입니다. 그러나 그 동전의 단점은 Apple이 매일 bajillion 지원 요청과 버그 보고서의 순서로 수신한다는 것입니다. 모두 처리하는 데는 상당히 좋지만 즉시 또는 전혀보고 한 문제를 처리하지 못할 수 있습니다. Cedar는 OCUnit보다 훨씬 새롭고 덜 구워 지지만 질문이나 문제 또는 제안 사항이있는 경우 Cedar 메일 링리스트 (cedar-discuss@googlegroups.com)에 메시지를 보내 주시면 도와 드리겠습니다. 또한 Github (github.com/pivotal/cedar)에서 코드를 포크하고 누락 된 것으로 생각되는 것을 추가하십시오.
iOS 기기에서 OCUnit 테스트를 실행하는 것은 어려울 수 있습니다. 솔직히, 나는 이것을 꽤 오랫동안 시도하지 않았으므로 더 쉬워 졌을 지 모르지만, 마지막으로 시도했을 때 UIKit 기능이 작동하기 위해 OCUnit 테스트를 얻을 수 없었습니다. Cedar를 작성할 때 시뮬레이터와 장치에서 UIKit 종속 코드를 테스트 할 수 있는지 확인했습니다.
마지막으로 단위 테스트를 위해 Cedar를 작성했습니다. 이는 UISpec과 같은 프로젝트와 실제로 비교할 수 없음을 의미합니다. UISpec을 사용해 본 이후 꽤 오래되었지만 iOS 프로그래밍 방식으로 UI를 프로그래밍 방식으로 구동하는 데 중점을 둔다는 것을 이해했습니다. 우리는 Apple이 UIAutomation을 발표하려고했기 때문에 Cedar가 이러한 유형의 사양을 지원하지 않도록 구체적으로 결정했습니다.
프랭크 를 수용 테스트 믹스로 던져야 할 것입니다. 이것은 상당히 새로운 추가 사항이지만 지금까지 훌륭하게 작동했습니다. 또한 실제로는 이케 크나 다른 것과 달리 적극적으로 노력하고 있습니다.
테스트 중심 개발의 경우, 설정하기 쉬운 GHUnit 을 사용 하고 디버깅에도 좋습니다.
위대한 목록!
iOS 애플리케이션을 테스트하는 UI에 대한 또 다른 흥미로운 솔루션을 찾았습니다.
기반으로 UIAutomation합니다. 프레임 워크를 사용하면 스타일과 같은 화면 중심 시나리오를 오이로 작성할 수 있습니다. 시나리오는 콘솔과 CI를 통해 콘솔에서 장치 및 시뮬레이터에서 실행할 수 있습니다.
어설 션은 스크린 샷을 기반으로합니다. 융통성이 없어 보이지만 강조 표시된 화면 비교를 통해 멋진 HTML 보고서를 얻을 수 있으며 픽셀 정확한 어설 션을 원하는 영역을 정의하는 마스크를 제공 할 수 있습니다.
각 화면은 설명되어야 CoffeScript하며 자체 도구는 루비로 작성됩니다. 그것은 일종의 폴리 글 로트 악몽이지만 도구는 훌륭한 추상화를 제공하며 UIAutomation화면이 설명 될 때 QA 담당자도 관리 할 수 있습니다.
승인 테스트에는 iCuke를, 단위 테스트에는 Cedar를 선택합니다. UIAutomation은 Apple에게 올바른 방향으로 나아가는 단계이지만 도구는 지속적인 통합을 위해 더 나은 지원이 필요합니다. 예를 들어, 인스트루먼트를 사용하여 UIAutomation 테스트를 자동으로 실행할 수는 없습니다.
GHUnit은 단위 테스트에 적합합니다. 통합 테스트를 위해 UISpec을 성공적으로 사용했지만 (github fork here : https://github.com/drync/UISpec ) iCuke는 가벼운 설정이 될 것이기 때문에 iCuke를 사용해 볼 수 있기를 기대합니다. RSpec 및 Cucumber와 같은 레일 테스트 우수성을 사용하십시오.
나는 현재 사용 specta을 (위에서 언급 한 바와 같이) 설정과 파트너 같은 RSpec에 대한 expecta 톤의 멋진 일치하는 옵션이 있습니다.
나는 OCDSpec2를 정말로 좋아하지만 편견이 있고 OCDSpec을 작성하고 두 번째에 기여합니다.
iOS에서도 매우 빠릅니다. 부분적으로는 OCUnit 위에 배치되지 않고 처음부터 구축 되었기 때문입니다. RSpec / Jasmine 구문도 있습니다.
'IT story' 카테고리의 다른 글
| 수퍼 타입 목록을 하위 유형 목록으로 캐스트하는 방법은 무엇입니까? (0) | 2020.04.16 |
|---|---|
| C ++보다 C ++이 얼마나 빠릅니까? (0) | 2020.04.16 |
| Android 용 TextView 자동 맞춤 (0) | 2020.04.16 |
| C # 이벤트 및 스레드 안전성 (0) | 2020.04.16 |
| GitHub에서 다른 사람의 코드에 어떻게 기여합니까? (0) | 2020.04.16 |