제가 보려고 만들었습니다. 계속 내용이 추가될 예정입니다.
잘못된 내용있으면 언제든지 말해주세요!!

안드로이드 4대 구성 요소

액티비티, 서비스, 브로드캐스트 리시버(BR), 콘텐츠 프로바이더(CP)

• 액티비티 - UI화면을 담당하는 컴포넌트
• 서비스 - 화면에 보이지 않는 백그라운드 작업을 처리할수있음
• 브로드캐스트 리시버 - 시스템 단에서 발생하는 이벤트를  앱에서 받아 처리함, 정적(매니페스트 등록), 동적으로 나뉜다.
• 콘텐츠 프로바이더 - 앱 간의 데이터 공유를 관리 - URI를 사용한다.

액티비티, 프래그먼트, AAC ViewModel, 서비스의 생명주기

다른건 다 잘 알고있고 서비스의 경우가 조금 어렵다.

• `Unbound` 서비스: 서비스가 시작되면 클라이언트가 바인딩되지 않아도 작업을 마치거나 시스템 또는 클라이언트가 명시적으로 중지할 때까지 독립적으로 실행된다. 
• `Bound` 서비스: 클라이언트가 서비스에 바인딩되어야 상호작용할 수 있으며, 하나 이상의 클라이언트가 바인딩되어 있는 동안 서비스가 계속 실행되고 모든 클라이언트가 바인딩을 해제하면 서비스는 종료될 수 있다.

두 상태에 따라서 생성 이후 메서드가 `onStartCommand`일지, `onBind(클라이언트가 없으면 onUnbind)`일지 갈린다.

ViewModel과 Jetpack의 AAC ViewModel은 어떤 차이?

ViewModel

• ViewModel은 MVC, MVP, MVVM 등 다양한 아키텍처 패턴에서 사용되는 프레젠테이션 로직을 처리하는 객체이다.
• 주로 UI 데이터를 처리하고, 화면의 상태를 유지하는 데 사용되며, 화면 회전 등으로 인해 액티비티가 다시 생성될 때 데이터를 유지할 수 있는 역할을 한다.
• 특징은 특정 플랫폼에 종속되지 않고, UI와 비즈니스 로직을 분리하는 데 집중한다.

Jetpack AAC ViewModel

• Jetpack의 AAC(ViewModel)는 Android Jetpack의 Architecture Component의 일부로, Android 앱의 수명 주기와 긴밀하게 통합된 ViewModel이다.
• Android의 수명 주기 관리에 최적화되어 있으며, 화면 회전이나 구성 변경 시에도 액티비티나 프래그먼트가 소멸되지 않는 동안 데이터를 유지할 수 있다.
• 특징은 액티비티나 프래그먼트의 수명 주기에 맞춰 메모리 누수를 방지하면서도 상태 데이터를 관리할 수 있다는 점이다.
• AAC ViewModel은 ViewModelProviders나 Hilt와 같은 DI 프레임워크를 통해 간단하게 인스턴스를 생성하고 주입할 수 있는 기능을 제공한다.

따라서, ViewModel은 다양한 아키텍처에서 사용되는 일반적인 개념이라면, Jetpack AAC ViewModel은 Android의 생명 주기를 자동으로 관리하여 구성 변경 시에도 UI 상태를 유지하는 데 특화된 구현이다.

액티비티와 프래그먼트의 차이?

각 액티비티는 독립적으로 동작하고, 다른 액티비티로 전환할 때에는 인텐트를 통해야 한다.

프래그먼트는 하나의 액티비티 안에서 재사용이 가능한 화면을 의미한다. 독립적으로 동작할 수 없고 항상 액티비티 내에 호스팅되어야 한다.

프래그먼트가 트랜잭션을 사용할 때는, 프래그먼트 매니저를 사용하는데 계층 구조가 아래와 같다.

• Host Activity (호스트 액티비티)
  
  •  FragmentActivity: 프래그먼트를 관리할 수 있는 액티비티다. 액티비티는 자신의 supportFragmentManager를 사용하여 프래그먼트를 관리한다.
  • supportFragmentManager: 액티비티의 프래그먼트들을 관리한다. 액티비티가 생성될 때 초기화되며, 액티비티(호스트) 내에서 프래그먼트의 추가, 제거, 교체 등 트랜잭션 작업을 수행할 수 있다.
• Host Fragment (호스트 프래그먼트)
  
  • Fragment: 프래그먼트는 또 다른 프래그먼트를 포함할 수 있다. 이런 프래그먼트는 호스트 프래그먼트라고 불리며, 자신의parentFragmentManager(호스트의 매니저)와 childFragmentManager(호스트해줄 매니저)를 가지고 있다.
  • parentFragmentManager: 호스트 프래그먼트가 포함된 액티비티나 상위 프래그먼트의 FragmentManager다.
  • childFragmentManager: 프래그먼트 안에 포함된 자식 프래그먼트를 관리한다. 프래그먼트 내에서 다른 프래그먼트를 추가하거나 관리할 수 있다.
• Child Fragment (자식 프래그먼트)
  자식 프래그먼트는 호스트 프래그먼트에 속한 프래그먼트다. parentFragmentManager를 통해 상위 호스트 프래그먼트와 연결된다.

그럼 Intent는?

컴포넌트(4대 컴포넌트 모두 포함) 간에 작업을 수행하도록 요청하는 메시지 객체이 명시적, 암시적 인텐트로 나뉜다.
명시적 Intent는 명확하게 시작할 컴포넌트나 액티비티를 지정하는 것,
암시적 Intent는 특정 액션을 수행할 수 있는 컴포넌트를 찾아 실행하는 것을 의미한다.(urlScheme과 같은)

암시적 Intent는 Intent filter를 사용해서 제어할 수 있다.

> `PendingIntent`도 있다.
Intent를 갖는 클래스로, 기본 목적은 다른 프로세스(애플리케이션)의 권한을 허가하여 가지고 있는 Intent를 마치 본인 앱의 프로세스에서 실행하는 것처럼 사용하는 것이다. Notification 설정할 때 봤을 것이다.
Notification을 클릭해서 그 앱으로 이동하는 건, 다른 프로세스에서 PendingIntent를 사용해서 NotificationManager로 하여금 앱을 실행시키는 것이다.

서비스는?

• 포그라운드 서비스 - 알림을 표시해 놓고 사용자와 상호 작용하지 않아도 계속 실행되는 걸 말함(음악 플레이어 같은)
• 백그라운드 서비스 - 사용자가 직접 알지 못하는 작업을 수행할 때 사용
• 바운드 서비스 - 앱 내에서 서비스를 사용하여 간단한 클라이언트 - 서버 환경을 구성하는 것을 말함(특정 컴포넌트와 서비스간 상호작용) -> onBind, onUnbind가 호출되는

옵션 3개가 있다.

