[Share] 안드로이드 Unit Test를 통해 느낀 테스트의 여러가지

[boohyunsik]

안드로이드 Unit Test 작성 방법

안드로이드는 Gradle을 이용하여 빌드되기 때문에, Gradle 표준으로 작성할 수 있습니다.
보통 src/test 디렉토리에 테스트 파일을 만들며, 패키지는 src와 똑같이 구성하며 클래스 이름 뒤에 Test를 붙이는 것이 특징입니다.
Test는 Java Unit Test framwork인 JUnit을 이용하며, 따라서 assert와 같은 Java Unit Test 문법을 그대로 활용할 수 있습니다. 이에 더해 Mockito, PowerMock, Robolectric과 같은 다양한 Java Testing Library를 활용할 수도 있습니다.

안드로이드 Unit Test 작성 시 어려움

안드로이드는 Device dependency가 상당히 강한 프레임워크입니다.
모든 앱은 안드로이드 OS가 설치된 디바이스 위에서 동작하고, 안드로이드 컴포넌트들은 컴퓨터의 JVM위에서 만들 수 없습니다. 따라서 컴퓨터의 JVM이 실행하는 안드로이드 유닛 테스트에서 안드로이드 컴포넌트 객체를 만들거나 사용하려 할 때, 많은 문제가 발생합니다. (Null-pointer exception 등..)

Mocking

이런 문제를 해결하기 위해 보통 Mock 이라는 개념을 사용합니다. 흔히 객체를 Mocking 한다라 하면, 테스팅을 위해 가짜 객체를 만드는 것 정도로 이해할 수 있습니다. Java의 Mockito, PowerMock과 같은 테스팅 라이브러리들은 이런 Mocking을 편리하게 지원합니다.

@RunWith(MockitoJUnitRunner.class)
class ExampleUnitTest {
   @Mock
   Context mContext;
}

위의 코드에서 Context는 안드로이드 OS에서 생성하는 앱의 정보를 담고있는 객체입니다. @Mock이라는 어노테이션을 이용하여 선언해주면 편리하게 Mock Context 객체를 생성할 수 있습니다.

@Before
public void setup() {
   when(mContext.getPacakgeName()).thenReturn("test_package_name");
}

Mock 객체를 이용하면 위의 코드와 같이 특정 함수 콜에 대한 응답을 내가 원하는 응답으로 설정할 수 있습니다. Context 객체는 내 컴퓨터의 JVM 위에서는 정상적으로 만들어지지 않으니, 이렇게 Mock 객체를 이용하여 필요한 함수 call에 대한 응답을 바꿔가며 테스트를 진행합니다.

DI 활용

안드로이드에서는 Intent, Bundle과 같이 필요할 때 객체를 생성하여 사용하는 경우가 있습니다. 또는 서버에 요청을 하기 위해 다양한 라이브러리를 활용하기도 합니다. 그러나 이런 클래스들도 framework 의존성이 강하기 때문에, 테스트시 문제를 야기하는 경우가 많습니다. 이런 경우는 Mock 객체를 주입해주기 위해 의존성 주입을 활용합니다.

public void useIntent() {
    Intent intent = new Intent();
    // use intent...
}

위의 메소드를 테스트 하려면, 내 컴퓨터의 JVM은 Intent를 정상적으로 만들어낼수 없기 때문에 NPE를 유발합니다. 따라서 위와 같은 경우는 Intent를 주입받는 식으로 작성하는게 좋습니다.

public void useIntent(Intent intent) {
  // use intent...
}

그리고 아래와 같이 테스트 할 수 있습니다.

@Mock
Intent mockedIntent;

@Test
public void test_useIntent() {
   testedObject.useIntent(mockedIntent);
}

그러나...

그러나 여러 Unit Test를 작성하면서, 모든 프레임워크 의존적인 컴포넌트들에 Mock 객체를 만들고, 원하는 응답을 설정해주는 것이 만만하지 않다는 것을 느꼈습니다. 많은 고민 끝에, Mock 객체를 최소화 하도록 코드를 설계하는 것이 더 좋은 해결방안이라는 생각이 들었고, 그 방법들을 어떻게 활용할 수 있는지 간단하게 설명해보겠습니다.

MVP, MVVM 패턴

