안드로이드 테스트 종합선물세트 -1편 돌잡이

우테코를 진행하며 많은것들을 배우지만 희안하게 예전처럼 정리가 안된다.

그리고 내머리는 잠을 자지못해 점점 퇴화 하고있다.

그래서 기억에 남는거라도 빠르게 기록을 해둬야겠다는 생각에 테스트에 대한 개요를 정리해놓은 테스트 돌잡이 글을 적어보려한다.

(테스트야 무럭무럭 자라렴)

 

1.테스트에서는 무엇이 있고 공부할것은 무엇이 있을까? 

테스트에 대해서 논하자면 이것도 미친듯이 분야가 넓고 애초에 안드로이드 뿐의 이야기가 아니기 때문에 소프트웨어 공학적으로 접근해야한다. 그렇게 보자면 테스트의 종류는 수도 없이 많다. 

구글에 "소프트웨어 테스트 종류"라고 구글링해보자 대충 몇개의 글만봐도 테스트 종류가 어마무시하고 분야를 막론하고 학문적으로 다루고 있음을 느낄수있다.

https://www.atlassian.com/ko/continuous-delivery/software-testing/types-of-software-testing

소프트웨어의 다양한 테스트 유형 | Atlassian

뭐 대충 이런거 봐보자(구글링 더해보자)

---

안드로이드에서 테스트란?

그래서 씹덕아 그만 헛소리하고 안드로이드 진영 혹은 모바일 진영에서 주로 하는 테스트가 뭔데(사실 ios 1도 모르지만 아는척해봄)

한다면 

 

안드로이드 개발의 바이블 안드로이드 공식문서에서 테스트에서 뭐라고 쏼라쏼라 해놨는지 봐야할것이다.

https://developer.android.com/training/testing/fundamentals?hl=ko 

테스트 기본 요소  |  Android 개발자  |  Android Developers

공식문서를 보면 엄청 어려운 이야기부터, TDD를 하라고 돌려말하고, 모듈형태로 쪼개서 테스트를 수월하게 할수있는 형태까지 제시하는 그야말로 종합선물 세트라서 읽어보면 좋지만 막상 뚜렷이 뭘하라는건지는 모르겠는게 대부분이다.(물론 각각을 공부하고 와서 보면 아!!!!!! 이런느낌이다.)

 

이 부분을 볼수있는데 여기서 말하는 소형테스트 조차도 이것저것 짬뽕 시켜놓은 것이므로 초심자 입장에서 이걸 본다고 알수있는것은 하나도 없다.

 

그래서 소형을 좀더 초소형으로 쪼개볼 예정이다(내수준에 맞게 ^^ 돼지는 아이큐가 65 라고한다.)

 

그래서 테스트 자체를 본질적으로 쪼개보겠다.

---

1. 단위 테스트

https://mccoy-devloper.tistory.com/114(지금은 닫아놨지만 추후에 기타 사용법 등등을 적어서 열어놓을 예정이다)

 

단위 테스트(Unit Test)

단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트이다.

단위 테스트에서 테스트 대상 단위의 크기는 엄격하게 정해져 있지 않다. 하지만, 일반적으로 클래스 또는 메소드 수준으로 정해진다. 단위의 크기가 작을수록 단위의 복잡성이 낮아진다. 따라서, 단위 테스트를 활용하여 동작을 표현하기 더 쉬워진다. 즉, 테스트 대상 단위의 크기를 작게 설정해서 단위 테스트를 최대한 간단하고 디버깅하기 쉽게 작성해야 한다.

소프트웨어를 개발할 때, 소프트웨어 내부 구조나 구현 방법을 고려하여 개발자 관점에서 테스트한다. 그러므로 단위 테스트는 소프트웨어 내부 코드에 관련한 지식을 반드시 알고 있어야 하는 화이트박스 테스트이다. 단위 테스트는 TDD와 함께 할 때 특히 더 강력해진다.

 

테코블의 단위테스트에 대해 정리해놓은 글을 따와봤다. 나는 항상 글을 느낌적으로 적어서 정의를 내리는건 힘들어한다. 때문에 글잘쓰는 우테코 선배들에게 정의를 맡기고 나는 느낌가는대로 단위테스트를 사용하는 방법에 대해서 이야기해보겠다.

 