• `START_STICKY` - 안드로이드가 서비스를 강제 중지한 경우, null intent를 보내서 재시작한다.
• `START_NOT_STICKY` - 안드로이드가 서비스를 강제 중지한 경우, 재시작 하지 않는다.
• `START_REDELIVER_INTENT` - 안드로이드가 서비스를 강제 중지한 경우, 이전과 동일한 intent를 보내서 재시작한다.

디자인 패턴? - MVC, MVP, MVVM

디자인 패턴은 소프트웨어 개발을 효율적으로 하기 위해 도입된, 재사용 가능한 설계를 의미한다.

• MVC - 모델 - 뷰 - 컨트롤러로 데이터 처리를 담당하는 모델, UI를 담당하는 뷰, 이걸 연결하는 컨트롤러로 구성된다.
• MVP - 뷰와 모델 사이에 프레젠터를 둬서 M-V 간의 직접 연결을 끊고, 뷰의 이벤트를 핸들링하는 역할을 한다. MVC의 진화
• MVVM - 뷰와 모델 사이에 뷰 모델이 있는 구조로, 데이터 바인딩을 통해 뷰와 뷰모델이 업데이트 되는 방식. 뷰 모델이 중간에서 데이터를 변환하거나 처리하는 것을 담당하고 뷰는 이벤트만 받는 방식을 적용하여, 뷰와 모델 사이의 의존성을 낮출 수 있다.

레거시 대비 - AsyncTask가 무엇인지? 사용시 단점은?

AsyncTask는 백그라운드 작업을 간단하게 처리하고, 그 결과를 UI 스레드에서 쉽게 업데이트할 수 있도록 설계된 클래스이다.
Android 11(API 레벨 30)에서 Deprecated되어, 코루틴, WorkManager, Handler과 같은 대안을 사용한다.

단점으로는 아래와 같다.

• 메모리 누수 (Memory Leaks):
  AsyncTask는 액티비티와 프래그먼트에서 자주 사용되었는데, 만약 액티비티가 백그라운드로 전환되거나 소멸되는 동안 AsyncTask가 계속 실행 중일 경우, 액티비티가 가비지 컬렉션(GC)에 의해 수집되지 않아 메모리 누수가 발생할 수 있다.
• 취소 및 중단의 어려움:
  AsyncTask는 cancel() 메서드를 통해 작업을 취소할 수 있지만, 백그라운드에서 작업이 이미 진행 중인 경우, 작업이 중단되지 않고 계속 진행되는 경우가 있었다.
• 작업 관리의 어려움:
  비동기 작업의 상태를 관리하고, 실행 중인 작업을 적절히 취소하는 것은 위에서 말했듯 AsyncTask에서 직접적으로 지원되지 않아서, 여러 AsyncTask가 동시에 실행되거나 연속적으로 실행될 때는 관리가 어렵다.
• ThreadPool 제한:
  AsyncTask는 내부적으로 스레드 풀을 사용했는데, 기본적으로 실행 가능한 스레드 풀의 크기가 작기 때문에, 많은 AsyncTask를 동시에 실행할 경우 스레드 풀의 대기열에 쌓여 작업이 지연될 수 있었다.
• 작업 순서 불확실성:
  AsyncTask는 Android 3.0(Honeycomb) 이후로 execute()를 호출할 때 기본적으로 직렬 실행되었지만, 이전 버전에서는 병렬 실행이 기본값이었다. 이로 인해 동작이 버전에 따라 달라졌고, 개발자가 명시적으로 executeOnExecutor()를 호출하여 병렬 실행을 명시해야 했다. 안정성이 떨어진다는 말.

대안으로 사용되는 WorkManager는 JetPack에 포함된 Android의 새로운 작업 스케줄링 라이브러리로, 백그라운드 작업을 안정적으로 처리할 수 있다. 특히, 긴 시간 실행되거나 네트워크에 의존하는 작업을 처리할 때 유용하다. 작업이 취소되었거나 장치가 재부팅된 경우에도 작업을 다시 시작할 수 있도록 설계되어 있다.

의존성 주입을 사용해봤는지? 왜 썼는지?

의존성 주입(Dependency Injection, DI)은 객체 간의 의존성을 외부에서 주입받는 방식으로, 코드의 유지보수성, 테스트 용이성, 가독성을 높이는 데 중요한 역할을 한다.

저는 Hilt를 사용했는데,  Hilt는 Google이 관리하는 Android 특화 DI 라이브러리로, 복잡한 설정 없이 DI를 쉽게 구현할 수 있는 장점이 있다.Dagger에 비해 보일러플레이트 코드를 대폭 줄여주고, 명시적인 컴포넌트 설정 없이도 간편하게 의존성을 주입할 수 있다.

Jetpack Navigation에서 popUpTo와 popUpToInclusive 차이

popUpTo

• popUpTo는 역방향 탐색 시 백 스택에서 특정 목적지까지의 프래그먼트를 제거하는 속성이다.
• 이 속성은 탐색할 때 특정 목적지 이후에 있는 모든 프래그먼트를 백 스택에서 제거하는 데 사용된다.
• 예를 들어, popUpTo="@+id/destination_home"로 설정하면 destination_home 목적지까지 역방향으로 탐색하며, destination_home 이후의 모든 프래그먼트가 제거된다.
• destination_home 자체는 백 스택에 남아 있어, 여전히 그 프래그먼트로 돌아가게 된다.

popUpToInclusive

• `popUpToInclusive`는 `popUpTo`와 함께 사용되며, 지정된 목적지 자체를 백 스택에서 제거할지 여부를 결정하는 속성이다.
• 기본값은 false로 설정되어 있으며, 이때는 popUpTo로 지정된 목적지 자체는 백 스택에서 제거되지 않고 남아 있다.
• `popUpToInclusive="true"`로 설정하면, 지정된 목적지도 포함하여 백 스택에서 제거된다.
• 예를 들어, `popUpTo="@+id/destination_home" popUpToInclusive="true"`로 설정하면, `destination_home`과 그 이후의 모든 프래그먼트가 제거된다.

따라서, `popUpTo`는 특정 목적지 이후의 프래그먼트를 제거하고, `popUpToInclusive`는 그 지정된 목적지 자체도 제거할지 여부를 결정하는 속성이다.

좀 더 부연설명하면,

• 네비게이션 그래프가 A -> B -> C -> D 라고 가정하자.
• 여기서 D에서 A로 돌아가면서 B와 C를 백스택에서 제거하려면 popUpTo="B"와 함께 popUpToInclusive=true를 설정하면 된다. 그럼 목적지인 B로 갈 때, B도 날리기 때문에 그 전의 backstack인 A만 남고 B, C, D가 백스택에서 모두 제거된다.

Dispatchers의 종류와 특징?

• Dispatchers.Main: UI 관련 작업 (메인 스레드).
• Dispatchers.IO: 네트워크, 파일 입출력 작업 (I/O 바운드 작업).
• Dispatchers.Default: CPU 집약적인 작업 (CPU 바운드 작업).
• Dispatchers.Unconfined: 특정 스레드에 얽매이지 않으며, 상황에 따라 실행 스레드가 달라짐.