안드로이드 앱을 작성하다보면(안드로이드 이외에 다른 앱 개발에도 많이 사용되지만) MVP 패턴, MVVM 패턴에 관한 이야기들을 많이 들을 수 있습니다. 이런 패턴을 사용하는데는 다양한 이유가 있지만, 그 중 테스트 가용성에 대해 이야기해보려 합니다. 안드로이드에서 가장 프레임워크 의존성이 강한 컴포넌트가 바로 Activity, Fragment와 같은 UI 컴포넌트 입니다. 이 클래스들은 안드로이드 OS에서 LifeCycle등을 관리하고, 객체를 만들어주기 때문에 컴퓨터의 JVM에서 UI 컴포넌트 객체를 만들어 테스트 할 수 없습니다. 따라서 UI와 연관된 Acitivty, Fragment를 상속받는 클래스에서는 최대한 UI 동작과 관련된 로직을 작성하고, 그 이외의 모든 비즈니스 로직은 Presenter 또는 View Model에서 작성합니다. 이렇게하면 모든 비즈니스 로직을 Activity에 작성할때 매우 까다로웠던 테스트를, 프레임워크와 의존성이 적은 Presenter나 View model을 테스트로 대체할 수 있습니다. 또한 Mocking을 위해 View interface를 작성해 UI 컴포넌트를 추상화해주는 작업또한 테스트 가용성을 위해 필수적으로 요구됩니다.

Clean Architecture

Clean Architecture는 엉클-밥 으로 유명한 Robert. C Martin이 제안한 소프트웨어 디자인 원칙으로, 핵심은 프레임워크와 완벽하게 독립된, 순수 Java코드로 구현된 layer를 갖는 구조입니다.
클린 아키텍쳐에서는 UseCase라는 비즈니스 로직을 구현한 계층을 구현하는데, 이 계층은 순수 자바코드로 이루어져 있고, Framework 의존적인, 예를 들면 안드로이드 dependency가 강한 객체, 서버에 요청을 보내는 객체등이 존재하지 않습니다. 그리고 이 UseCase들의 조합으로 프로그램을 작성하게 됩니다. 이렇게 코드를 작성하면, 프레임워크 의존성이 떨어지게 되어 테스트하기 매우 간편해진다는 장점이 있습니다.

[hihiboss]

이슈 템플릿(Topic/Detail 분리)정도만 지켜주세요!!

[sojeongw]

글 잘 읽었습니다! 개발 알못, 안드 알못이 궁금해서 질문 드립니다.

1. mock 객체를 최대한 지양한다는 게 구체적으로 어떤 의미일까요? 쪼렙의 입장에서는 mock을 쓰지 않는다 = 실제 오브젝트를 갖다 쓴다 로 이해되는데, 맞나요? 만약 맞다면 이 경우 테스트 코드가 장황해지거나 작성이 번거롭다거나 하는 일들도 있나요?

2. 순수 자바 코드라는 게 있다면 그렇지 않은 코드는 어떤 코드인가요? 안드 개발에만 쓰는 activity 등의 객체는 순수 자바 코드에 포함되지 않는 걸로 이해하면 되나요?

[AgwaB]

또한 Mocking을 위해 View interface를 작성해 UI 컴포넌트를 추상화해주는 작업또한 테스트 가용성을 위해 필수적으로 요구됩니다. 라는 말을 테스트를 위해(mocking을 위해) interface를 작성한다는 뜻인가요? 추상화 시키는 목적이 오로지 테스트를 위해서인지 궁금합니다!

[boohyunsik]

이슈 템플릿(Topic/Detail 분리)정도만 지켜주세요!!

이제 확인했습니다! ㅠ.ㅠ

[boohyunsik]

글 잘 읽었습니다! 개발 알못, 안드 알못이 궁금해서 질문 드립니다.

1. mock 객체를 최대한 지양한다는 게 구체적으로 어떤 의미일까요? 쪼렙의 입장에서는 mock을 쓰지 않는다 = 실제 오브젝트를 갖다 쓴다 로 이해되는데, 맞나요? 만약 맞다면 이 경우 테스트 코드가 장황해지거나 작성이 번거롭다거나 하는 일들도 있나요?
2. 순수 자바 코드라는 게 있다면 그렇지 않은 코드는 어떤 코드인가요? 안드 개발에만 쓰는 activity 등의 객체는 순수 자바 코드에 포함되지 않는 걸로 이해하면 되나요?