단위테스트란 아주 작은 단위로 테스트를 하는것을 뜻하지만 안드로이드에서는 대부분 안드로이드에 의존성이 없는 도메인 측면에서의 로직들을 잘게 잘게 쪼개서 테스트 하는것들을 말하곤 한다.

안드로이드의 의존성이 들어갈수 있고 Robolectric 을 이용해서 안드로이드 의존성을 갖고있는 로직들도 단위테스트의 대상으로 테스트하게 될수있지만 안드로이드의 주 관심사는 대부분 UI 즉 화면과 관련된 경우가 많다. 때문에 화면과 관련되어있다면 UI테스트로 가는경우가 대부분이다.결국 중요하게 남는것들은 도메인 관련 로직들이 남게된다.(물론 화면과 관련없지만 도메인적인 측면도 있고 공격하고 싶은게 뭔지는 알지만 쉽게 쉽게 정리하고 싶은 마음에 정리한것이니 그러려니 하고 넘어가주시면 감사드리겠습니다.)

그래서 내가 자바 혹은 코틀린으로 얼기설기 짠 코드가 과연 맞는것인지 검증하는 과정인 경우가 많다.

ex) 오목을 두는데 적용한 33룰이 논리 적으로 맞는가? 

 

그래서 Junit와 AssertJ를 사용하여 테스트를 하게된다.

• JUnit: 자바 단위 테스트를 위한 테스팅 프레임워크
• AssertJ: 자바 테스트를 돕기 위해 다양한 문법을 지원하는 라이브러리

이런걸 이용하게 될것이고 자세한것은 최초에 남긴 링크에서 사용법을 따라가보자.

 

아 참고로 안드로이드에서는 개빡치게 2023.05.01 기준으로 Junit5가 최신인데

안드로이드 관련 모듈이라면 JUnit4를 기본으로 지원한다. -> 그래서 JUnit5를 app모듈같은데서 쓸려면 라이브러리를 이용해야한다(개킹받네 진짜 그냥 JUnit4 문법이 거기서 거기니 JUnit4 문법을 익혀서 사용하자)

JUnit5 사용을 위한 라이브러리:

https://github.com/mannodermaus/android-junit5

GitHub - mannodermaus/android-junit5: Testing with JUnit 5 for Android.

plugins {
  id("de.mannodermaus.android-junit5") version "1.9.3.0"
}

dependencies {
  // (Required) Writing and executing Unit Tests on the JUnit Platform
  // JUnit5 를 사용하고 싶다면 추가
  testImplementation("org.junit.jupiter:junit-jupiter-api:5.9.3")
  testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.9.3")

  // (Optional) If you need "Parameterized Tests"
  // Parameterized Test를 위해 추가
  testImplementation("org.junit.jupiter:junit-jupiter-params:5.9.3")

  // (Optional) If you also have JUnit 4-based tests
  // JUnit4테스트 또한 사용하고 있다면 무조건 추가해줘야함 빈티지엔진!!!!!!
  testImplementation("junit:junit:4.13.2")
  testRuntimeOnly("org.junit.vintage:junit-vintage-engine:5.9.3")
}

 

그리고 도메인 모듈처럼 자바 코틀린 모듈이라면 JUnit5를 사용해도 무방하니 JUnit5를 애용해주자 ㅎㅎ 

---

2. UI 테스트

https://mccoy-devloper.tistory.com/115 (지금은 닫아놨지만 추후에 기타 사용법 등등을 적어서 열어놓을 예정이다)

 

UI 테스트란 무엇인가?

UI테스트는 유닛 테스트, 통합 테스트 등 보다 대형 테스트 기법으로 분류되며, 실제 앱을 사용자의 흐름에 따라 화면에 직접 터치해가며 일련의 동작을 수행해 보는 테스트입니다. 말 그대로 User Interface Test 인 것이죠

말은 이런데 한마디로 화면에 뭐 잘나오나 우리가 일일히 노가다로 눌러보고 실제로 육안으로 확인하던걸 코드로 작성해놓으면 막 에뮬이 켜져서 코드에 작성해놓은대로 스와이프하고 터치하고 해서 어떤조건

ex)멧돼지는 강하다 같은 문구가 있는가 확인 이런 것들을 할수가 있다.

