안드로이드의 4대 컴포넌트에 대해 설명
액티비티(Activity)는 사용자에게 보여지는 화면을 제공하는 컴포넌트입니다.
자체적인 생명 주기를 가지고 있으며, 하나의 액티비티만 화면에 보여줄 수 있는 특징이 있습니다.

서비스(Service)는 액티비티와 달리 눈에 보이지 않는 컴포넌트입니다.
서비스의 유형은 포그라운드 서비스, 백그라운드 서비스, 바인드 서비스 3가지가 있습니다.
서비스 자체는 UI Thread에서 실행되며 오래 걸리는 작업을 서비스로 해야 하는 경우에는 서비스 내에
별도의 스레드를 만들어서 작업해야 합니다.

브로드캐스트 리시버(Broadcast Receiver)는 안드로이드에서 발생하는 특정 이벤트를 수신할 수 있는 컴포넌트입니다.

콘텐트 프로바이더(Content Provider)는 앱의 데이터를 외부 다른 앱에 공유할 때 사용됩니다.
콘텐트 프로바이더를 구현한 앱의 데이터는 다른 앱에서 contentResolver를 통해서 접근이 가능합니다.

Activity의 라이프 사이클에 대해 설명
그려서 외우기.

Fragment의 라이프 사이클에 대해 설명
그려서 외우기.

Fragment에 대해 설명
Fragment는 태블릿의 등장으로 화면 크기가 커지면서 하나의 화면에 여러 개의 화면을 구성하고,
각 화면의 생명 주기를 관리하기 위해서 생겨났습니다.

Activity와 Fragment의 차이점 설명
Activity는 독립적으로 존재할 수 있는 반면에, Fragment는 독립적으로 존재할 수 없습니다.

Activity와 Fragment의 통신 방법에 대해 설명
ㅇㅇ

서비스(Service)를 사용한 적 있는지
서비스는 FCM을 연동할 때 PUSH 메시지를 받기 위해서 Service를 사용했었습니다.

서비스의 유형에 대해서 설명
1) 포그라운드 서비스: startForegroundService()로 시작하고, 알람을 표시해야 합니다.
2) 백그라운드 서비스: 사용자에게 직접 보이지 않는 작업을 수행하는 서비스입니다.
(Android 8.0부터 백그라운드에 대한 제한이 있음)
3) 바인딩 서비스: 서버-클라이언트로 상호작용할 수 있는 서비스입니다.
(서비스는 자신의 호스팅 프로세스의 기본 스레드에서 시작함!!!)

브로드캐스트리시버(Broadcast Receiver)의 등록 방법에 대해 설명
정적인 등록 방법과 동적인 등록 방법이 있습니다.
정적인 등록 방법은 매니페스트 파일에서 등록하고, 동적인 등록 방법은 코드 상에서 등록합니다.

콘텐트 프로바이더(ContentProvider)를 사용한 적 있는지
네, 사용했던 적이 있습니다. 저는 앨범에서 이미지를 불러올 때 사용했었고, Android github에 있는 콘텐트 프로바이더 샘플앱의 내부 디비에 저장된 데이터를 불러오는 것을 구현했습니다.

다른 액티비티가 일부만 가리면 어떤 LifeCycle 메서드가 호출되는지?
onPause()까지 호출됩니다.

가린 액티비티가 종료되어 원래 액티비티로 돌아오면 어떤 LifeCycle 메서드가 호출되는지?
onResume()이 호출됩니다.

전체를 가리면 어떤 LifeCycle 메서드가 호출되는지?
onStop()까지 호출됩니다.

전체를 가렸다가 다시 돌아오면 어떤 LifeCycle 메서드가 호출되는지?
onRestart() -> onStart()가 호출됩니다.