1. 이 부분은 지극히 주관적인 의견입니다! 테스트를 하다보면 어쩔수 없이 mocking 라이브러리를 가져다 써야 하는 경우가 되게 많은데요. 제가 지향하는 부분은 이런 라이브러리 도움 없이도 간단하게 테스트를 작성할 수 있도록 코드를 설계하는 것입니다.

2. 넵. 조금이라도 프레임워크와 엮여있다면 그건 순수 자바 코드라고 볼 수 없습니다. 그런 코드는 테스트하기 힘듭니다. 또한 activity를 상속받거나 하지 않아도 안드로이드에서만 사용하는 클래스(Intent, Context, Bundle등)를 사용한다면 그것도 프레임워크와 엮여있다고 할 수 있습니다.

[boohyunsik]

또한 Mocking을 위해 View interface를 작성해 UI 컴포넌트를 추상화해주는 작업또한 테스트 가용성을 위해 필수적으로 요구됩니다. 라는 말을 테스트를 위해(mocking을 위해) interface를 작성한다는 뜻인가요? 추상화 시키는 목적이 오로지 테스트를 위해서인지 궁금합니다!

둘 다 해당됩니다. MVVM이나 MVP과 같은 디자인 패턴에서 Viewmodel, Presenter를 사용하는 이유는 UI(View)와 비즈니스 로직(Model)을 완전하게 분리하기 위함입니다. 조금 더 들어가면 여러 차이점이 있긴 하지만 결국 컨트롤러(Viewmodel, Presenter) 단에서 UI로직을 추상화하면 테스트하기도 쉬워진다는 이점이 있습니다. 다만 이 글은 테스트 관점에서 쓴 글이어서 테스트를 조금 더 부각시켰습니다.

[AgwaB]

@boohyunsik 넵넵 조금 더 질문을 구체화하면, mokito와 같은 테스트 도구들을 사용하면 굳이 추상화를 하지 않아도 mocking을 할 있는데 테스트를 위해서 추상화를 시킨다라고 느꼈어서 위의 질문을 단 것이었습니다!

[AgwaB]

글 잘 읽었습니다! 개발 알못, 안드 알못이 궁금해서 질문 드립니다.

1. mock 객체를 최대한 지양한다는 게 구체적으로 어떤 의미일까요? 쪼렙의 입장에서는 mock을 쓰지 않는다 = 실제 오브젝트를 갖다 쓴다 로 이해되는데, 맞나요? 만약 맞다면 이 경우 테스트 코드가 장황해지거나 작성이 번거롭다거나 하는 일들도 있나요?
2. 순수 자바 코드라는 게 있다면 그렇지 않은 코드는 어떤 코드인가요? 안드 개발에만 쓰는 activity 등의 객체는 순수 자바 코드에 포함되지 않는 걸로 이해하면 되나요?

1. 이 부분은 지극히 주관적인 의견입니다! 테스트를 하다보면 어쩔수 없이 mocking 라이브러리를 가져다 써야 하는 경우가 되게 많은데요. 제가 지향하는 부분은 이런 라이브러리 도움 없이도 간단하게 테스트를 작성할 수 있도록 코드를 설계하는 것입니다.
2. 넵. 조금이라도 프레임워크와 엮여있다면 그건 순수 자바 코드라고 볼 수 없습니다. 그런 코드는 테스트하기 힘듭니다. 또한 activity를 상속받거나 하지 않아도 안드로이드에서만 사용하는 클래스(Intent, Context, Bundle등)를 사용한다면 그것도 프레임워크와 엮여있다고 할 수 있습니다.

개인적으로는

1. 개인적으로 저는 테스트하려는 method 내에서 다른 method를 끌고와서 쓸 때, 해당 method에서 하는 일이 굉장히 많으면 해당 method를 mocking 해버립니다. 최대한 관심사를 잘 분리해서 디펜던시를 줄이면 mock 객체는 덜 쓸 수 있지 않나 싶습니다.
2. 부식님 말처럼 조금이라도 프레임워크와 엮여있다면 순수 자바코드가 아닙니다. 토비의 스프링 1장에서도 스프링 프레임워크(빈 팩토리, application context 등... bean이면)와 엮여있지 않다면 해당 객체는 순수 자바 객체(pojo)라고 언급하고 있습니다.

[sojeongw]

글 잘 읽었습니다! 개발 알못, 안드 알못이 궁금해서 질문 드립니다.