솔직히 말해서 단위테스트 만큼 필요성이 확 와닿지는 않는다 (제임스가 말하길 아직 써보지도 않고 아는척하며 말할시간에 한줄이라도 더 공부하고 판단하라 -> 맞는말이지만 똥인지 된장인지 찍어먹어보다 똥으로 배부르게 식사할수도 있는거자나요 ㅠㅠ)

 

UI 테스트가 필요한가에대한 논쟁은 많이들 하는것 같은데 하고 안하고는 자기맘이지만 모르고 안하는거랑 알고서도 안하는거랑은 분명다르니 학습할가치는 무조건 있다.

 

안드로이드에서는 이러한 UI테스트를 진행하기위해 제공하는 라이브러리로 에스프레소가 있고

https://developer.android.com/training/testing/espresso?hl=ko 

Espresso  |  Android 개발자  |  Android Developers

 

이 에스프레소는 안드로이드 프로젝트를 만들면 기본적으로 포함되어있다.(리사이클러뷰 같은거 테스트에는 추가 의존성을 추가해줘야함)

 

이런 에스프레소의 사용법은 상위에 걸어놓은 링크에 자세히 설명할것이고 UI테스트에 대해서 사용할때 어떻게 하면 좋은 테스트를 짤수있을가 라는 부분에서 생각해보고 갈만한 것들을 몇개 적어보려한다.

 

1. UI는 진짜 숨쉬듯이 바뀌는 부분이니 테스트도 유연성있게 짜자

2. 이 프로젝트에서 바뀌지않을만한 코어한 UI에 대해서는 꼼꼼히 로직을 작성할 필요성이있다.

3. UI테스트 불신론자들에게 퇴마를하듯이 하나의 강력한 장점을 제시하자면 안드로이드의 오만가지 기기 대응에는 UI테스트가 강력하게 작용할수 있다.

---

3.부가적으로 적용할수있는 Test Double

https://mccoy-devloper.tistory.com/116 (지금은 닫아놨지만 추후에 기타 사용법 등등을 적어서 열어놓을 예정이다)

 

테스트 더블은 뭐 테스트가 아니라 테스트를 하는데 드는 비용 혹은 테스트를 좀더 잘하기위해 기교를 부리는것이다.

즉 테스트를 좀더 유연하게 만들수있는 방법들이다.

 

이것들은 진짜 기술들이니 자세한 사항들은 글에서 정리하도록 하고 지금 우테코에서 막 떠돌고있는 테스트더블 대표 3인방을 반달이 정리해놓은것을 복붙하고 끝내봐야겠다.

 

Mock

Mock객체는 미리 정의된 동작을 가진 객체입니다. 이러한 객체는 수신하는 호출을 등록하여 코드에서 객체를 사용하는 방법을 단언할 수 있습니다. Mock객체에는 실제 구현이 없습니다. 대신 코드에서 어떻게 사용될지에 대한 기대치가 미리 프로그래밍되어 있습니다.

 

Stub

Stub은 미리 정의된 값을 반환하는 객체입니다. Mock 객체와 마찬가지로 실제 구현이 없습니다. 하지만 Mock객체와 달리 특정 호출을 예상하도록 프로그래밍되지 않습니다. 대신 호출될 때 값을 반환합니다.

 

Fake

Fake는 작동하는 구현이 있는 객체입니다. Fake객체는 실제 객체와 동일한 인터페이스를 구현하지만 성능 향상을 위해 최단경로를 사용합니다. Fake는 일반적으로 외부 서비스나 API에 의존하는 무언가를 테스트해야 하는데 해당 서비스를 실제로 호출하고 싶지 않을 때 사용합니다.

 

셋 중 고르는 방법

테스트 더블을 선택할 때는 무엇을 테스트할지, 어떻게 테스트할지 고려해야 합니다. Fake는 일반적으로 외부 호출을 피하여 성능을 개선하는 데 사용됩니다. Mock 테스트는 코드의 동작을 검증하는 데 사용됩니다. Stub은 코드가 실행하는 데 필요한 데이터를 제공하는 데 사용됩니다.

 

https://tecoble.techcourse.co.kr/post/2020-09-19-what-is-test-double/

Test Double을 알아보자

테스트 더블 관련 좋은글