케이스 별로 생명주기 메서드가 호출되는 순서(암기할 것)
- 시작할 때: onCreate -> onStart -> onResume
- 화면 회전할 때: onPause -> onStop -> onDestroy -> onCreate -> onStart -> onResume
- 다른 액티비티가 위에 뜰 때/전원 키로 화면 OFF할 때/홈 키: onPause -> onStop
- 백 키로 액티비티 종료: onPause -> onStop -> onDestroy
- 백 키로 기존 액티비티에 돌아올 때/홈 키로 나갔다가 돌아올 때: onRestart -> onStart -> onResume
- 다이얼로그 테마 액티비틴 투명 액티비티가 위에 뜰 때: onPause

액티비티 라이프타임(암기할 것)
- 전체 라이프타임: onCreate < onStart, onResume, onPause, onStop < onDestory
- 가시 라이프타임: onStart < onResume, onPause < onStop
- 포그라운드 라이프타임: onResume < < onPause

onDestory()가 호출되는 경우가 언제인지 설명
onDestroy()가 호출되는 경우는 finish() 메서드가 호출되는 경우 또는 시스템에 의해서 종료될 때 호출됩니다.
시스템에 의해 종료되는 경우는 앱이 여러 개의 태스크를 사용 중일 때
메모리가 부족하면 백그라운드의 태스크에서 액티비티를 종료합니다.

태스크가 무엇인지 설명
태스크는 액티비티 작업 묶음 단위입니다.
예를 들어 A, B, C 액티비티가 차례대로 실행된다면 액티비티 백스택에 A,B,C액티비티가 차례대로 쌓이고 이것이 하나의 태스크가 됩니다.

액티비티의 launch mode에 대해 설명
Launch mode는 호출자 액티비티(호출하는 액티비티), 피호출자 액티비티(불려지는 액티비티)가 있을 때, 피호출자 액티비티에 적용하는 속성으로 4가지가 있습니다.
- standard: 태스크의 TopActivity에 매번 새로운 액티비티 인스턴스를 생성합니다.
- singleTop: 태스크의 TopActivity에 이미 있는 경우 onNewIntent() 메서드로 호출자 액티비티가 Intent를 전달합니다. TopActivity에 없을 때는 standard와 동일합니다. (onNewIntent는 onCreate처럼 override하는 함수이고 onNewIntent -> onResume으로 넘어감)
- singleTask: A의 launchMode가 singleTask이고, A B C A 순서대로 호출했을 경우, A만 남게 됩니다.
- singleInstance: A의 launchMode가 singleInstance이고, A B C A를 호출했을 경우, B C/ A로 두개의 태스크가 됩니다.

taskAffinity에 대해서 설명
액티비티가 관련된 태스크에 들어갈 때 참고하는 값입니다. 별도로 지정하지 않으면 앱의 패키지명이 들어갑니다.

Intent에 대해 설명
Intent는 어플리케이션의 컴포넌트 간에 작업 수행을 위한 정보를 전달하는 역할을 합니다.
기본적으로 액션과 데이터로 구성되어 있으며, 액션은 수행할 기능, 데이터는 액션이 수행될 대상 데이터를 말합니다.

명시적 Intent와 암시적 Intent의 차이점에 대해 설명
명시적 Intent는 인텐트에 클래스 객체나 컴포넌트 이름을 지정해서 호출될 대상을 확실히 알 수 있는 Intent를 말합니다.
암시적 Intent는 호출될 대상의 속성들을 지정했지만, 호출될 대상이 달라질 수 있는 Intent를 말합니다.
암시적 Intent의 한가지 예로 Intent.ACTION_VIEW가 있습니다.

Intent Filter에 대해 설명
Intent Filter는 수신하고자 하는 암시적 인텐트를 정의하는 것을 말합니다.
Intent Filter는 action, data, category속성을 수신한 암시적 인텐트와 비교하여 필터링 여부를 검사합니다.