동기 비동기, Blocking Non-Blocking

동기와 비동기는 작업의 순차성과 대기 상태에 대한 차이를 나타내며, 블로킹과 넌블로킹은 작업 중 대기 여부에 따라 구분되는 개념이다.

graph TD
    A[Start] --> B[Task 1 - Synchronous]
    B --> C[Task 2 - Synchronous]
    C --> D[End]
    
    A1[Start] -->|Async Execution| B1[Task 1 - Asynchronous]
    B1 -->|No Waiting| C1[Task 2 - Asynchronous]
    C1 --> D1[End]
    
    A2[Start] -->|Blocking| B2[Task - Blocking]
    B2 -->|Wait until complete| C2[End]
    
    A3[Start] -->|Non-blocking| B3[Task - Non-blocking]
    B3 -->|Instant return| C3[End]

동기(Synchronous)

• 동기 방식은 작업이 순차적으로 실행되며, 하나의 작업이 완료되기 전에는 다음 작업이 시작되지 않는다.
• 각 작업은 서로 의존하며, 작업 A가 완료되어야 작업 B가 시작된다.
• 이 방식은 블로킹 상태를 초래할 수 있다. 즉, 이전 작업이 끝날 때까지 다음 작업이 대기 상태에 놓이게 된다.
• 예: 파일을 읽을 때, 파일이 완전히 읽힐 때까지 코드가 다음 단계로 넘어가지 않는다.

비동기(Asynchronous)

• 비동기 방식은 여러 작업이 동시에 실행될 수 있으며, 하나의 작업이 완료되기를 기다리지 않고 다음 작업이 진행된다.
• 작업 간에 의존성이 없으며, 각 작업이 별도의 스레드 또는 프로세스에서 실행될 수 있다.
• 이 방식은 넌블로킹 상태를 유지하여, 작업을 기다리는 동안 다른 작업을 동시에 수행할 수 있다.
• 예: 네트워크 요청을 보내고, 응답이 올 때까지 다른 코드를 계속 실행한다.

Blocking

• 블로킹 작업은 호출된 함수나 작업이 완료될 때까지 실행 흐름이 멈추는 것을 의미한다.
• 즉, 작업이 완료될 때까지 프로그램이 대기 상태에 빠지며 다른 작업을 할 수 없다.
• 예: 파일을 블로킹 방식으로 읽으면, 파일이 완전히 읽혀질 때까지 다른 작업을 수행할 수 없다.

Non-blocking

• 논블로킹 작업은 호출된 작업이 즉시 반환되며, 실행 흐름이 중단되지 않고 계속 진행된다.
• 작업이 완료되기를 기다리지 않고 다른 작업을 동시에 진행할 수 있다.
• 예: 파일을 논블로킹 방식으로 읽으면, 파일 읽기 요청 후 즉시 다음 작업을 진행하며, 나중에 파일 읽기가 완료되면 알림을 받는다.

섞는다면 아래와 같이 적용된다.

• Sync + Blocking: 작업이 완료될 때까지 기다리고, 순차적으로 실행된다.
• Async + Blocking: 비동기적 작업이지만, 완료될 때까지 기다린다.
• Sync + Non-blocking: 순차적으로 실행되지만, 즉시 반환되므로 다른 작업을 수행할 수 있다.
• Async + Non-blocking: 비동기적 작업이며 즉시 반환되어 다른 작업을 동시에 처리할 수 있다.

Serializable과 Pacelable 차이

OkHttp와 Retrofit2의 차이

OkHttp와 Retrofit은 둘 다 네트워크 통신을 위한 라이브러리이지만, OkHttp는 더 낮은 수준의 HTTP 클라이언트 라이브러리이고, Retrofit은 OkHttp를 기반으로 동작하는 고수준의 REST 클라이언트 라이브러리이다. Wrapping된게 Retrofit이라고 봐야된다.

git merge와 rebase의 차이?

rebase는 커밋 히스토리를 재구성해서 깔끔한 커밋 그래프를 만들어준다.

git과 git flow의 차이는 무엇인가요?

• Git은 버전 관리 도구이며, 소스 코드의 변경 사항을 관리하는 시스템이다.
• Git Flow는 Git을 기반으로 한 브랜칭 전략으로, 개발, 릴리스, 배포 프로세스를 체계적으로 관리하기 위한 방법론이다.

interface와 abstract 차이? -> 일반적인 정의, 코틀린에서의 정의

• 인터페이스는 구현이 없는 메서드 선언을 제공하며, 여러 클래스에서 공통적으로 구현할 동작을 정의하고, 다중 상속이 가능하다.
• 추상 클래스는 추상 메서드와 일반 메서드를 모두 포함하며, 상속을 통해 공통 동작을 재사용할 수 있다. 단일 상속만 가능하다.

안드로이드 권장 아키텍쳐?

graph TD
    subgraph Presentation Layer
        A[View]
        A -->|사용자 입력| B[ViewModel]
        B -->|LiveData or StateFlow| A
    end
    
    subgraph Domain Layer - optional
        B --> F[UseCase]
    end
    
    subgraph Data Layer
        F --> C
        B --> C[Repository]
        C --> D[Local Database]
        C --> E[Network]
        E --> C
        D --> C
    end

https://developer.android.com/topic/architecture?hl=ko&_gl=1*ee4yak*_up*MQ..*_ga*MTQwODM3NjUyMy4xNzI3NjEyMzEz*_ga_6HH9YJMN9M*MTcyNzYxMjMxMi4xLjAuMTcyNzYxMjMxMi4wLjAuNzk3MTIxNjY0

• 모듈화: 각 레이어가 독립적으로 설계되어 있어 코드가 분리되어 유지보수가 쉽고, 팀에서 협업하기 용이해진다.
• 유지보수성: 각 레이어가 분리되어 있으므로, 특정 기능이 수정되더라도 다른 부분에 영향을 주지 않는다.
• 확장성: 레이어 간의 의존성이 낮기 때문에 새로운 기능을 추가하거나 확장하기 쉽다.
• 테스트 용이성: 각 레이어는 독립적으로 테스트할 수 있어 단위 테스트 및 통합 테스트가 용이하다.

Google의 앱아키텍쳐에서는 ‘domain layer가 data layer를 알고 있다’이고,
밥의 클린 아키텍쳐는 Domain layer는 아무도 몰라야 하고,Presentation layer, Data layer가 Domain layer에 의존해야 한다.

근데 구글의 앱 아키텍쳐에서 Domain레이어는 optional이다. 뷰모델에서 조합해서 사용해도 무관하다.

::출처::

https://1-three.tistory.com/129

https://velog.io/@godmin66/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-%EC%A4%91-%EB%82%98%EC%99%94%EB%8D%98-%EC%A7%88%EB%AC%B8-%EB%AA%A9%EB%A1%9D

