처음 학습하면서 작성한 글입니다. 필요시 추후 내용을 수정할 예정입니다.
틀린 부분이 있으면 언제든 지적해주면 감사하겠습니다 :)
지난번 Espresso 를 사용한 UI 테스트에 이어서 Truth 를 사용한 Unit 테스트에 대한 스터디를 진행하였다.
Unit 테스트를 진행함에 있어서 Junit4 만 사용해도 되지만 공식 developer 문서에도 사용하는 것이 좋다는 언급이 되어있기도하여 Truth 를 사용해보자 생각하였다.
Espresso 를 사용해보면서 테스트 환경을 어느정도 만들어 두지 않았나 싶어서 바로 Truth 를 사용해보도록 하였다.
우선,
Truth 가 무엇인가 ?
Guava 팀에서 제공하는 유창한 어설션 라이브러리
라고 안드로이드 developer 문서에서 언급되어있다.
Unit 테스트를 진행하는데 사용되는 어설션을 사용하기 쉽게 도움을 주는 라이브러리 라고 생각하면 되는데,
여기서 어설션이란 테스트 함수를 작성할 때 사용하는 Junit 에서 제공하는 함수이다.
즉, Junit 을 사용하여 Unit 테스트를 진행하는데 Junit 에서 제공하는 어설트 함수 대신에 사용이 가능한 라이브러리라고 생각하면 된다.
그렇다면,
Truth 를 적용하고 사용해보자.
Module 범위의 gradle 에 해당 라이브러리만 추가해주면 truth 를 사용할 준비는 끝났다.
이전에 Espresso 를 사용할 때 그 외 테스트에 필요한 항목은 추가해두었기 때문에 위의 truth 라이브러리만 추가하였는데, Truth 를 통해 처음 테스트를 진행하고자 한다면 다음 항목들을 확인하길 바란다.
필자가 Gradle 에 선언한 Unit 테스트에 필요한 라이브러리 이다.
이렇게 선언을 해두었으면, Espresso 와 마찬가지로 테스트 코드를 작성하기만 하면 되는데,
이번에는 계측 단위 테스트가 아닌 로컬 단위 테스트를 해야한다.
따라서, androidTest 가 아닌 Test 로 되어있는 패키지의 테스트 클래스에 테스트 코드를 작성해주어야 한다.
테스트 코드를 작성하기 앞서, 테스트에 사용할 간단한 Calculator 클래스를 만들어 두었다.
작성한 2개의 함수를 사용하여 테스트 코드를 작성해 볼 예정이다.
우선, 테스트 클래스에서 Truth 를 import 하여 사용하도록 하자.
import com.google.common.truth.Truth.assertThat
생성한 클래스를 사용하기 위해 lateinit 로 선언해두고, before 어노테이션을 사용한 함수 내부에서 테스트가 진행되기 전에 클래스를 생성해주도록 한다.
테스트를 진행할 테스트 코드는 @Test 어노테이션을 사용하여 작성하도록 한다.
이곳에서 truth 라이브러리를 사용할 수 있는데, 우선 앞서 Truth 를 import 하였기 때문에 Truth 에서 제공하는 assertThat 메소드를 그냥 사용할 수 있다.
assertThat 을 사용하여 테스트 할 동작들을 작성해주면 된다.
assertThat 메소드는 assertThat(object).확인할 동작 형태로 작성하면 되는데, 자동 완성 기능을 사용하여 필요한 테스팅 함수를 찾으면 된다.
이처럼, 자료형에 따라 각각 사용이 가능한 테스팅 함수가 나오기 때문에, 따로 찾아 볼 필요 없이 함수 목록을 확인하여 원하는 작업을 진행하면 된다.
object 가 들어가는 부분에 다른 함수를 호출하여 리턴값을 사용해도 상관 없고,
espresso 에서 테스트 했던 것 처럼 test 함수 내에 다른 test 함수를 호출해도 무관하다.
assertThat 함수를 사용하여 하나라도 테스트에 통과하지 못할 경우 오류 메세지가 뜨고, assertThat 함수는 순차적으로 동작하여 앞에서 통과를 하지 않으면 뒤에 있는 테스트 함수의 결과는 알 수 없다.
따라서, 순차적으로 확인을 해야하는 항목이 아닌 경우 나눠서 테스트하는 것이 좋을 것으로 보인다.
*
Truth 로 테스트를 진행하던 도중, Junit 에서 제공하는 Assert 함수를 사용하면 어떻게 되는지 궁금하여 한번 사용해 보았다.
이처럼 assert 뒤에 체크할 동작을 선언하고 사용해야 하며, 체크를 하고자 하는 객체와 동일 여부를 체크하는 변수를 , 로 구분하여 넘겨주어야 한다.
확실히 이렇게만 봤을 때도 truth 를 사용하는 편이 훨씬 더 직관적으로 함수를 이해하기 쉬운 것으로 보인다.
테스트 함수를 작성했으니,
테스트를 실행시킬 차례이다.
Espresso 를 사용할 때와 마찬가지로, 테스트 함수 왼편에 나와있는 Junit 테스트 버튼을 사용한다.
테스트를 실행했을 때 모든 테스트를 통과하게 되면 별다른 메세지가 발생하지 않으며,
테스트를 통과하지 못한 항목이 있으면 다음과 같이 오류가 발생한다.
이처럼 테스트를 통과하지 못한 지점과, 그 값에 대해서 설명이 나오게 되어 어느 부분을 수정해야 하는지 확인이 쉽다.
상단 툴바를 통해서도 동일하게 빌드가 가능하며, 계측 테스트와 다르게 연결된 기기나 VM 이 필요하지 않기 때문에 연결된 기기 부분은 활성화 되어있지 않다.
run 버튼을 누르게 되면 위에서 실행한 것과 동일하게 테스트가 진행되는 것을 알 수 있다.
*
2022.02.24 추가.
테스트 클래스 전체를 실행시켰을 때 Test 함수에 따른 성공과 실패 여부가 나오게 되는데, 실패한 부분만 나오는 경우 테스트 결과가 나와있는 창 상단의 옵션을 눌러보면 확인 가능합니다.
이처럼 테스트 성공, 실패 함수를 쉽게 파악할 수 있습니다.
따라서, 하단에 기입한 테스트 코드를 찾아서 실행시키는 것에 불편함이 있을 것 같다는 말은 제거합니다.
테스트 함수가 많아질 수록, 테스트 코드를 찾아서 실행시키는 것에 불편함이 있을 것으로 보였다. 따라서,
테스트 함수를 작성하는 네이밍 컨벤션을 잘 지켜서 구현을 하는 것이 중요할 것이라고 생각이 되었는데,
테스트 함수의 네이밍 컨벤션에 대하여 구글링을 해보았는데 컨벤션 자체가 생각보다 길어서 당황했다.
필자는 테스트 예제를 만들기 위하여 테스트 함수 명을 마음대로 작성하였는데,
혹, 컨벤션을 지키면서 예제를 만들고 싶다면 다음 링크를 참고하면 될 것 같다.
https://dzone.com/articles/7-popular-unit-test-naming
해당 게시글에 사용 된 예제 코드는 Github에 업로드 해두었으니 참고 바란다.
https://github.com/HeeGyeong/UnitTestSample
GitHub - HeeGyeong/UnitTestSample
Contribute to HeeGyeong/UnitTestSample development by creating an account on GitHub.
github.com
'Android > TDD' 카테고리의 다른 글
| [TDD] TDD 란 ? (0) | 2022.02.27 |
|---|---|
| [Mockito] Mockito를 사용해 Instrumented Unit Test를 해보자 (0) | 2022.02.25 |
| [Mockito] Mockito를 사용하여 Unit Test 를 해보자 (feat. Truth + Junit4) (2) | 2022.02.24 |
| [Espresso] Espresso를 사용하여 UI Test 를 해보자 (feat. Junit4) (0) | 2022.02.22 |
| [Mockito] Mock 객체 란? (0) | 2020.06.10 |