1. mock 객체를 최대한 지양한다는 게 구체적으로 어떤 의미일까요? 쪼렙의 입장에서는 mock을 쓰지 않는다 = 실제 오브젝트를 갖다 쓴다 로 이해되는데, 맞나요? 만약 맞다면 이 경우 테스트 코드가 장황해지거나 작성이 번거롭다거나 하는 일들도 있나요?
2. 순수 자바 코드라는 게 있다면 그렇지 않은 코드는 어떤 코드인가요? 안드 개발에만 쓰는 activity 등의 객체는 순수 자바 코드에 포함되지 않는 걸로 이해하면 되나요?

1. 이 부분은 지극히 주관적인 의견입니다! 테스트를 하다보면 어쩔수 없이 mocking 라이브러리를 가져다 써야 하는 경우가 되게 많은데요. 제가 지향하는 부분은 이런 라이브러리 도움 없이도 간단하게 테스트를 작성할 수 있도록 코드를 설계하는 것입니다.
2. 넵. 조금이라도 프레임워크와 엮여있다면 그건 순수 자바 코드라고 볼 수 없습니다. 그런 코드는 테스트하기 힘듭니다. 또한 activity를 상속받거나 하지 않아도 안드로이드에서만 사용하는 클래스(Intent, Context, Bundle등)를 사용한다면 그것도 프레임워크와 엮여있다고 할 수 있습니다.

개인적으로는

1. 개인적으로 저는 테스트하려는 method 내에서 다른 method를 끌고와서 쓸 때, 해당 method에서 하는 일이 굉장히 많으면 해당 method를 mocking 해버립니다. 최대한 관심사를 잘 분리해서 디펜던시를 줄이면 mock 객체는 덜 쓸 수 있지 않나 싶습니다.
2. 부식님 말처럼 조금이라도 프레임워크와 엮여있다면 순수 자바코드가 아닙니다. 토비의 스프링 1장에서도 스프링 프레임워크(빈 팩토리, application context 등... bean이면)와 엮여있지 않다면 해당 객체는 순수 자바 객체(pojo)라고 언급하고 있습니다.

아 pojo! 그동안 포조의 개념이 아리송했는데 이제 이해가 가네요. 감사합니다!

[ttkmw]

글 잘 읽었습니다! 개발 알못, 안드 알못이 궁금해서 질문 드립니다.

1. mock 객체를 최대한 지양한다는 게 구체적으로 어떤 의미일까요? 쪼렙의 입장에서는 mock을 쓰지 않는다 = 실제 오브젝트를 갖다 쓴다 로 이해되는데, 맞나요? 만약 맞다면 이 경우 테스트 코드가 장황해지거나 작성이 번거롭다거나 하는 일들도 있나요?
2. 순수 자바 코드라는 게 있다면 그렇지 않은 코드는 어떤 코드인가요? 안드 개발에만 쓰는 activity 등의 객체는 순수 자바 코드에 포함되지 않는 걸로 이해하면 되나요?

@sojeongw
1번에 대해 제 의견을 적어봅니다. 아래 내용 중 '~합니다.' 라고 적은 것도 다 생각일 뿐이니, '~라고 생각합니다.' 라고 이해해주시면 감사하겠습니다.
일단 저도 mock 객체를 최대한 지양해야한다고 생각해요.
mock 객체를 사용하면, 의존대상에 상관없이 내가 테스트하고자 하는 부분에 집중할 수 있다는 장점이 생길텐데요. 다만, 마냥 좋은 것이 아니라 트레이드오프가 있는 것 같아요.
예를 들어, 직접 로직수행하는 부분 없이 모두 걸 의존대상에 위임한다면? 그 때 mock처리를 적용하면 진짜 그냥 통과할 수밖에 없는, 무의미한 테스트가 될 수 있어요.
그런 경우에는, 단위테스트가 무의미해질 수 있다고 보고, 통합테스트를 해서 진짜 다 잘 돌아가는걸 확인하거나, 아니면 테스트를 작성하지 않거나. 이렇게 하는 게 낫다고 봅니다.

[ttkmw]

@boohyunsik 넵넵 조금 더 질문을 구체화하면, mokito와 같은 테스트 도구들을 사용하면 굳이 추상화를 하지 않아도 mocking을 할 있는데 테스트를 위해서 추상화를 시킨다라고 느꼈어서 위의 질문을 단 것이었습니다!