https://github.com/devSquad-study/2023-CS-Study/tree/main

https://github.com/4z7l/tech_interview.zip

https://github.com/VSFe/Tech-Interview?tab=readme-ov-file

https://github.com/WooVictory/Ready-For-Tech-Interview

https://github.com/gyoogle/tech-interview-for-developer

https://github.com/JaeYeopHan/Interview_Question_for_Beginner

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

https://www.acmicpc.net/problem/2559

오답노트(푸는 동안 사고과정 및 개선점)

누적합 문제다. 

처음에 고려안한 부분은 누적합 배열 시작 인덱스 부분이다.

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class Main {
    static int n, gap;

    public static void main(String[] args) throws Exception {
        //System.setIn(new FileInputStream("res/input.txt"));
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        gap = Integer.parseInt(st.nextToken());
        int[] in = new int[n];
        int[] prefix = new int[n];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < n; i++) {
            in[i] = Integer.parseInt(st.nextToken());
            if (i == 0) {
                prefix[i] = in[i];
            } else {
                // 누적합
                prefix[i] = prefix[i - 1] + in[i];
            }
        }
        PriorityQueue<Integer> pq = new PriorityQueue<>((o1, o2) -> {
            return o2 - o1;
        });
        //이제 각 간격의 합을 pq에 넣기
        int idx = n - 1;
        while (true) {
            if (idx - gap < 0) break;
//            System.out.println(prefix[idx] + ", " + prefix[idx - gap]);
            pq.add(prefix[idx] - prefix[idx - gap]);
            idx--;
        }

        System.out.println(pq.poll());
    }
}

이렇게 해버리면 무슨 문제가 생기냐면 

10 3
100 -1 -1 -1 -1 -1 -1 -1 -1 -1

이 입력이 들어올 때 누적합 배열에는 다 들어가지만, 간격을 더할 때 98이 최대값이 아니라 3이 최대값이 나와버린다.

[100, 99, 98, 97, 96, 95, 94, 93, 92, 91]

이게 size가 n인 prefix인데, 내 로직 상 `n`번째 - `n-k`번째 누적합 항목을 빼면 그 사이의 누적합이 나오도록 되어있다. 이 경우 -3이 나오게 되고, 원래라면 100, -1, -1 이 세 수의 합이 98인데, 시작 항목을 간격으로 잡고 가버린 셈이 돼서 -3이 나오게 됐다. 그래서 시작 부분을 고려하게 되면 n+1 크기를 가진 prefix 배열을 만들어야 하고, 아래와 같이 누적합 배열이 구성된다.

prefix 배열 구성할 때는 그래서 1칸 더 크게 하는게 좋을 것 같다. DP랑 거의 동일한 개념으로 이해했다.

[0, 100, 99, 98, 97, 96, 95, 94, 93, 92, 91]

비슷한 문제로 연속합이 있다.

몇 번 연속해도 좋으니까 연속한 합이 가장 큰 수를 구하는 문제다.

https://www.acmicpc.net/problem/1912

여기서 떠올린 아이디어는 어차피 누적해서 합하는데, 값이 작아지는 경우에는 더하지 않고 가겠다는 것이다.

for (int i = 0; i < n; i++) {
    in[i] = Integer.parseInt(st.nextToken());
}
PriorityQueue<Integer> pq = new PriorityQueue<>((o1, o2) -> {
    return o2 - o1;
});
for (int i = 1; i <= n; i++) {
    prefix[i] = Math.max(prefix[i-1]+in[i-1], in[i-1]);
    pq.add(prefix[i]);
}

이러면 값이 주어진 입력 배열보다 작은 누적합 위치가 발생하면, 누적합 값에 이전 연속합을 무시하고, 새로 시작한다.

일종의 DP라고 볼수도 있지않을까?

좀 더 난이도있는 문제를 살펴보기 위해 누적합을 2번쓰는 문제를 풀어봤다.

https://www.acmicpc.net/problem/2304

문제를 잘 읽어야한다. 선분 시작점을 주는 것이 핵심이다.

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws Exception {
        // System.setIn(new FileInputStream("res/input.txt"));
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        int n = Integer.parseInt(st.nextToken());
        int maxH = -1;
        int maxIdx = -1;
        int[] input = new int[10001];

        for (int i = 0; i < n; i++) {
            st = new StringTokenizer(br.readLine(), " ");
            int idx = Integer.parseInt(st.nextToken()); // 기둥 왼쪽면의 위치
            int h = Integer.parseInt(st.nextToken());
            input[idx + 1] = h; // idx 자체는 0이 없으나, 0-1 ,1-2 이렇게 간격으로 들어감 -> 정확히는 왼쪽 모서리 기준이니까 하나씩 밀기
            maxIdx = Math.max(idx, maxIdx);
            maxH = Math.max(h, maxH);
        }


        int[] pref = new int[maxIdx + 2]; // 앞뒤에 한칸씩 추가하기
        int[] suff = new int[maxIdx + 2]; // 앞뒤에 한칸씩 추가하기
        int[] maxPoint = new int[2]; //
        Arrays.fill(maxPoint, -1);
        int prev = 0;
        int prefSum = -1;
        int suffSum = -1;
        // l to r
        for (int i = 1; i <= maxIdx + 1; i++) {
            prev = Math.max(input[i], prev);
            pref[i] = pref[i - 1] + prev;
            if (input[i] == maxH) {
                maxPoint[0] = i;
                break;
            }
        }
        prev = 0;
        for (int i = maxIdx + 1; i >= 0; i--) {
            prev = Math.max(input[i], prev);
            suff[i - 1] = suff[i] + prev;
            if (input[i] == maxH) {
                maxPoint[1] = i;
                break;
            }
        }
        // max까지 합
        int maxLToR = -1;
        int maxRToL = -1;
        for (int i = 0; i < maxPoint[0]; i++) {
            maxLToR = Math.max(maxLToR, pref[i]);
        }
        for (int i = maxIdx + 1; i >= maxPoint[1]; i--) {
            maxRToL = Math.max(maxRToL, suff[i]);
        }
//        System.out.println(maxLToR + ", " + maxRToL);

        // 합치기

        int maxWidth = maxPoint[1] - maxPoint[0] + 1;

//
//        System.out.println(Arrays.toString(pref) + ", " + maxPoint[0] + ", " + maxH);
//        System.out.println(Arrays.toString(suff) + ", " + maxPoint[1] + ", " + maxH);
        System.out.println(maxLToR + maxRToL + maxWidth * maxH);
    }
}

완전히 같은 방식으로 아래 문제도 풀수있다.