Application 클래스에 대해 설명
Application클래스는 앱 프로세스에서 가장 먼저 시작되는 클래스입니다.
앱 프로세스가 떠 있지 않은 상태에서 다른 컴포넌트가 요청을 받으면 앱 프로세스가 생성되고
Application이 먼저 시작됩니다.

onTrimMemory() 메서드에 대해 설명
onTrimMemory() 메서드는 전체 시스템에 메모리가 부족해서 원하는 만큼 백그라운드 프로세스를 실행할 수 없을 때
운영 체제에 의해서 호출되는 메서드입니다.

onLowMemory() 메서드에 대해 설명
onLowMemory() 메서드는 전체 시스템에 메모리가 부족할 때 호출되며,
일반적으로 모든 백그라운드 프로세스가 제거되었을 때 호출됩니다.

안드로이드의 커널에 대해 설명
안드로이드의 커널은 리눅스 커널을 기반으로 불필요한 것을 제거하고
필요한 기능(low memory killer 등)을 확장 패치한 것입니다.

compileSdkVersion, targetSdkVersion, minSdkVersion 에 대해 설명
compileSdkVersion는 컴파일시 어느 버전의 android.jar를 사용할 것인지 지정하는 API레벨을 의미합니다.
컴파일시에만 적용되며 런타임에는 영향을 끼치지 않습니다.

targetSdkVersion은 애플리케이션이 기기에서 동작할때(런타임) 사용되는 API레벨을 의미합니다.
OS버전 < targetSdkVersion일 경우, OS버전으로 동작
OS버전 > targetSdkVersion일 경우, targetSdkVersion으로 동작

minSdkVersion은 애플리케이션을 실행하는데 필요한 최소 API레벨을 의미합니다.
기기의 OS버전이 minSdkVersion보다 낮을 경우, 애플리케이션이 설치되지 않습니다.

RTL이 무엇인지 설명
아랍어의 경우는 텍스트를 읽는 방향이 오른쪽에서 왼쪽으로 읽는 RTL입니다.
그래서 아랍어같은 RTL 언어로 서비스를 제공할 경우 이를 설정해야 하는 것으로 알고 있습니다.

LMK(Low Memory Killer)에 대해 설명
LMK(Low Memory Killer)는 가용 메모리가 설정된 Threshold 이하로 떨어지게 되면, 우선순위에 따라서 프로세스를 종료시키는 역할을 합니다.

안드로이드에서 레이아웃이 그려지는 과정에 대해 설명
Activity가 포커스를 얻게 되면 시스템은 Activity의 Root Node를 요청합니다. (setContentView에 세팅한 레이아웃이 Root Node)
View는 레이아웃의 Root Node를 시작으로 레이아웃 트리를 순회하면서 View를 그리기 시작합니다.
View를 그리는 과정은 Measure[메져]->Layout->Draw 3단계로 진행이 됩니다.
측정(Measure) 단계에서 뷰의 크기를 측정하고, 레이아웃(Layout) 단계에서 뷰의 크기와 위치를 결정하고, 그리기(Draw) 단계에서 뷰를 화면에 그립니다.

View와 ViewGroup의 차이점에 대해서 설명
View는 Button, EditText, TextView와 같이 안드로이드에서 UI를 구성하는 기본 요소를 말합니다.
ViewGroup은 ConstraintLayout, LinearLayout과 같이 View 또는 ViewGroup을 포함하는 요소를 말합니다.

Display, Window, Surface, Canvas에 대해서 설명

• Display는 안드로이드의 화면을 의미합니다.
  
• Window는 1개의 Surface를 가진 틀이라고 할 수 있습니다. Window의 예시로는 Dialog, Activity, status bar 등이 있습니다.
  
• Surface는 픽셀들을 가지고 있는 객체입니다. 일반적으로 2개의 버퍼를 가지고 동작합니다.
  
• Canvas는 실제 UI를 그리기 위한 공간으로 비트맵이 그려지는 공간입니다.
  

