iOS 테스트/스펙 TDD/BDD 및 통합 및 수용 테스트
iPhone에서 동작 중심 개발에 사용할 수 있는 가장 좋은 기술은 무엇입니까?이러한 테크놀로지의 건전한 사용을 증명하는 오픈 소스 프로젝트의 예는 무엇입니까?검색한 옵션은 다음과 같습니다.
유닛 테스트
테스트:: 유닛 스타일
- OCUnit/SenTestingKit (iOS 개발 가이드: 유닛 테스트 애플리케이션 및 기타 OCUnit 참조)에 설명되어 있습니다.
- 또 만나
- GHUnit
- Mac용 Google 도구 상자: iPhone 유닛 테스트
RSpec 스타일
- 키위(조롱과 기대도 포함)
- 삼나무
- 능숙한 iOS-Acceptance-Testing 사양에 표시된 UI Automation 기능을 갖춘 Jasmine
인수 테스트
셀레니엄 스타일
UI 자동화(디바이스에서 작동)
- UI 자동화 기기 안내서
- UI Automation 참조 문서
- Tunup js - UIAutomation과 함께 사용할 수 있는 시원한 라이브러리.
-
UI Automation을 구동하기 위해 Oy(JavaScript로 작성)를 사용할 수 있습니다.이것은 훌륭한 오픈 소스 프로젝트가 될 것입니다.그러면 Gherkin을 작성하여 UI 자동화 테스트를 실행할 수 있습니다.일단은 Gherkin을 댓글로 쓰도록 하겠습니다.
업데이트: Zucchini Framework는 Ooy와 UI Automation을 혼합한 것 같습니다. :)
이전 블로그 투고:
-
- UISpec은 Google 코드의 오픈 소스입니다.
- UISpec에는 포괄적인 문서가 있습니다.
오이 스타일
Frank와 iCuke(오이와 iPhone의 대화를 바탕으로)
- 프랭크 구글 그룹은 아이큐 구글 그룹보다 훨씬 더 많은 활동을 하고 있다.
- Frank는 장치와 시뮬레이터 모두에서 실행되지만, iCuke는 시뮬레이터에서만 실행됩니다.
- Frank는 iCuke의 단계 정의보다 더 포괄적인 단계 정의를 가지고 있는 것 같습니다.그리고 프랭크는 위키에 단계 정의 개요도 있어요
- iCuke & Frank(Merb & Rails의 합병 방법과 유사)는 공통의 목표를 가지고 있기 때문에 합병할 것을 제안했습니다.iOS용 오이
Zucchini Framework는 쓰기 테스트에 Oy 구문을 사용하고 단계 정의에는 CoffeeScript를 사용합니다.
추가 정보
- 조롱을 위한 OCMock
- OCHamcrest 및/또는 기대에 부응하는 Expecta
결론
물론 이 질문에 대한 정답은 없지만, 현재 제가 선택한 것은 다음과 같습니다.
유닛 테스트에서는 XCode 4의 OCUnit/SenTestingKit를 사용했습니다.심플하고 견고합니다.단, TDD보다 BDD 언어를 선호합니다(RSpec이 테스트보다 나은 이유::유닛?)왜냐하면 우리의 말이 우리의 세계를 창조하기 때문입니다.그래서 지금은 키위를 ARC&KIWI 코드 완성/자동 완성으로 사용하고 있습니다.키위는 OCUnit 위에 세워져 있고 RSpec 스타일의 매처&목/스텁이 있기 때문에 시더보다 더 좋아합니다.업데이트: 현재 Kiwi는 무료 브리지 객체를 지원하지 않기 때문에 OCMock에 대해 알아보고 있습니다.
UI Automation을 사용합니다.각 테스트 사례를 기록하여 쓰기 테스트를 자동으로 수행할 수 있습니다.또한, 애플이 그것을 개발하기 때문에, 장래가 촉망된다.또한 기기 및 계측기에서 작동하여 메모리 누수를 보여주는 등 다른 멋진 기능을 사용할 수 있습니다.UI Automation - Objective - C 、 Frank & iCuke 에 i i i 。하위하거나 'Objective-C'를 만듭니다UIButton를 클릭하면 Objective-C 코드가 실행됩니다.
어떤 솔루션을 사용하고 있습니까?
관련 질문
- 현재 iOS4 및 Xcode4에서 잘 작동하는 BDD 솔루션이 있습니까?
- 유닛 테스트용 XCode 4의 SenTestingKit(XCode와 통합)와 GHUnit의 비교
- OCunit을 사용하는 iOS에서 비동기 코드 테스트
- Xcode 4의 SenTestingKit: 비동기 테스트?
- 아이폰 유닛 테스트는 어떻게 이루어집니까?
dr;dr
Pivotal에서는 Ruby 프로젝트에서 Rspec을 사용하고 사랑하기 때문에 Cedar를 작성했습니다.Cedar는 OCUnit을 대체하거나 경쟁하는 것이 아닙니다.Rspec이 Ruby에서 BDD 스타일의 테스트를 개척한 것처럼 BDD 스타일의 테스트 가능성을 목표 C에 가져오는 것을 의미합니다.그러나 테스트를 없애지는 않았습니다.: 유닛. 둘 중 하나를 선택하는 것은 주로 스타일 선호도의 문제입니다.
OCUnit의 동작방식의 몇 가지 단점을 극복하기 위해 Cedar를 설계한 경우도 있습니다.특히 테스트에서 디버거를 사용하고 명령줄 및 CI 빌드에서 테스트를 실행하여 테스트 결과의 유용한 텍스트 출력을 얻기를 원했습니다.이것들은 당신에게 다소 도움이 될 수 있습니다.
장답
Cedar와 OCUnit과 같은 두 가지 테스트 프레임워크(예를 들어) 중 하나를 결정하는 것은 선호하는 스타일과 사용 편의성 두 가지로 귀결됩니다.스타일부터 시작합시다.그건 단순히 의견과 선호의 문제이기 때문에 사용하기 쉽다는 것은 일종의 트레이드오프인 경향이 있습니다.
스타일 고려는 사용하는 테크놀로지나 언어를 초월합니다.xUnit 스타일의 유닛 테스트는 BDD 스타일의 테스트보다 훨씬 오래되었지만, Rspec의 영향으로 후자의 인기가 급속히 높아지고 있습니다.
xUnit 스타일 테스트의 주요 장점은 단순성과 광범위한 채택(유닛 테스트를 작성하는 개발자 중)입니다. 코드 작성을 고려할 수 있는 거의 모든 언어는 xUnit 스타일 프레임워크를 사용할 수 있습니다.
BDD 스타일의 프레임워크는 xUnit 스타일에 비해 테스트(또는 사양)의 구조화 방법과 어설션의 작성에 관한 구문이라는 두 가지 주요 차이점이 있는 경향이 있습니다.저는 구조적인 차이가 주된 차별화 요인입니다.xUnit 테스트는 1차원이며, 특정 테스트 클래스의 모든 테스트에 대해 하나의 setUp 메서드를 사용합니다.그러나 우리가 테스트하는 클래스는 1차원이 아닙니다.우리는 종종 상충될 수 있는 여러 가지 다른 맥락에서 행동을 테스트해야 합니다.예를 들어 addItem: 메서드를 사용하는 단순한 ShoppingCart 클래스를 생각해 보겠습니다(이 답변에서는 Objective C 구문을 사용합니다).이 방법의 동작은 카트가 비어 있을 때와 다른 아이템이 들어 있을 때와 다를 수 있습니다.사용자가 할인 코드를 입력했을 경우, 지정된 아이템을 선택한 배송 방법으로 배송할 수 없는 경우 등에 다를 수 있습니다.이러한 조건이 서로 교차함에 따라 가능한 컨텍스트의 수가 기하학적으로 증가하게 됩니다.xUnit 스타일 테스트에서는 testAddItem과 같은 이름의 메서드가 많이 사용됩니다.Cart Is Empty And No Discount Code And Shipping Method Applies(Cart Is Empty And No Discount Code And Shipping Method AppliesBDD 스타일의 프레임워크의 구조를 통해 이러한 조건을 개별적으로 구성할 수 있습니다.이것에 의해, 모든 케이스를 커버하는 것 외에, 개개의 조건을 검색, 변경, 또는 추가하는 것도 간단하게 실시할 수 있습니다.예를 들어, 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 사양을 실행하므로 디버거를 동일한 방식으로 사용할 수 있습니다.
- 간단한 콘솔 로그인이 테스트에 필요했습니다.NSLog()는 OCUnit 테스트에서 사용할 수 있지만 출력은 빌드 창으로 들어가 빌드 단계를 읽기 위해 전개해야 합니다.
- 명령줄과 Xcode 모두에서 읽기 쉬운 테스트 보고서를 원했습니다.OCunit 결과는 Xcode의 빌드 창에 잘 나타나지만 명령줄(또는 CI 프로세스의 일부)에서 빌드하면 테스트 출력이 여러 다른 빌드 출력과 혼합됩니다.Cedar는 별도의 빌드 및 실행 단계를 통해 출력을 분리하여 테스트 출력을 쉽게 찾을 수 있습니다.기본 Cedar 테스트 실행자는 각 합격 사양에 대해 표준 인쇄 스타일 "."을, 불합격 사양에 대해 "F"를 복사합니다.또한 Cedar는 커스텀리포터 오브젝트를 사용할 수 있기 때문에 약간의 노력으로 원하는 방식으로 결과를 출력할 수 있습니다.
OCUnit은 Objective C의 공식 유닛 테스트 프레임워크로 Apple이 지원합니다.애플은 기본적으로 무한한 자원을 가지고 있기 때문에, 만약 그들이 무언가를 하고 싶다면, 그것은 완성될 것이다.그리고 결국, 이것은 우리가 놀고 있는 애플의 샌드박스입니다.그러나, 동전의 이면은, 애플이 매일 수십억 건의 지원 요청과 버그 보고를 받는다는 것이다.그들은 모든 문제를 잘 처리하지만, 당신이 보고한 문제를 즉시 처리하거나 전혀 처리하지 못할 수도 있습니다.Cedar는 OCUnit보다 훨씬 새롭고 덜 구워졌지만, 질문이나 문제, 제안이 있으면 Cedar 메일링 리스트(cedar-discuss@googlegroups.com)로 메시지를 보내주시면 저희가 도와드릴 수 있는 모든 것을 해드리겠습니다.또한 Github(github.com/pivotal/cedar))에서 코드를 포크하여 부족한 내용을 추가해 주십시오.델이 테스트 프레임워크를 오픈 소스로 만드는 데는 이유가 있습니다.
iOS 기기에서 OCUnit 테스트를 실행하는 것은 어려울 수 있습니다.솔직히 말하면, 꽤 오랫동안 시험해 본 적이 없기 때문에, 간단하게 할 수 있었을지도 모릅니다만, 지난번 시험에서는, UIKit 의 기능에 관한 OCUnit 테스트를 받을 수 없었습니다.Cedar를 작성할 때 시뮬레이터와 디바이스 모두에서 UIKit에 의존하는 코드를 테스트할 수 있도록 했습니다.
마지막으로 유닛 테스트용으로 Cedar를 작성했습니다.즉, UISpec과 같은 프로젝트와는 비교가 되지 않습니다.UISpec을 사용해 본 지 꽤 되었지만, 주로 iOS 디바이스의 UI를 프로그램적으로 구동하는 것에 중점을 두고 있는 것을 알 수 있었습니다.애플이 UIAutomation을 발표하기 직전이었기 때문에 Cedar가 이러한 사양에 대응하지 않도록 특별히 결정했습니다.
프랭크를 인수 테스트에 참여시켜야 할 것 같아요.이것은 꽤 새로운 추가이지만, 지금까지는 훌륭하게 기능하고 있습니다.또한 icuke나 다른 것들과는 달리 실제로 활발하게 작업되고 있습니다.
테스트 기반 개발에서는 GHUnit을 사용하는 것을 좋아합니다.설정은 간단하며 디버깅에도 매우 적합합니다.
훌륭한 리스트!
iOS 애플리케이션을 UI 테스트하기 위한 또 다른 흥미로운 솔루션을 찾았습니다.
에 근거하고 있습니다.UIAutomation화면 중심 시나리오를 오이처럼 쓸 수 있는 프레임워크입니다.시나리오는 시뮬레이터 및 콘솔에서 디바이스에서 실행할 수 있습니다(CI 친화적).
주장은 스크린샷을 기반으로 합니다.유연하지 않은 것처럼 들리지만, HTML 보고서와 강조 표시된 화면 비교가 제공됩니다.또한 픽셀 단위의 정확한 어설션을 원하는 영역을 정의하는 마스크를 제공할 수 있습니다.
각 화면은 에서 설명해야 합니다.CoffeScript툴은 루비로 되어 있습니다.그것은 일종의 다언어 악몽이지만, 이 도구는 좋은 추상화를 제공합니다.UIAutomation또한 QA 담당자라도 화면을 쉽게 관리할 수 있습니다.
인수 테스트에는 iCuke를, 유닛 테스트에는 Cedar를 선택하겠습니다.UIAutomation은 Apple에게 올바른 방향으로 나아가는 단계이지만 툴은 지속적인 통합을 위해 더 나은 지원이 필요합니다. 예를 들어, 현재 계측기에서 UIAutomation 테스트를 자동으로 실행할 수 없습니다.
GHUnit은 유닛 테스트에 적합합니다.통합 테스트에서는 UISpec을 사용하여 성공을 거두었습니다(여기서는 github fork: https://github.com/drync/UISpec),. 단, 경량 셋업을 약속하고 있기 때문에 iCuke를 사용해 보는 것이 기대됩니다.또, RSpec이나 Ooy와 같은 레일도 사용할 수 있습니다.
저는 현재 specta를 셋업과 같은 rspec에 사용하고 있으며, 많은 매칭 옵션을 갖춘 파트너(위에서 언급한 바와 같이) expecta입니다.
저는 OCDSpec2를 굉장히 좋아하지만 편견이 있어서 OCDSpec을 쓰고 두 번째에 기여했습니다.
iOS에서도 매우 빠릅니다.부분적으로는 OCUnit 위에 놓이는 것이 아니라 처음부터 처음부터 구축되었기 때문입니다.RSpec/Jasmin 구문도 있습니다.
https://github.com/ericmeyer/ocdspec2
언급URL : https://stackoverflow.com/questions/4114083/ios-tests-specs-tdd-bdd-and-integration-acceptance-testing
'codememo' 카테고리의 다른 글
| configSections 요소는 설정 파일마다 1개만 허용되며 존재하는 경우 루트 설정 요소의 첫 번째 아이여야 합니다. (0) | 2023.04.23 |
|---|---|
| Excel-Vba에서 사용자 입력을 받지 않도록 콤보박스를 얻는 방법 (0) | 2023.04.23 |
| 구두점 없이 현재 날짜 및 시간 표시 (0) | 2023.04.23 |
| Python 3에서 "non local"은 무엇을 합니까? (0) | 2023.04.23 |
| IIS7에서 애플리케이션 풀 아이돌타임아웃을 무효로 하는 방법 (0) | 2023.04.23 |