https://www.acmicpc.net/problem/14719

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws Exception {
        System.setIn(new FileInputStream("res/input.txt"));
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int H = Integer.parseInt(st.nextToken());
        int W = Integer.parseInt(st.nextToken());

        int[] heights = new int[W];
        st = new StringTokenizer(br.readLine(), " ");
        for (int i = 0; i < W; i++) {
            heights[i] = Integer.parseInt(st.nextToken());
        }

        int[] leftMax = new int[W]; // 얘네가 창고다각형에 있던 prefix, suffix 역할
        int[] rightMax = new int[W];

        // 왼쪽에서 본 최대 높이 계산
        leftMax[0] = heights[0];
        for (int i = 1; i < W; i++) {
            leftMax[i] = Math.max(leftMax[i - 1], heights[i]);
        }

        // 오른쪽에서 본 최대 높이 계산
        rightMax[W - 1] = heights[W - 1];
        for (int i = W - 2; i >= 0; i--) {
            rightMax[i] = Math.max(rightMax[i + 1], heights[i]);
        }

        // 빗물이 고일 수 있는 양 계산
        int water = 0;
        for (int i = 0; i < W; i++) {
            int minHeight = Math.min(leftMax[i], rightMax[i]);
            if (minHeight > heights[i]) {
                water += minHeight - heights[i];
            }
        }

        System.out.println(water);
    }
}

정답코드

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class Main {
    static int n, gap;

    public static void main(String[] args) throws Exception {
        System.setIn(new FileInputStream("res/input.txt"));
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        gap = Integer.parseInt(st.nextToken());
        int[] in = new int[n];
        int[] prefix = new int[n+1];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < n; i++) {
            in[i] = Integer.parseInt(st.nextToken());
            prefix[i+1] = prefix[i] + in[i];
        }
        System.out.println(Arrays.toString(prefix));

        PriorityQueue<Integer> pq = new PriorityQueue<>((o1, o2) -> {
            return o2 - o1;
        });
        //이제 각 간격의 합을 pq에 넣기
        int idx = n;
        while (true) {
            if (idx - gap < 0) break;
            pq.add(prefix[idx] - prefix[idx - gap]);
            idx--;
        }

        System.out.println(pq.poll());
    }
}

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class Main {
    static int n;

    public static void main(String[] args) throws Exception {
        // System.setIn(new FileInputStream("res/input.txt"));
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        int[] in = new int[n];
        int[] prefix = new int[n + 1];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < n; i++) {
            in[i] = Integer.parseInt(st.nextToken());
        }
        PriorityQueue<Integer> pq = new PriorityQueue<>((o1, o2) -> {
            return o2 - o1;
        });
        for (int i = 1; i <= n; i++) {
            prefix[i] = Math.max(prefix[i-1]+in[i-1], in[i-1]);
            pq.add(prefix[i]);
        }
//        System.out.println(Arrays.toString(prefix));
        
        System.out.println(pq.poll());
    }
}

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

안드로이드 외부 환경과 연동하는 프로젝트를 진행하고있다. 안드로이드와 연계된 부분을 테스트를 하려면 매번 새로 빌드 받아 테스트 모바일 기기에 설치해야 하는데 매번 설치를 요청하는 것도, 매번 연결해서 설치하는 것도 상당히 비효율적이라는 생각이 들었다. Github Actions로 build하여 artifacts로 뽑아본 경험이 있었기에, gitlab의 비슷한 기능인 gitlab pipeline을 사용하면 되지않을까? 라는 생각으로 이번에 도전해봤다.

이번에 해볼 것은 gitlab-pipeline으로  안드로이드 프로젝트를 build 해서, artifacts로 debug apk를 추출하는 것이다.

Windows에서 로컬 환경 Gitlab-Runner 초기 세팅하기

사용하기 쉬운 환경을 위해서 Docker와 Docker-Compose를 사용해 gitlab-runner를 설치할 것이다. docker-desktop을 먼저 설치하면 된다.

docker에 있는 terminal을 사용할 건데, 리눅스 명령어가 동작하는 mingw64를 쓰거나, wsl2 환경에서 진행하면 된다.

# 로컬 환경에 디렉토리 만들기

먼저 C드라이브나, 접근하기 쉬운 위치에 gitlab runner 디렉토리를 만들어준다.

mkdir gitlab-runner
cd gitlab-runner

이제 여기가 gitlab-runner 서비스가 위치할 곳이다.

vscode나 다른 에디터로 해당 디렉토리에서 docker-compose.yml을 만들어준다. 내용은 아래와 같이 하면 된다.

version: "3"

services:
  gitlab-runner:
    container_name: gitlab-runner
    image: 'gitlab/gitlab-runner:latest'
    restart: always
    volumes:
    - './config:/etc/gitlab-runner'
    - '/var/run/docker.sock:/var/run/docker.sock'

최신버전의 gitlab-runner가 설치되는 compose 파일을 만든다. 위에서 부터 쭉 보자.

Docker Compose 버전을 3으로 지정하고, gitlab-runner라는 이름의 컨테이너를 만들어서 서비스로 등록한다. 컨테이너에 사용될 이미지는 gitlab-runner 최신버전이고, 컨테이너가 중지될때(PC 종료와 같은 경우) 재시작 옵션을 걸고 컨테이너의 볼륨마운트 까지 정의해줬다. 볼륨마운트 의미는 아래와 같다.
`./config:/etc/gitlab-runner`: 현재 디렉토리의 config 폴더를 컨테이너의 /etc/gitlab-runner에 마운트한다.
`/var/run/docker.sock:/var/run/docker.sock`: 호스트의 Docker 소켓을 컨테이너 내부로 마운트한다. 이러면 gitlab runnner가 호스트 docker-daemon을 써서 docker in docker 환경이 구성되는데, 이러면 컨테이너 내부에서 호스트의 도커 엔진을 사용할 수 있고 호스트의 이미지 캐시를 사용하게 되므로 좀 더 효율적인 구성이 가능해진다.

컴포즈 파일을 실행시켜서 컨테이너를 만들면 된다.

docker compose up -d

Gitlab-Runner 등록하기

gitlab 프로젝트로 가서, runner를 만들어줘야한다.

CI/CD세팅으로 가서 runner를 만들어준다.

tag를 지정해주고, unstaged jobs도 체크해서 태그가 지정안된 ci 작업도 돌아가게 만들었다.

그러면 gitlab-runner 등록 코드가 나오는데, 이걸 도커로 만든 컨테이너에 지정해줄 것이다.

docker-compose exec gitlab-runner bash

docker-compose exec는 이미 실행 중인 gitlab-runnner 컨테이너 내부에서 새 명령을 실행하라는 의미이다. bash 셸을 열겠다는 의미로 여기서 저 gitlab-runner register를 등록해야 도커에 올라간 컨테이너가 깃랩 컨테이너의 역할을 수행할 수 있게된다.

# gitlab-runner 컨테이너 안의 shell이다.
gitlab-runner register  --url gitlab 서버 주소  --token 아까 있던 토큰 값