Surface의 이중 버퍼 렌더링에 대해서 설명
스크린에 출력될 화면 데이터는 프레임 버퍼에 저장됩니다.
그런데 하나의 버퍼만 가지는 경우, 이미지를 반복해서 그리거나 다 그려지지 않은 채로 렌더링해야 될 때가 있는데
이때 깜박임 현상이 발생할 수 있습니다.
이를 해결하기 위해 프레임 버퍼에 바로 렌더링 하지 않고, 다른 버퍼를 하나 만들어서 그 버퍼에 렌더링을 완료 하고
다음 프레임 버퍼에 옮기는 방식을 사용하여 Flicker 현상을 해결할 수 있습니다.

SurfaceView에 대해서 설명
게임처럼 복잡하고 빠른 그래픽 처리가 요구되는 애플리케이션에 SurfaceView가 사용됩니다.
SurfaceView는 백그라운드 스레드에서 강제로 화면을 그립니다.
SurfaceView는 Canvas가 아닌 Surface(= 가상 메모리 화면)에 그리고 그려진 Surface를 화면에 뿌리기 때문에 게임이나 카메라 같은 높은 반응성이 필요한 UI 작업이 필요한 경우 사용할 수 있습니다
SurfaceView는 더블 버퍼링 기법을 사용합니다.
SurfaceView의 구조는 Surface와 SurfaceHolder 로 구성되며, SurfaceHolder가 Surface에 미리 그리고, 이 Surface가 SurfaceView에 반영하는 구조입니다.

NDK에 대해서 설명
NDK는 안드로이드에서 C나 C++ 같은 네이티브 코드를 사용할 수 있도록 도와주는 툴킷입니다.

안드로이드 key hash값에 대해서 설명
Key Hash는 앱의 signing key를 해시 함수를 거쳐 나온 해시키값을 말합니다.
signing key는 안드로이드 스튜디오 설치 후 한번이라도 빌드를 하면 자동으로 생성되는 키값이며
PC마다 고유한 값입니다.

FCM(Firebase Cloud Messaging)의 원리
FCM은 먼저 앱에 FCM 관련 설정과 서비스를 구현합니다.
그러면 자동으로 Firebase 서버에 token을 요청하고 Firebase 서버는 앱으로 token을 전달합니다.
그러면 구현한 서비스가 실행되면서 token값을 받습니다.
보통 이 token값을 앱의 서버 DB에 저장합니다.
그리고 푸시 알림을 보내야 할 경우, 앱 서버에서 token과 데이터를 Firebase 서버로 전달합니다.
Firebase 서버에서 앱에 푸시 알림을 전송합니다.

안드로이드 런타임(Android RunTime, ART)에 대해 설명
기존의 달빅 가상 머신(Dalvik VM)의 한계점을 해결하기 위해서 새로 나온 런타임입니다.
원래는 AOT컴파일러를 기반으로 작동하며, 최근에는 JIT컴파일러와 AOT 컴파일러가 같이 사용됩니다.

달빅(Dalvik VM)과 ART(Android RunTime)의 차이점에 대해 설명
달빅 가상 머신(Dalvik VM)은 JIT 컴파일러를 사용하고
ART(Android RunTime)는 JIT 컴파일러와 AOT 컴파일러를 함께 사용합니다.

JIT(Just In Time)컴파일러와 AOT(Ahead Of Time)컴파일러의 차이점에 대해 설명
JIT(Just In Time)컴파일러는 앱 최초 실행시 자바 코드가 일정 부분 한꺼번에 변환이 되며,
변환된 내용을 메모리에 올려둡니다.
JIT의 단점은 JIT컴파일러가 돌아가는 동안에 하드웨어 부하가 크게 발생하고 배터리 소모가 심한 단점이 있습니다.
또한, 애플리케이션 실행시 실행 부분 전체를 RAM에 상주시켜야 합니다.

