[Bitrise] Bitrise를 사용해보자 - 3. Unit Test

본 게시글은 이전 게시글에 이어서 작성된 부분입니다.

2022.03.30 - [Android/CI CD] - [Bitrise] Bitrise를 사용해보자 - 1. 기본 Setting

2022.04.01 - [Android/CI CD] - [Bitrise] Bitrise를 사용해보자 - 2. Slack 연동

 

이번에는 Bitrise를 사용한 Unit Test를 수행해 볼 예정이다.

GIthub Actions에서도 Unit Test를 해보고 싶었는데, 설정해 줄 부분도 많고 설정했을 때 정상적으로 잘 동작하지 않아서 Bitrise에서 적용해 보았다.

 

Bitrise에서 제공하는 Workflow Recipes를 사용하여 VM환경에서 Unit Test를 진행하도록 작업하였다.

---

우선, 이전 게시글에서 작성했던 Workflow를 확인해보면

이미 Unit Test에 대한 작업이 추가 되어있는 것을 확인할 수 있을 것이다.

 

 

그리고, 첫 번째 게시글에서 언급했던 빌드 결과 화면에서 찾을 수 있는 Details & Add-ons 탭의 Test Reports에서도 Unit Test가 진행되었던 것을 확인 할 수 있다.

 

 

이처럼 말이다.

파일 명을 확인해보니, ExampleUnitTest로 프로젝트를 생성할 때 기본으로 생성되는 테스트 코드로 보인다.

기본으로 작성되어있는 테스트 코드를 확인해 보면,

 

@Test
fun addition_isCorrect() {
    assertEquals(4, 2 + 2)
}

 

이처럼 반드시 성공하게 작성이 되어있어 Test Reports에서 성공으로 나오게 된다.

 

그렇다면, 다른 테스트 케이스를 추가해보도록 한다.

필자는 이전에 Unit Test에 관련된 글을 작성할 때 사용했던 예제에서 코드를 그대로 가져왔다.

 

2022.02.25 - [Android/TDD] - [Mockito] Mockito를 사용해 Instrumented Unit Test를 해보자

2022.02.24 - [Android/TDD] - [Mockito] Mockito를 사용하여 Unit Test 를 해보자 (feat. Truth + Junit4)

코드에 대한 설명이 필요하다면, 해당 게시글을 확인하길 바란다.

 

작성된 테스트 코드가 정상적으로 동작하는지 확인해 본다.

여기서, ExampleUnitTest 클래스 외에도 추가된 테스트 클래스가 있기 때문에 workflow에 들어가서 Unit Test 작업에 추가적인 설정을 해주어야 하는지 확인해 보았는데, 별도로 추가할 부분은 없어 보이기 때문에 커밋하여 빌드를 진행시켰다.

 

 

정상적으로 빌드가 완료 되었으니, Add-ons에서 Test Reports를 확인해보도록 한다.

 

 

별도의 추가 설정을 하지 않았고, 프로젝트에서 테스트 클래스를 추가했을 뿐인데 알아서 추가된 클래스까지 Unit Test를 진행해 주었다.

 

기본적으로 Bitrise에서 생성해주는 Workflow에서 Unit Test까지 완벽하게 지원해준다는 것이 세상 놀라웠다. 

Github Actions에서는 별짓을 다해도 안되던데..

---

Unit Test를 진행해 보았으니, 다음으로는

UI Test를 진행해 볼 차례이다.

 

위에서 Unit Test가 진행된 작업에서는 InstrumentedTest는 제공해주지 않는 것으로 보인다.

따라서, workflow에서 제공하는 작업을 검색해보도록 한다.

 

 

Test를 검색하고 내용을 읽어보니, 가장 위에 UI Test를 Virtural Device에서 진행시켜주는 작업을 찾을 수 있었다.

 

해당 작업을 추가하고 설정을 확인해보자.

 

 

우선, 필자가 수정한 설정은 없고 전부 기본적으로 설정이 되어있다.

하단의 탭들을 보면 상당히 많은 옵션들을 입력할 수 있게 되어있는데, 필수 값들은 전부 알아서 입력이 되어있기 때문에 별도로 수정해야 할 부분은 없는 것으로 보였다.

 

해당 작업을 저장 한 후에, BitriseSample 프로젝트에서 Espresso를 사용한 UI Test를 추가하도록 하자.

UI Test도 Unit Test와 마찬가지로 작업해 두었던 것들을 토대로 간단하게 작성하였다.

 

2022.02.22 - [Android/TDD] - [Espresso] Espresso를 사용하여 UI Test 를 해보자 (feat. Junit4)

Espresso에 대한 설명이 필요하다면 해당 글을 참고하길 바란다.

 

Espresso.onView(withId(R.id.button_first))
    .perform(ViewActions.click())
Espresso.onView(withId(R.id.button_second))
    .perform(ViewActions.click())

 

기본으로 만들어지는 프로젝트는 Activity 하나에 버튼을 통해 2개의 Fragment를 스위치 하도록 구현이 되어있기 때문에, Test Code 또한 버튼을 한번씩 누르는 것으로 작성해 두었다.

 

그 다음 커밋을 통해 테스트 코드를 빌드시켜보았는데, 다행히도 한번에 빌드가 되었다.

 

 

로그를 확인해보니, 정상적으로 테스트가 진행되어서 성공했다는 것을 볼 수 있었다.

 

 

