Calabash를 사용한 Android 및 iOS UI 테스트

테스트는 모든 모바일 앱 개발 프로세스의 필수적인 부분입니다. 이러한 테스트를 자동화하는지 여부에 관계없이 정상적인 개발자는 앱을 테스트하지 않는 한 작업이 완료된 것으로 간주하지 않습니다.

잘 테스트된 앱은 일반적으로 단위 테스트, 통합 테스트, 승인 테스트 등 여러 단계의 테스트를 거칩니다. 앱이 성장함에 따라 테스트의 중요성이 커지고 테스트 자동화가 필수가 되었습니다.

웹과 같은 다른 플랫폼은 테스트 메커니즘 및 프레임워크 측면에서 크게 발전했지만 모바일 영역은 뒤처지지 않습니다. 이 기사에서는 Calabash를 사용하여 일반 영어 지침을 사용하여 Android 및 iOS 앱용 UI를 자동화하고 가능한 한 쉽게 승인 테스트를 수행하는 방법을 배웁니다.

UI 테스팅이란 무엇인가?

앱을 수동으로 테스트해 왔다면 동일한 작업을 반복해서 수행하는 데 많은 시간을 낭비하고 있을 것입니다. 코드를 약간 변경하고, 앱을 빌드하고, 기기나 에뮬레이터에서 실행하고, 앱을 조작하여 예상대로 작동하는지 알아냅니다.

UI 테스트를 자동화하여 동일한 수동 단계를 자동으로 수행할 수 있습니다. 앱의 크기가 적당하다면 많은 시간을 절약할 수 있으며 앱이 난처한 버그, 특히 회귀 버그로 가득 차 있는 것을 방지할 수 있습니다.

"굉장히 들립니다."라고 말하지만 Android 또는 iOS 앱에서는 어떻게 합니까?

Android 및 iOS용 UI 테스트 프레임워크

Android 및 iOS용 공식 문서를 읽으면 공식 IDE에서 UI 테스트를 작성하고 실행할 것을 제안합니다. Android의 경우 Android Studio이고 iOS의 경우 Xcode입니다.

공식 문서는 테스트를 위한 특정 프레임워크를 권장하기까지 합니다. 공식 Android 문서에서는 Android UI 테스트 프레임워크인 Espresso에 대한 몇 가지 주제를 다룹니다. 마찬가지로 Apple은 XCTest 프레임워크를 사용할 것을 제안합니다.

그리고 UI 테스트에 대해 진지하게 작업하려는 경우 다음 제안을 따를 수 있습니다. Espresso는 Google에서 유지 관리하고 Android 지원 리포지토리의 일부이기 때문에 의미가 있습니다. Espresso는 Google이 향후 Android에 도입할 모든 새로운 기능을 지원할 가능성이 매우 높습니다. iOS용 XCTest 프레임워크에 대해서도 마찬가지입니다.

그러나 자동화된 테스트의 수많은 이점에도 불구하고 많은 개발자가 단순히 테스트를 전혀 작성하지 않는다는 점을 기억할 가치가 있습니다.

내부적으로 테스트 자동화를 알고 있는 모든 개발자는 이것이 훌륭한 아이디어라는 것을 알고 있습니다. 그러나 앉아서 이러한 테스트를 작성하는 것과 관련하여 많은 개발자가 시간을 할애할 가치가 있는지 의문을 갖기 시작합니다. "버튼을 터치"하는 것이 "이 버튼을 터치"하는 코드를 작성하는 것보다 훨씬 빠른 작업으로 밝혀졌기 때문입니다. 자동으로. 때로는 앱을 사용하려고 애타게 기다리는 클라이언트와 관리자도 도움이 되지 않습니다.

많은 개발자들은 그 시점에서 기존 기능에 대한 자동화된 UI 테스트를 작성하는 것보다 애플리케이션의 새로운 기능에 대한 작업을 계속하는 것이 더 낫다고 결정합니다.

응용 프로그램이 성장하면 응용 프로그램을 업데이트할 때마다 수동으로 "이 버튼을 터치"하는 데 점점 더 많은 시간이 소요됩니다.

하지만 UI 테스트를 더 쉽게 만드는 프레임워크가 있고 앱에 대한 UI 테스트를 작성하지 않을 핑계를 주지 않는다면 어떻게 될까요?

칼라바시를 만나보세요.

Calabash: 모바일 앱에 대한 자동 승인 테스트

약 1년 전, 저는 소프트웨어 개발자가 아닌 사람들도 사용하기 쉬운 테스팅 프레임워크를 찾기 시작했습니다. 그리고 그 때 나는 Calabash를 찾았습니다.

Xamarin 팀에서 개발 및 유지 관리하는 이 오픈 소스 테스트 프레임워크는 Android와 iOS 모두에서 작동합니다. 모바일 애플리케이션에 대한 자동화된 승인 테스트를 작성하고 실행할 수 있습니다.

승인 테스트는 일반적으로 앱이 비즈니스 요구 사항을 충족하는지 확인하는 시스템 테스트 후에 수행됩니다. UI 수준에서 작동한다는 점을 감안할 때 이것은 UI 테스트 자동화 프레임워크의 선택과 잘 맞습니다.

Calabash는 Espresso 또는 XCTest처럼 앱과 상호 작용할 수 있습니다. 그러나 여기서 Calabash를 탁월한 선택으로 만드는 것은 Cucumber에 대한 지원입니다.

Cucumber는 일반 영어로 작성된 자동화된 테스트를 실행할 수 있는 도구입니다(원하는 경우 다른 일반 언어를 사용하도록 조정할 수 있음). 따라서 Cucumber에서 자동화된 테스트를 작성하기 위해 테스터는 Java, Objective-C 또는 기타 프로그래밍 언어를 알 필요가 없습니다.