AOT(Ahead Of Time) 컴파일러는 애플리케이션 설치시 한번에 컴파일하여 바이트 코드로 변환해두고 있다가
프로그램 실행시 변환된 코드를 읽어 들이는 방식입니다.
AOT는 설치 공간을 더 많이 차지하고, 애플리케이션 설치 시간이 느리다는 단점이 있습니다.

WebViewClient의 onPageStarted(),shouldOverrideUrlLoading(),onPageFinished()의 호출 순서
shouldOverrideUrlLoading() -> onPageStarted() -> onPageFinished() 순으로 호출됩니다.
- shouldOverrideUrlLoading(): WebView에서 새로운 URL이 로드될 때 이를 컨트롤할 수 있는 함수입니다.
- onPageStarted(): 페이지 로딩을 시작할 때 호출되는 콜백 함수입니다.
- onPageFinished(): 페이지 로딩을 끝냈을 때 호출되는 콜백 함수입니다.

shouldOverrideUrlLoading()의 리턴값이 true/false의 차이점
1) WebViewClient를 제공한 경우
- shouldOverrideUrlLoading()가 true를 리턴: 현재 WebView가 URL로드를 중단한다.
- shouldOverrideUrlLoading()가 false를 리턴: WebView는 정상적으로 URL로드를 진행한다.
2) WebViewClient를 제공하지 않은 경우
- WebView는 Activity Manager에게 URL에 대한 적절한 처리기를 선택하도록 요청한다.

JNI(Java Native Interface)에 대해서 설명
JNI는 Java와 네이티브 언어 사이를 연결시켜 주는 인터페이스입니다.

JavaScript와 WebView와의 통신 방법에 대해서 설명
JavaScript에서 Android의 메서드를 호출하기 위해서 JavaScriptInterface 어노테이션을 사용합니다.
그리고 안드로이드에서 웹을 호출할때는 loadUrl() 메서드를 사용합니다.

의존성 주입(Dependency Injection)에 대해 설명
의존성 주입(Dependency Injection)은 다른 클래스의 인스턴스를 생성자나 필드를 통해서 주입받는 것을 말합니다.

Dagger에 대해서 설명
Dagger는 컴파일 타임에 의존성을 주입하는 의존성 주입 프레임워크입니다.
- @Module: 클래스에만 붙인다. 의존성 주입에 필요한 객체들을 Provide메소드를 통해 관리한다.
- @Provide: @Module클래스 안에 선언된 메소드에만 붙인다. 컴포넌트에게 객체를 제공하는 역할을 한다.
- @Inject: 필드, 생성자, 메소드에 붙여서 컴포넌트로부터 객체를 주입받을 수 있게 한다.(인터페이스, 써드파티 라이브러리 클래스에는 사용할 수 없다.)
- @Component: interface 또는 abstract 클래스에 붙일 수 있다. 컴파일 타임에 어노테이션 프로세서에 의해 생성된 클래스는 접두어 Dagger와 @Component가 붙은 클래스이름이 합쳐진 형식의 이름을 갖는다. @Component 어노테이션이 달린 interfacce 또는 abstract 클래스에는 적어도 하나의 추상 컴포넌트 메소드가 있어야 한다. 컴포넌트 메소드에는 Provision 메서드와 Member-Injection 메서드가 있다.
- Provision Method: 매개변수가 없고, 모듈이 제공하는 객체의 타입을 반환형으로 갖는다. 생성된 컴포넌트 클래스에서 이 메소드를 이용하여 객체를 얻을 수 있습니다.
- Member-Injection Method: 의존성을 주입시킬 객체를 메소드의 파라미터로 넘기는 방법입니다. 멤버인젝션 메소드를 호출 하게 되면 타겟 클래스 내의 @Inject 필드에 객체를 주입받게 됩니다.
- @Component.Builder: 컴포넌트를 생성하기 위한 Builder용 애노테이션입니다. Component 내의 abstract 클래스 또는 interface에 이 애노테이션을 붙입니다. 다음과 같이 Builder를 정의 할 수 있습니다.