@AgwaB
저도 이 부분에 평소 궁금한 점이 있었어요.
구체적으로, '인터페이스가 아니어도, 구조체도 모킹할 수 있는데?. 추상화하는 게 테스트에 어떤 도움이 되지?'라는 생각이 있었는데요.

지금까지의 생각을 말씀드리자면,
일단 토비의스프링 5장에도 추상화가 테스트를 하는 데 도움이 되고, 테스트만을 위해서도 추상화하는 것이 의미가 있다고 나와있습니다.
그러면서 예제로 테스트만을 위한 코드를 추가하고 싶을 때,

1. 일단 의존대상을 추상화하고 그에대한 코드 구현
2. 테스트할 때 구체화된 코드를 수정하고 싶음.
3. 테스트 구조체를 만들고, 실제 구조체를 상속함.
4. 테스트 구조체를 원하는대로 커스터마이징.

이런식으로 추상화 -> 테스트편리화 로 이야기를 합니다.

물론 질문이었던 '추상화를 해야 mocking을 할 수 있는가?'에 대해서는 아닌것같지만,
'테스트를 위해 추상화가 필요하다' 정도로 이해하고 있습니다.

[boohyunsik]

@boohyunsik 넵넵 조금 더 질문을 구체화하면, mokito와 같은 테스트 도구들을 사용하면 굳이 추상화를 하지 않아도 mocking을 할 있는데 테스트를 위해서 추상화를 시킨다라고 느꼈어서 위의 질문을 단 것이었습니다!

@AgwaB
저도 이 부분에 평소 궁금한 점이 있었어요.
구체적으로, '인터페이스가 아니어도, 구조체도 모킹할 수 있는데?. 추상화하는 게 테스트에 어떤 도움이 되지?'라는 생각이 있었는데요.

지금까지의 생각을 말씀드리자면,
일단 토비의스프링 5장에도 추상화가 테스트를 하는 데 도움이 되고, 테스트만을 위해서도 추상화하는 것이 의미가 있다고 나와있습니다.
그러면서 예제로 테스트만을 위한 코드를 추가하고 싶을 때,

1. 일단 의존대상을 추상화하고 그에대한 코드 구현
2. 테스트할 때 구체화된 코드를 수정하고 싶음.
3. 테스트 구조체를 만들고, 실제 구조체를 상속함.
4. 테스트 구조체를 원하는대로 커스터마이징.

이런식으로 추상화 -> 테스트편리화 로 이야기를 합니다.

물론 질문이었던 '추상화를 해야 mocking을 할 수 있는가?'에 대해서는 아닌것같지만,
'테스트를 위해 추상화가 필요하다' 정도로 이해하고 있습니다.

일반 객체도 라이브러리를 이용하면 쉽게 mocking 할 수 있지만, 제가 지향하는점은 라이브러리의 도움이 없어도 테스트하기 편한 코드를 짜는게 더 좋을것 같다는 점입니다. 이 점은 객체 지향 프로그래밍에서 강조하는 개방-폐쇄 원칙, 또는 전략 패턴과도 어느정도 일맥상통한다고 생각합니다.
순수 코드로 mocking을 할 수 있느냐(추상화된 객체), 라이브러리의 도움을 빌려야 하느냐는 조금 차이가 있다는 생각입니다. :)
하지만 코드를 짜다보면 이걸 완벽하게 지키기는 솔직히 힘들긴 하죠^^ 따라서 저번 시간에 얘기한것 처럼 어떤 부분의 변화가 있을지를 잘 판단해서 추상화할 객체를 정해야 하는것 같아요.

[boohyunsik]

글 잘 읽었습니다! 개발 알못, 안드 알못이 궁금해서 질문 드립니다.

1. mock 객체를 최대한 지양한다는 게 구체적으로 어떤 의미일까요? 쪼렙의 입장에서는 mock을 쓰지 않는다 = 실제 오브젝트를 갖다 쓴다 로 이해되는데, 맞나요? 만약 맞다면 이 경우 테스트 코드가 장황해지거나 작성이 번거롭다거나 하는 일들도 있나요?
2. 순수 자바 코드라는 게 있다면 그렇지 않은 코드는 어떤 코드인가요? 안드 개발에만 쓰는 activity 등의 객체는 순수 자바 코드에 포함되지 않는 걸로 이해하면 되나요?