그렇다면 자세한 정보를 위해 Add-ons의 Test Reports를 확인해 보도록 하자.

 

 

정상적으로 에뮬레이터에서 테스트가 진행됬음을 확인 할 수 있었다.

Test Cases를 눌러 확인을 해보았는데, 무언가 이상함을 느꼈다.

 

 

Test Case를 작성해서 빌드했음에도 불구하고, 진행한 Test Case에 대한 정보가 나오지 않는다.

 

 

다른 항목들도 확인해 보았을 때, 모두 테스트를 진행한 것으로 보였고, Video를 통해 UI Test 진행을 영상으로 확인할 수 있었다.

 

해당 영상을 보니 내가 작성했던 Test Code로 UI Tset가 진행 된 것이 아니라 자기가 맘대로 모든 버튼을 눌러가면서 테스트를 진행한 테스트 영상이였다.

 

뭔가 이상하다 싶어서 다시 추가했던 작업에 대한 설정을 확인해 보았다.

 

 

Test Type의 기본 설정은 robo로 되어있고, 클릭해보니 드롭다운 메뉴로 Instrumentation이 나오는 것을 확인할 수 있었다.

즉, robo로 설정되어있었기 때문에 AI가 알아서 버튼을 눌러가면서 UI 테스트를 진행한 것이다.

UI Test Code를 따로 작성하지 않아도, 알아서 테스트를 진행하는 것이라서 이것 또한 상당히 좋은 옵션이라고 생각된다.

 

하지만, 필자가 진행하고자 했던 것은, InstrumentationTest의 진행이기 때문에 Test Type을 변경해주고 저장한 후에 Rebuild를 진행해 주도록 한다.

 

 

Rebuild를 해보니 빌드에 실패하였다.

빌드 시간을 보니 2분 20초로 바로 테스트 중간에 실패한게 아니라 그 이전에 실패했음을 직감할 수 있었다.

 

빌드 로그를 확인해 보자.

 

 

test apk path에 문제가 있고, 뭐 이런거 설정하는거 잊은거 아니야? 라고 경고문이 나온다.

 

우선, 다시 해당 작업의 설정부터 확인해보도록 한다.

 

 

Instrumentation Test 탭에서 Test APK path항목을 확인해보니 위처럼 설정이 되어있다.

해당 Path에 apk가 존재하지 않아서 발생하는 문제가 아닌가? 싶어 해당 경로를 기존 디버그 APK가 빌드되는 path로 변경한 후에 Rebuild를 해보았다.

 

 

동일하게 오류가 발생한다.

 

정확한 사용 방법을 확인하기 위하여 Virtual Device Testing for Android 작업의 페이지에 들어가 보았다.

 

 

설명을 읽어보니까, 별도로 UI testing을 위한 빌드 작업이 선행되어야 한다고 한다.

Build for UI testing을 클릭하여 들어가니 다음과 같은 페이지로 이동한다.

 

 

Description을 읽어보니, 가상 머신에서 테스트를 돌리기 전에 Test apk를 만들어주는 작업인 것으로 확인된다.

 

 

따라서 이처럼 Build for UI Testing 작업이 선행된 후에 가상 머신으로 테스트하는 작업을 수행하도록 하였다.

 

 

UI Test를 위한 빌드 작업에도 이처럼 설정을 해주었다. 이전에 추가했었던 Android Build 작업에서 설정한 것과 동일한 값이다.

 

이렇게 설정을 한 후 저장을하여 다시 Rebuild 해보도록 한다.

 

 

정상적으로 테스트가 통과됐음을 확인할 수 있다.

 

'

Test Reports에서 확인해보면 한개의 작업이 정상적으로 수행되었고 2초의 시간이 걸린것으로 보인다.

 

 

Test cases를 확인했을 때도 필자가 작성했던 테스트가 실행되고 성공된 것을 볼 수 있다.

 

그렇다면, 실패했을 때는 어떻게 나오는가도 확인해 보아야한다.

테스트 코드에 실행 시 오류가 발생하는 코드를 넣어주고 빌드를 진행한다.

 

 

정상적으로 실패가 됐음을 확인할 수 있다.

 

이번에도 마찬가지로 Test Reports를 확인해보자.

 

 

3개의 테스트 중 2개의 테스트는 통과하고, 한개의 테스트는 실패했다는 결과를 보여주고 있다.

여기까지만 봐도 정확하게 테스트가 진행되는 것으로 보이지만, Test Casese도 확인해보도록 하자.

 

 

ui_fail_test로 명명한 테스트 함수만 실패했음으로, UI Test 기능이 정상적으로 동작하고 있음을 확인할 수 있다.

---

Bitrise를 사용한 Unit Test작업을 진행해 보았는데, 생각보다 빠르게 적용을 해볼 수 있었다.

단, 아무래도 가상머신을 사용한 테스트가 들어가다보니 실행 시간이 길어져 사용할 수 있는 크레딧이 빠르게 줄어든다는 단점이 있다.

 

따라서, 실제로 테스트를 진행하는 workflow는 따로 빼내고 조건을 추가하여 Dev Branch나 Master Branch에 머지하는 작업을 하는 등 모든 Commit이 아닌 특정한 경우에서만 실행되도록 하는 것이 좋을 것으로 보인다.

 

Github Actions과 마찬가지로, Bitrise도 지속적으로 공부하면서 적용하기 괜찮은 기능을 찾아낸다면 적용해보고 그것에 대한 글을 작성하고자 한다.