Koin에 대해서 설명
Koin은 순수 코틀린으로 개발된 의존성 주입 라이브러리입니다.
Koin은 lazy키워드를 통해서 런타임에 의존성을 주입합니다.

Koin의 장/단점에 대해 설명
Koin의 장점은 프로젝트에 빠르게 적용할 수 있다는 점이 가장 크고, 별도의 어노테이션을 사용하지 않기 때문에 컴파일 시간이 단축된다는 장점이 있습니다.
반면에 단점은 런타임에서 에러가 날 가능성이 존재한다는 것이 단점입니다.

Koin과 dagger의 차이점에 대해 설명
Dagger는 어노테이션을 통해서 컴파일타임에 의존성을 주입합니다.
그렇기 때문에 컴파일 과정이 느려질 순 있지만 런타임에 에러가 날 가능성이 적다는 장점이 있습니다.
반면에 Koin은 런타임에 의존성을 주입합니다.
그렇기 때문에 컴파일 과정에서의 오버헤드는 없지만 런타임에서 에러가 날 가능성이 존재합니다.

Retrofit에 대해 설명
Retrofit은 HTTP통신에 사용되는 클라이언트 라이브러리이고, OkHttp라이브러리를 네트워크 레이어로 사용하고 있습니다.

Retrofit의 동작 원리에 대해서 설명
Retrofit을 사용하기 위해서 먼저 사용할 API를 인터페이스로 정의합니다. 그리고 레트로핏 빌더의 create 메서드를 통해서 인터페이스의 구현체를 생성합니다. 구현체의 생성에는 프록시와 리플렉션이 사용됩니다. 구현체를 생성하는 과정은 런타임에 어노테이션을 파싱해서 리플렉션을 통해 정의한 인터페이스를 읽고 이를 바탕으로 프록시 클래스를 만들고 그 구현체를 생성합니다. 이후 생성된 구현체를 통해 네트워크 통신을 진행합니다.

OkHttp의 동작 원리에 대해서 설명
OkHttp라이브러리는 내부적으로 여러 인터셉터들의 체이닝으로 동작합니다. BridgeInterceptor, CacheInterceptor등을 거쳐서 마지막에 CallServerInterceptor에서 request를 날리고 response를 받아 통신하는 것으로 알고 있습니다.

Gson에 대해 설명
Gson은 자바 오브젝트와 JSON간의 변환을 도와주는 라이브러리입니다.

Glide에 대해서 설명
Glide는 안드로이드의 이미지 로딩 라이브러리입니다.
내부적으로 커스텀된 HttpUrlConnection을 사용하며
Volley나 OkHttp를 연결할 수 있는 유틸리티 라이브러리도 포함하고 있습니다.

Glide 캐시에 대해서 설명
Glide 캐시는 메모리 캐시와 디스크 캐시가 사용됩니다.
Glide를 통해서 이미지를 불러올 경우, 먼저 메모리 캐시를 확인해서 데이터가 있으면 메모리 캐시에서 가져옵니다.
메모리 캐시에 없을 경우 디스크 캐시를 확인합니다.
디스크 캐시에 있으면 메모리 캐시에 저장한 후 데이터를 가져옵니다.
디스크 캐시에 없으면 네트워크 통신을 통해서 데이터를 가져옵니다.
그래서 디스크 캐시에 저장하고 그다음 메모리 캐시에 저장한 다음 데이터를 가져옵니다.

Glide 메모리 캐시와 디스크 캐시에 어떤 알고리즘 사용되는지 설명
LRU알고리즘이 사용됩니다. LRU알고리즘은 가장 오랫동안 참조되지 않은 것을 대체하는 알고리즘입니다.