1. 이 부분은 지극히 주관적인 의견입니다! 테스트를 하다보면 어쩔수 없이 mocking 라이브러리를 가져다 써야 하는 경우가 되게 많은데요. 제가 지향하는 부분은 이런 라이브러리 도움 없이도 간단하게 테스트를 작성할 수 있도록 코드를 설계하는 것입니다.
2. 넵. 조금이라도 프레임워크와 엮여있다면 그건 순수 자바 코드라고 볼 수 없습니다. 그런 코드는 테스트하기 힘듭니다. 또한 activity를 상속받거나 하지 않아도 안드로이드에서만 사용하는 클래스(Intent, Context, Bundle등)를 사용한다면 그것도 프레임워크와 엮여있다고 할 수 있습니다.

개인적으로는

1. 개인적으로 저는 테스트하려는 method 내에서 다른 method를 끌고와서 쓸 때, 해당 method에서 하는 일이 굉장히 많으면 해당 method를 mocking 해버립니다. 최대한 관심사를 잘 분리해서 디펜던시를 줄이면 mock 객체는 덜 쓸 수 있지 않나 싶습니다.
2. 부식님 말처럼 조금이라도 프레임워크와 엮여있다면 순수 자바코드가 아닙니다. 토비의 스프링 1장에서도 스프링 프레임워크(빈 팩토리, application context 등... bean이면)와 엮여있지 않다면 해당 객체는 순수 자바 객체(pojo)라고 언급하고 있습니다.

1. TDD에서는 이런경우 리팩토링 대상이라고 언급하고 있기도 합니다. 테스트의 순기능인것 같은데요. 이 메소드나 객체를 테스트 코드상에서 동작시키기가 매우 까다로울것 같다는 생각이 들면 리팩토링을 고려하는것도 방법 중 하나일 것 같습니다.

[AgwaB]

@inDlife 토비의스프링 5장에도 추상화가 테스트를 하는 데 도움이 되고, 테스트만을 위해서도 추상화하는 것이 의미가 있다고 나와있습니다. 라고 하셨는데 테스트만을 위해 추상화한 코드가 실제 프로덕션 코드에 남아 있다는 것인가요 아니면 테스트 단계에서 쓰고 버리는 코드인건가요? 써 주신 예제만으로는 잘 이해가 안가서 질문드립니다! 혹시 5장의 어느 부분인지 말씀해 주시면 감사히 참고하겠습니다!

@boohyunsik 넵넵 맞습니다. 저도 저런 제 코드를 테스트 하면서 자괴감이 들곤 했습니다ㅠㅠㅠ 그래서 의도한 건 최대한 테스트 하려는 method의 의도가 들어나고, 의도를 헤치지 않으려는 선에서만 mocking을 한 기억이 있네요.

[ttkmw]

@inDlife 토비의스프링 5장에도 추상화가 테스트를 하는 데 도움이 되고, 테스트만을 위해서도 추상화하는 것이 의미가 있다고 나와있습니다. 라고 하셨는데 테스트만을 위해 추상화한 코드가 실제 프로덕션 코드에 남아 있다는 것인가요 아니면 테스트 단계에서 쓰고 버리는 코드인건가요? 써 주신 예제만으로는 잘 이해가 안가서 질문드립니다! 혹시 5장의 어느 부분인지 말씀해 주시면 감사히 참고하겠습니다!

프러덕션 코드에 남아있는 걸 말합니다.
그런데 제가 저 때 쓴 부분에서 더 읽으니까, 그 코드를 목 객체로 바꾸는 개선을 해요. 결국에는 목을 쓰는거죠.

이런 과정을 보고 모킹을 하나의 추상화로 볼 수 있나보다 라고 생각했어요.
예제에서는 interface를 모킹하는 걸 보여줬기 때문에 불확실한 면이 있지만,
class를 모킹하는 것도 하나의 추상화로 수 있겠다고 생각했습니다.

토비스프링이 한 주제를 가지고 단계적으로 설명하다보니 그 부분이 어디인지 콕 찍어말하기가 애매하네요 ㅜㅜ 5장을 다시 볼 때 그부분을 보면 얘기드릴게요.

[JaehwanMango]

<TargetFramework>net6.0-android</TargetFramework>
XUnit Test를 Framework android에서 구동할 방법이 있나요?