아까 명령어를 복사해서 그대로 붙여 실행하면 된다. 그러면 뭐라뭐라 나오는데, executer 를 `docker`, docker image를 `alpine:latest` 로 설정하는 이외에는 다 enter  쳐서 기본값으로 넣어도 된다.

Android CI 파일 작성하기

처음에는 구독중인 클로드를 사용했는데, 영 동문서답만 나와서 그냥 gitlab 공식 예제를 사용했다.

https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Android.latest.gitlab-ci.yml

이거 기반으로 작성했고, 최신 sdk인 34에 맞췄다.

먼저 프로젝트에 등록된 `local.properties`값들을 Gitlab에도 세팅해줘야한다.

CI/CD 탭의 Variables에서 작성하면된다. 다만 나의 경우처럼 Mask를 활성화 할 경우, value에 큰 따옴표를 넣을 수 없기 때문에 이따가 yml파일 작성할 때 이스케이프 처리를 해줘야한다.

파이프라인 설정은 각자 목적에 맞게 해주면 된다. 나는 그냥 root 디렉토리에 위치시켰다.

이제 `.gitlab-ci.yml` 파일을 작성하자. 파이프라인 에디터에서 바로 해도 되고, 로컬PC에서 작성해서 올려도 된다.

image: eclipse-temurin:17-jdk-jammy

variables:
  ANDROID_COMPILE_SDK: "34"
  ANDROID_BUILD_TOOLS: "34.0.0"
  ANDROID_SDK_TOOLS: "9477386"

SDK34를 사용하고, gradle 버전이 8.7이라서 jdk버전도 11이 아닌 17로 올려서 사용한다.

script를 작성하기 전에 프로젝트 repository를 보면, Android 폴더가 따로 존재한다. 즉 build를 저 폴더로 들어가서 진행해야한다는 의미가 된다. 그래서 before_script에 `cd Drtaa-Android`가 존재한다.

before_script:
  - cd Drtaa-Android
  - apt-get --quiet update --yes
  - apt-get --quiet install --yes wget unzip
  - export ANDROID_HOME="${PWD}/android-sdk-root"
  - install -d $ANDROID_HOME
  - wget --no-verbose --output-document=$ANDROID_HOME/cmdline-tools.zip https://dl.google.com/android/repository/commandlinetools-linux-${ANDROID_SDK_TOOLS}_latest.zip
  - unzip -q -d "$ANDROID_HOME/cmdline-tools" "$ANDROID_HOME/cmdline-tools.zip"
  - mv -T "$ANDROID_HOME/cmdline-tools/cmdline-tools" "$ANDROID_HOME/cmdline-tools/tools"
  - export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/cmdline-tools/tools/bin
  - sdkmanager --version
  - yes | sdkmanager --licenses > /dev/null || true
  - sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}"
  - sdkmanager "platform-tools"
  - sdkmanager "build-tools;${ANDROID_BUILD_TOOLS}"
  - chmod +x ./gradlew

나머지는 예시에 적힌 내용과 동일하다. 이제 문제는 variable에 적어둔 변수들을 가져와서 넣어줘야 한다는 점이다. 안그러면 BuildConfig로 설정해둔 값이 다 오류난다.

이번 프로젝트에서는 keystore를 사용하지않고 local.properties에서 키들을 관리하고 있기 때문에 local.properties 파일을 만들어서 거기에 값을 써주는 방식을 채택했다.

  - echo "sdk.dir=$ANDROID_SDK_ROOT" > local.properties
  - echo "NAVER_MAP_CLIENT_ID=\"$NAVER_MAP_CLIENT_ID\"" >> local.properties
  - echo "NAVER_MAP_CLIENT_ID_MANIFEST=$NAVER_MAP_CLIENT_ID_MANIFEST" >> local.properties
  - echo "NAVER_MAP_CLIENT_SECRET=\"$NAVER_MAP_CLIENT_SECRET\"" >> local.properties
  - echo "NAVER_CLIENT_ID=\"$NAVER_CLIENT_ID\"" >> local.properties
  - echo "NAVER_CLIENT_SECRET=\"$NAVER_CLIENT_SECRET\"" >> local.properties
  - echo "GOOGLE_LOGIN_CLIENT_ID=\"$GOOGLE_LOGIN_CLIENT_ID\"" >> local.properties
  - echo "TOUR_API_KEY=\"$TOUR_API_KEY\"" >> local.properties
  - echo "BASE_URL=\"$BASE_URL\"" >> local.properties
  - echo "MQTT_URL=\"$MQTT_URL\"" >> local.properties
  - echo "BOOTPAY_APP_ID=\"$BOOTPAY_APP_ID\"" >> local.properties

이스케이프 처리해둔 값들은 kotlin 코드에서 사용되는 값들이다. 내 코드의 경우 buildConfig에 사용되는 값들이 `" " `로 감싸져있지않으면 gradle에서 읽어올 때 에러가 난다. 아까 variable을 넣어줄때 mask를 활성화 해둬서 큰 따옴표를 못쓰기 때문이 이렇게 처리해줬다.

이 과정을 거치면 build할 때도 `local.properties`를 생성한 효과가 나타난다.

이제 job을 설정하면 된다. 내가 할 작업이 assembleDebug라서, 이름도 똑같이 넣어줬다.

assembleDebug:
  interruptible: true
  stage: build
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - Drtaa-Android/app/build/outputs/apk/debug/app-debug.apk
      - Drtaa-Android/app/build/outputs/logs/
    expire_in: 1 week

interruptible를 true로 켜서 새로운 커밋이 들어오면 현재 실행 중인 job을 중단하고 새 job을 시작하도록한다. 
stage: build: 이 job이 'build' 단계에서 실행됨을 나타냅니다. CI/CD 파이프라인의 여러 단계 중 하나입니다.
script에는 before_script를 기반으로 실행될 명령어를 정의하는 곳이다. 지금은 assembleDebug만 있지만, detekt같은 걸 시도할 수도 있다.

artifacts에는 이 job이 완료된 후 보존할 파일들을 정의해주는데, 저 paths 에 적힌 경로에 들어가서 파일을 긁어온다. 나는 안드로이드 프로젝트 안에 들어가야 되므로 `Drtaa-Android/`를 넣어서 경로를 확실하게 지정해야한다. 프로젝트 전체 artifacts 용량이 1GB라서 보존기간을 일주일로 명시해뒀다.

이렇게 하면 기존 목적이었던 아티팩트를 뽑는 과정이 완성된다. 문제는 다른 폴더에서 작업하여 develop이 업데이트 될 때도 이 pipeline이 돌아간다는 점이다. github actions에서는 workflow를 설정해서 이걸 막을 수 있었는데, 여기서는 only 옵션으로 돌릴 수 있다. gitlab에도 workflow가 있어서 stage별 제어조건을 걸 수 있는데 이건 나중에 확인하자.

https://docs.gitlab.com/ee/ci/yaml/#workflow

.android_changes: &android_changes
  only:
    changes:
      - Drtaa-Android/**/*