코루틴 빌더: launch, async, runBlocking - 일시 중단 알고리즘을 만드는데 사용됨. 코루틴 빌더를 호출할 때 전달하는 코드는 일시 중단 람다이다.
일시 중단 함수(suspending functions)
- 일시 중단 함수를 만드려면 suspend 제어자만 추가하면 된다.
- 일시 중단 함수는 delay()와 같은 다른 일시 중단 함수를 직접 호출할 수 있다.
- 일시 중단 함수는 코드를 코루틴 빌더 안에 감쌀 필요가 없기 때문에 명확하고 가독성 있음.
- 일시 중단 연산은 다른 일시 중단 연산에서만 호출될 수 있다.
- 비 일시 중단 코드에서 일시 중단 함수를 호출하려면 코루틴 빌더로 감싸야 한다.
코루틴 컨텍스트(Coroutine Context)
코루틴은 항상 컨텍스트 안에서 실행된다.
컨텍스트는 코루틴이 어떻게 실행되고 동작해야 하는지를 정의할 수 있게 해주는 요소들의 그룹이다.
- 디스패처(Dispatcher): 코루틴이 실행될 스레드를 결정(시작될 곳과 중단 후 재개될 곳을 모두 포함)
-- CommonPool
채널

AndroidTest와 Test의 차이점에 대해서 설명
AndroidTest는 하드웨어나 에뮬레이터에서 실행되는 테스트입니다. 반면에 Test는 컴퓨터의 JVM 위에서 실행되는 테스트입니다.

Mockito에 대해서 설명
Mockito는 모의 객체를 주입해주는 자바 기반의 프레임워크입니다.

Mockito는 왜 사용했나요
유닛테스트시 실제 객체가 아니라 모의 객체를 통해서 테스트하기 위해서 사용했습니다.

• 테스트할때 모의 객체를 사용하신 이유가 있나요. 요즘에 유닛테스트 공부중이다 –> 처음에는 실제 객체로 테스트해야 된다고 생각했다 –> 해보니 잘 안됐다 –> 찾아보니 모의 객체를 많이 사용하더라 –> 테스트 더블이라는 용어도 알게 됨 –> mockito를 사용해서 stubbing 했음 TDD(Test Driven Development)에 대해 설명 TDD(Test Driven Development)는 프로그램 설계 후 테스트 코드를 먼저 작성해서 설계를 보완하고, 이를 토대로 코드를 작성하는 개발 방법론을 말합니다.

Hamcrest에 대해 설명
Hamcrest는 조금 더 가독성 있는 테스트 코드를 짤 수 있도록 도와주는 라이브러리입니다.

테스트 더블(Test Doubles)에 대해 설명
테스트 더블은 실제 객체로 테스트가 어려운 경우 이를 대신해서 사용할 수 있는 객체들을 말합니다.

테스트 더블의 종류와 그 종류들에 대해 설명

테스트 더블은 크게 Dummy, Fake, Stub, Spy, Mock으로 나뉩니다.

• Dummy는 인스턴스화된 객체만 필요하고 객체의 기능은 필요하지 않을 때 사용됩니다.
• Fake는 실제 구현을 단순화시켜서 만든 테스트 객체를 말합니다.
• Stub은 테스트에서 호출된 요청에 대해서 미리 준비해둔 결과를 제공하는 것을 말합니다. Android에서 자주 사용되는 Mockito 역시 Stub입니다.
• Spy는 Stub의 역할을 가지면서 호출된 내용에 대해 약간의 정보를 기록합니다. Mockito의 verify가 이와 같은 역할을 합니다.
• Mock은 행위 검증을 하는 모의 객체를 말합니다.

상태 검증과 행위 검증에 대해서 설명

• 상태 검증은 메서드가 수행된 이후 주요 객체나 협력 객체의 상태를 살펴봄으로써 올바르게 동작했는지 검증하는 것을 말합니다.
• 행위 검증은 상태 검증과 달리 주요 객체나 협력 객체의 특정 메서드가 호출되었는지의 행위를 검증하는 것을 말합니다.