호리병박이 똑딱 거리게 만드는 것은 무엇입니까?

Calabash 프레임워크는 Android 및 iOS 앱과 상호 작용할 수 있는 라이브러리로 구성됩니다. 실제 장치에서 실행할 수 있습니다. 따라서 테스터가 수동으로 수행하는 작업을 수행할 수 있습니다.

GitHub에는 Calabash를 가능하게 하는 두 가지 프로젝트가 있습니다.

• calabash-android - 안드로이드용

• calabash-ios - iOS용

Calabash는 모든 Ruby 기반 테스트 프레임워크와 함께 작동할 수 있습니다. 이 기사에서는 Calabash에서 가장 인기 있고 편리한 테스트 작성 방법인 Cucumber를 다룰 것입니다.

계속하기 전에 기사의 나머지 부분을 따라가면서 Calabash를 사용해 보려면 컴퓨터에 Ruby가 설치되어 있는지 확인하십시오. 여기에서 자세한 설치 지침을 찾을 수 있습니다.

다음으로, 위의 GitHub 링크를 따라 선호하는 플랫폼용 Calabash를 설치하십시오.

Calabash에서 첫 번째 테스트 작성하기

Calabash에서 테스트를 작성하는 것은 매우 쉽습니다. iOS 앱에 대한 간단한 테스트가 어떻게 보이는지 봅시다.

 Feature: User Login Scenario: Unsuccessful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "tstuser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Username you entered is incorrect" Scenario: Successful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "testeruser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Hey testeruser!"

여기에서 앱은 잘못된 사용자 이름과 비밀번호로 테스트되고 있으며 올바른 사용자 이름과 비밀번호로 테스트되고 있습니다. 테스트에서는 앱이 첫 번째 시나리오에서는 로그인에 실패하지만 두 번째 시나리오에서는 성공할 것으로 예상합니다.

필요한 만큼 시나리오를 만들 수 있으며, 단계/지침을 간단한 영어 문장으로 분해하기만 하면 됩니다. 당신이 이야기를 쓰는 것처럼!

행동 주도 개발(BDD)에 대해 아는 사람은 이미 이에 대해 잘 알고 있을 것입니다.

호리병박은 어떻게 작동합니까?

테스터가 사용하는 단계 뒤에서 무슨 일이 일어나는지 보려면 GitHub에서 프로젝트를 열고 다음 파일을 확인할 수 있습니다.

 calabash-cucumber/features/step_definitions/calabash_steps.rb

다음 단계의 정의를 살펴보겠습니다.

 When I enter "testeruser" into the "Username" field

 Then /^I enter "([^\"]*)" into the "([^\"]*)" field$/ do |text_to_type, field_name| touch("textField marked: '#{field_name}'") wait_for_keyboard keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

Ruby 코드의 이 작은 조각은 특정 필드를 찾아 터치하고 키보드가 나타날 때까지 기다렸다가 text_to_type 변수에서 텍스트를 입력하고 다음 단계로 전환하기 전에 잠시 기다립니다.

단계의 첫 단어는 "Given", "When", "Then", "And" 또는 "But"이 될 수 있습니다. 어떤 키워드를 사용할지는 중요하지 않습니다. 그들 중 하나를 사용하여 이야기를 더 명확하게 만들 수 있습니다.

사용자 정의 단계를 추가하는 방법

Calabash에서 아직 구현되지 않은 단계가 필요한 경우 직접 작성할 수 있습니다. 구문은 이미 사전 정의된 단계에서와 정확히 동일합니다.

예를 들어 테스터가 필드 이름 대신 자리 표시자로 입력 필드에 액세스해야 하는 경우:

 Then /^I enter "([^\"]*)" into the field with placeholder "([^\"]*)"$/ do |text_to_type, placeholder| touch("textField placeholder:'#{placeholder}'") wait_for_keyboard() keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

이 단계 정의는 이전 단계 정의와 거의 동일하지만 필드 이름 대신 자리 표시자로 필드에 액세스하고 있습니다. 앱이 어떻게 보이는지 고려하면 테스터가 작업을 훨씬 더 쉽게 할 수 있습니다.

개발자도 쉽게 사용할 수 있습니다. 개발자는 단계를 한 번 구현하고 테스터는 필요할 때마다 사용합니다. 또한 사용자 정의 단계를 구현하기 위해 Ruby를 많이 알 필요도 없습니다.

여기에서 사용할 수 있는 Ruby 기능을 찾을 수 있습니다.

http://www.rubydoc.info/gems/calabash-cucumber/Calabash/Cucumber

자마린 테스트 클라우드

모바일 애플리케이션을 테스트할 때 또 하나의 과제가 있습니다. 장치와 OS 버전이 너무 많기 때문에 가능한 한 많은 장치에서 테스트해야 합니다.

여기서 Xamarin Test Cloud가 많은 도움이 됩니다. 클라우드에는 약 2,000개의 실제 장치가 있으며 좋은 소식은 Calabash 테스트를 지원한다는 것입니다.

반복적인 작업을 줄여 시간을 절약하는 데 도움이 되었던 동일한 Calabash 테스트를 이제 많은 실제 장치에서 애플리케이션을 테스트하는 데 사용할 수 있습니다.

UI 테스트 작성 시작

Calabash가 앱에 필요한 테스트 솔루션인지 여부와 함께 제공하는 이점으로 인해 모바일 앱에 대한 자동화된 UI 테스트를 작성할 때 변명의 여지가 없습니다. 앱이 특정 장치 기능(예: 카메라)에 크게 의존하는 경우 Calabash가 부족할 수 있지만 여전히 대부분의 앱에 대한 테스트 작성을 훨씬 더 쉽게 만듭니다.