assembleDebug:
  <<: *android_changes
  interruptible: true
  stage: build
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - Drtaa-Android/app/build/outputs/apk/debug/app-debug.apk
      - Drtaa-Android/app/build/outputs/logs/
    expire_in: 1 week

앵커를 작성해주고, 안드로이드 폴더에서 변화가 있을 때만 assembleDebug Job을 돌아가게 했다. 이러면 다른 폴더에서 작업한 건 assembleDebug Job을 실행시키지않는다!

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

class NaverRepositoryImpl @Inject constructor(
    private val naverDataSource: NaverDataSource
) : NaverRepository {
    override suspend fun getSearchList(keyword: String): Flow<Result<List<Search>>> = flow {
        when (
            val response = safeApiCall { naverDataSource.getSearchList(keyword) }
        ) {
            is ResultWrapper.Success -> {
                emit(
                    Result.success(response.data.items.map { it.toSearch() })
                )
                Timber.d("성공")
            }

            is ResultWrapper.GenericError -> {
                emit(Result.failure(Exception(response.message)))
                Timber.d("실패")
            }

            is ResultWrapper.NetworkError -> {
                emit(Result.failure(Exception("네트워크 에러")))
                Timber.d("네트워크 에러")
            }
        }
    }
}

계속 미뤄왔던 테스트 코드를 학습해보자.

여러 모듈을 거쳐 테스트 하는 게 아니라 이번에는 `:core-data` 모듈에서만 단위 테스트를 진행할 것이다.

테스트에 사용될 Repository 구현체는 아래와 같다. Naver의 검색 API를 호출하는 Repository이며, safe api call을 도입해 성공, 보통에러, 네트워크 에러 3가지 분기로 나누었다.

이제 사용될 라이브러리를 보자.

//Test
testImplementation(libs.mockk)
testImplementation(libs.kotlinx.coroutines.test)
testImplementation(libs.junit)

[versions]
# Test
junit = "4.13.2"
mockk = "1.13.3"
kotlinxCoroutinesTest = "1.7.1"

네트워크 호출 없이 바로 로직을 검증할 것이기 때문에 mocking을 위한 mockk라이브러리를 추가해준다. flow를 쓰고있어서 코루틴 환경에서 test를 작성해야 하기 때문에 코루틴 테스트도 추가해준다. junit은 기본으로 dependency에 들어가있다.

Mockito가 더 유명하지만 코틀린 환경이고, mockk이 코루틴을 더 잘 지원해준다고 해서 mocking 라이브러리로 mockk을 선택했다.

아직 테스트 코드로 들어가지 않았지만 Mockito와 Mockk을 비교하면 아래와 같다. 우선 두 코드 모두 `naverDataSource.getSearchList(keyword)가 호출되면 mockResponse를 반환하라` 라는 의미다.

// Mockito
`when`(naverDataSource.getSearchList(keyword)).thenReturn(mockResponse)
val result = naverRepository.getSearchList(keyword).toList()

// Mockk
coEvery { naverDataSource.getSearchList(keyword) } returns mockResponse
val result = naverRepository.getSearchList(keyword).toList()

모키토에서 백틱으로 감싸진 when은 놀랍게도 메서드다. 거기에 대응되는 mockk의 함수가 coEvery다. co는 coroutine의 co이며, suspend 메서드를 호출할 때 사용된다. 비교 글은 많으니까 일단 넘어가겠다.

https://medium.com/@htj889/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-unit-test-mockito-kotlin-vs-mockk-%EB%8B%B9%EC%8B%A0%EC%97%90%EA%B2%8C-%EB%A7%9E%EB%8A%94-mocking-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%EB%8A%94-%EF%B8%8F-a1e79bd7ce9a

일단 Test 클래스를 만든다.

private lateinit var naverDataSource: NaverDataSource
private lateinit var naverRepository: NaverRepositoryImpl

@Before
fun setup() {
    naverDataSource = mockk()
    naverRepository = NaverRepositoryImpl(naverDataSource)
}

준비과정이다. repository에 들어갈 데이터 소스가 필요하니 이걸 mockk을 사용해 Mock 객체로 만들어주고, naverRepository 인스턴스를 Mock객체를 사용해서 만들어준다. `@Before` 어노테이션은 각 테스트 메소드 실행 전에 이 메소드를 실행하도록 지정한다. 

ResultWrapper로 3개로 나눠둬서 테스트 코드도 세개로 만드려고 한다. 성공, 일반에러, 네트워크에러로 만들겠다. getSearchList자체가 suspend 메서드이기 때문에 runBlocking으로 선언해줬다. 원래 runBlockingTest였던걸로 기억하는데 deprecated됐다. 정확히는 Mockito의 경우에는 코루틴을 지원하지않아서 runBlockingTest를 사용해야 했고, Mockk은 코루틴 지원이라 runBlocking으로 써도 된다!

테스트 코드를 작성하기 전에, `Given - When - Then` 구조를 알아야한다. Behavior-Driven Development (BDD) 방법론에서 주로 사용되는 방식으로 이렇게 테스트 코드를 구조화해서 작성한다.

https://www.devkuma.com/docs/testing/bdd/

• Given (주어진 상황): 테스트를 전제 조건을 설정하고, 테스트에 필요한 객체, 데이터들을 생성하거나 초기화한다.
• When (실행할 때): 테스트하려는 실제 메서드나 로직을 수행한다.
• Then (결과): 예상결과와 실제 결과를 assert로 비교해서 검증한다.

Given과 When 먼저 보자.

@Test
fun `getSearchList success html tag remove`() = runBlocking {
    // Given
    val keyword = "test" // 함수 호출에 사용되는 키워드
    val mockResponse = ResponseSearch(
        display = 0,
        lastBuildDate = LocalDate.now().toString(),
        start = 0,
        total = 10,
        items = listOf(
            SearchItem(
                title = "<b>제목이요</b>",
                link = "https://test.com",
                category = "Test Category",
                description = "Test Description",
                telephone = "123-456-7890",
                address = "Test Address",
                roadAddress = "Test Road Address",
                mapx = "123",
                mapy = "456"
            )
        )
    )
    coEvery { naverDataSource.getSearchList(keyword) } returns mockResponse

    // When
    val result = naverRepository.getSearchList(keyword).toList()
}

when을 쓰기전에 이미 이때 사용될 메서드 호출과 반환결과를 coEvery로 정의해둔다. 이러면 함수 호출 시 coEvery로 정의해둔 행동이 실행된다. 지금은 그냥 예상 결과를 return 해놨는데, throw Exception으로 예외 케이스도 만들 수 있다.

val result = naverRepository.getSearchList(keyword).toList()

여기서 toList는 flow의 toList다. flow의 결과를 리스트로 반환해줘서 first로 접근하기 좋다.

public suspend fun <T> Flow<T>.toList(destination: MutableList<T> = ArrayList()): List<T> = toCollection(destination)

이제 함수호출도 했고, 미리 반환값도 정해뒀으니 assert로 비교할 일만 남았다.

// Then
assertTrue(result.size == 1)
assertTrue(result[0].isSuccess)
val searchList = result.first().getOrNull()
assertEquals(1, searchList?.size)
assertEquals("제목이요", searchList?.first()?.title)

• 1. 내가 리스트에 한 개의 객체만 넣었으니 result크기는 1이어야 할 것이다.
• 2. kotlin.Result로 감싸뒀으니 첫번째 응답이 isSuccess인지도 검사한다.
• 3. isSuccess가 true면 다음 줄에서 data를 뽑아준다.

이게 중요한데 Result로 감싼경우에 getOrNull을 쓰면 아래 로직으로 동작한다.

 fold(onSuccess = { it }, onFailure = { null })

그래서 searchList에는 크기 1짜리 List<SearchItem> 이 들어가게 된다. 리스트 크기 검증도 해주고, 원하는 결과와 맞는 지 비교도 해준다.

그럼 이게 pass가 안될때는 어떤 경우일까?

is ResultWrapper.Success -> {
    emit(
        Result.success(response.data.items.map { it.toSearch() })
    )
    Timber.d("성공")
}

mapper인 `toSearch` 에서는 다음과 같이 처리를 하고 있다.

fun SearchItem.toSearch(): Search {
    return Search(
        title = this.title.removeHtmlTags(),
        category = this.category.removeTextBeforeArrow(),
        roadAddress = this.roadAddress,
        lng = this.mapx.toDouble() / 10000000,
        lat = this.mapy.toDouble() / 10000000
    )
}

title에서 html 태그를 지워주는 작업을 해주는데, 이걸 빼고 돌려보자.

Tests failed를 보여준다.

에러 테스트 코드는 거의 똑같으니 네트워크 에러만 그냥 코드를 두고 가겠다.

@Test
fun `getSearchList network error`() = runBlocking {
    // Given
    val keyword = "test"
    coEvery { naverDataSource.getSearchList(keyword) } throws Exception("네트워크 에러")

    // When
    val result = naverRepository.getSearchList(keyword).toList()

    // Then
    assertTrue(result.size == 1)
    assertTrue(result[0].isFailure)
    assertEquals("네트워크 에러", result[0].exceptionOrNull()?.message)
}

coEvery를 사용해서 함수호출행위에 대해 Exception 던지는 행위로 정의해줬다.

# 구현체를 직접 사용하는 게 거슬린다...

Hilt를 사용하여 Test용 Module을 만들고, 그걸 주입받아서 사용하겠다. hilt-android-test와 robolectric이 필요하다. hilt가 android 환경을 기대하기 때문에 Robolectric을 사용해줘야한다. 사실 그냥 AndroidJunit으로 해도 되는데, 나중에 에뮬레이터가 필요한 테스트도 가능한 라이브러리이기 때문에 Roblectric을 선택했다.

먼저 테스트를 위한 모듈을 만들어 줄 것이다. 중복 바인딩을 막기위해 꼭 해줘야한다.

@Module
@TestInstallIn(
    components = [SingletonComponent::class],
    replaces = [DataSourceModule::class]
)
object TestDataSourceModule {
    @Provides
    @Singleton
    fun provideNaverDataSource(): NaverDataSource = mockk()
}

@Module
@TestInstallIn(
    components = [SingletonComponent::class],
    replaces = [RepositoryModule::class]
)
object TestRepositoryModule {
    @Provides
    @Singleton
    fun provideNaverRepository(dataSource: NaverDataSource): NaverRepository =
        NaverRepositoryImpl(dataSource)
}

이 모듈들은 test 패키지 밑에 존재한다. 여기 위치시키지않으면 @TestInstallIn을 import하지 못하는 현상을 볼 수 있을 것이다.

기존에 사용하던 모듈 대신 테스트 환경에서는 지금 정의한 모듈을 사용하라는 의미를 나타낸다.

그리고 다시 NaverRepositoryImplTest로 돌아가 아래 코드들을 추가해주면 끝난다.

@HiltAndroidTest
@Config(application = HiltTestApplication::class)
@RunWith(RobolectricTestRunner::class)
class NaverRepositoryImplTest {

    @get:Rule
    var hiltRule = HiltAndroidRule(this)

    @Inject
    lateinit var naverRepository: NaverRepository
    @Inject
    lateinit var naverDataSource: NaverDataSource

    @Before
    fun setup() {
        hiltRule.inject()
        clearAllMocks()
    }
    
    // ... 동일
}

TestRunner로 기본이 AndroidJunit인데, HiltAndroidTest를 사용했더니 아래와 같은 메시지가 나온다.

No instrumentation registered! Must run under a registering instrumentation.

기본 러너를 못잡아서 이렇게 된 것이다. @RunWith으로 러너를 지정해주면 해결된다.

@RunWith(RobolectricTestRunner::class)

@Inject를 사용하는 건 익숙하고, Rule부분을 보겠다.

@get:Rule
var hiltRule = HiltAndroidRule(this)

테스트 실행 전에 Hilt의 컴포넌트를 설정하고, 테스트에 필요한 의존성을 주입해준다. 이대로 쓰면 안되고 @Before에서 inject()를 해줘야 필드 주입이 실행된다.

`clearAllMocks`는 특별할 게 없다. 여러 테스트를 복합적으로 돌릴 경우 이미 생성된 Mock 객체를 가져다 쓸 수도 있으니까 초기화 해주는 단계다.

직접 구현체를 안쓰고 주입받아 쓰니 훨씬 편안하다... 그 대신 hilt없이 테스트를 돌렸을 때 보다 살짝 느려진 걸 볼 수 있다.

# 왜 테스트를 도입할까?

사실 나도 이번이 학습하게 처음이라 아직 테스트 코드의 중요성을 완전히 이해하지는 못했다. 그리고 repository 구현체 자체도 단순 api call에 가까워서 mocking 하는 의미가 없다고 생각한다. 실제 네트워크를 타고 들어오는 건 다를 수 있는데, 지금 작성한 테스트 코드는 커버리지가 너무 좁다. 추후 실제 네트워크에서 호출하는 코드도 작성해야겠다. 그렇게 하려면 분리된 network 모듈에 접근해야하기 때문에 새로운 도전이 될 것 같다.

usecase의 성격을 띄는 곳에 테스트 코드를 작성하면 비즈니스 로직을 리팩토링할 때 테스트 코드를 활용할 수 있다고 하는데, 이건 나중에 또 도전해봐야겠다.

TDD가 효율적인지도 아직은 의문이다. 이번 포스팅의 경우에는 이미 만들어진 코드를 테스트 하는 것이기 때문에 뻔한 코드가 나왔지만, 테스트 코드를 먼저 작성한다고 가정했을 때는 repository 구현체를 만들고 나서 이렇게 테스트 해볼 수 있겠다라는 생각은 든다.

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!