Blitz.dev

정적 분석으로 iOS 앱 구조 파악하기

heoblitz — Sat, 3 Dec 2022 05:43:21 +0900

Photo by Robin Glauser on Unsplash

[ 본 포스팅은 언패킹(리버스 엔지니어링)에 대한 내용으로 관련 법률에 유의하시기 바랍니다. ]

iPA

iOS App-Store Package 의 줄임말으로 iOS 및 ipad 어플리케이션 아카이브 파일입니다. 모든 앱은 IPA 형태로 앱스토어에 배포가 됩니다. 개발한 코드와 함께 번들, 사이닝, 리소스 파일등이 모두 포함됩니다.

https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

iPA 다운 받기

앱스토어에 올라가 있는 앱의 iPA 를 얻기 위해 ipatool 을 사용해보겠습니다. ( 다른 방법으로 3utools, Xcode 아카이브, 탈옥된 iOS 기기를 통해 얻을 수 있습니다. )

// ipatool 설치
brew tap majd/repo
brew install ipatool

// ipatool 로그인
ipatool auth login --email test@apple.com --password testPassword

// 앱스토어에서 키워드로 검색
ipatool search kickstarter

// 번들 ID 로 IPA 다운 받기
ipatool download -b com.kickstarter.kickstarter

정적 분석

Apache License 2.0 로 공개되어 있는 kickstarter-iOS 앱을 분석해보겠습니다. 다운 받은 ipa 확장자를 zip 으로 변경하고 압축을 풉니다.

com.kickstarter -> Payload 폴더에 들어간 후, Kickstarter.app 에서 패키지 내용 보기를 누릅니다.

iPA 구조

1. ( root ) /

메인 번들 폴더입니다. 실행 파일과 함께 앱 아이콘과 컴파일된 스토리 보드 파일이 있습니다. 또한 별도로 분리해서 사용하는 번들 파일들도 볼 수 있습니다.

2. _CodeSignature

코드 서명과 관련된 폴더입니다.

3. Frameworks

Embed 되는 Dynamic Framework 가 모여있는 폴더입니다.

( * Static Framework 의 경우 Linking 되어 실행 파일에 포함됩니다. )

Frameworks 폴더에서 보이는 KsApi 는 Dynamic Framework 임을 확인할 수 있습니다.

Mach-O

https://github.com/aidansteele/osx-abi-macho-file-format-reference/blob/master/Mach-O_File_Format.pdf

iPA > Payload 폴더에 있는 앱 실행파일

Mach Object file format 의 줄임말으로서 Mach 커널을 사용하는 OS 의 실행 파일, 오브젝트 파일, 공유 라이브러리에 사용되는 파일 포맷입니다.

내부 구조는 크게 Header, Load commands, Data 로 구분되어 있습니다. 각 섹션에 어떤 정보가 있는지 파악해보겠습니다.

Mach-O Header

file 은 해당 바이너리가 어떤 정보를 가지고 있는지를 보여주는 명령어입니다.

file Kickstarter

arm64 아키텍처를 지원하는 실행파일임을 확인할 수 있습니다.

Load commands

otool 은 오브젝트 파일과 라이브러리를 분석할 수 있는 툴입니다. 아래와 같은 명령어를 통해 앱에서 어떤 정적/동적 라이브러리를 사용했는지 유추할 수 있습니다.

otool -L Kickstarter

( @rpath 가 없더라도 dynamic 프레임워크일 수 있습니다. 시스템 프레임워크의 경우에는 절대 경로를 사용합니다. )

Data

컴파일된 바이너리의 로직을 분석하기 위해 Disassembler 툴을 사용할 수 있습니다. ( Hopper, IDA Pro, Ghidra.. )

위와 같은 분석을 방지하기 위해 LINE 에서는 ORK 라는 난독화 컴파일러를 만들어서 사용하고 있습니다.

https://engineering.linecorp.com/ko/blog/code-obfuscation-compiler-tool-ork-1/

Disassembler 툴을 사용하면 코드가 공개되지 않은 바이너리 파일의 동작을 분석할 수 있습니다.

( UIKit 버그 파악하기 관련 게시글 )

https://pspdfkit.com/blog/2021/reverse-engineering-uikit/

https://medium.com/bumble-tech/using-hopper-to-investigate-an-ios-bug-66d373e6336d

참고:

https://ss64.com/osx/lipo.html

https://minsone.github.io/ios/mac/ios-framework-part-1-static-framework-dynamic-framework

레츠스위프트 2022, iOS 개발에서 알아두면 좋은 것들

코딩테스트를 위한 Swift 필수 자료구조 구현하기

heoblitz — Tue, 11 Jan 2022 11:31:02 +0900

Photo by ThisisEngineering on Unsplash

코딩테스트는 취업에 있어 꼭 필요한 과정 중 하나입니다. 저도 익숙하게 사용했던 Python 언어를 활용하여 코딩 테스트를 준비했었는데요. 하지만 최근에 점차 많은 회사들이 포지션에 맞게 코딩테스트 언어 제한을 두었습니다.

2021 네이버웹툰 개발 챌린지 ( iOS 포지션은 Swift를 사용해야 한다 )

Swift는 Type-Safe 언어이고 문법도 간결해서 iOS 개발할 때에 무척 편리하게 사용하고 있습니다. 하지만 Python과 달리 별도의 Built-in 자료 구조가 없어서 코딩테스트에 필요한 부분은 직접 구현해야 합니다.

이번 게시글에서는 Swift를 통해 필요한 자료구조를 직접 구현하는 방법에 대해 기술하고자 합니다.

Queue

Queue 는 FIFO 방식으로 동작하는 자료구조입니다. 프린터, 작업 대기열 같은 문제에 활용되고 더 나아가 SPFA 같은 최단 거리 알고리즘에 사용합니다.

Double Array를 활용한 Queue

Swift Reversed 메서드의 시간 복잡도는 O(1) 이기 때문에 Double Array를 사용하면 쉽게 Queue를 구현할 수 있습니다. 일반적인 상황에서 주로 사용합니다.

Cursor를 활용한 Queue

Double Array를 활용한 Queue는 극단적인 테스트 케이스에서 시간초과가 발생하게 됩니다. ( 상당히 많은 1회 추가, 삭제를 반복하는 경우 Array 를 계속 재할당하는 오버헤드가 발생함 )

이런 경우에는 Cursor를 활용해서 Queue를 구현할 수 있습니다.

Heap ( Priority Queue )

힙(우선순위 큐)는 완전 이진트리를 기반으로 최소(혹은 최대) 값을 O(logN)으로 구할 수 있는 자료구조입니다. 최소, 최대 값을 지속적으로 추적해야 하는 문제나 최단거리를 구하는 다익스트라 알고리즘에 사용합니다.

구현 편의를 위해 트리가 아닌 배열을 사용하고 첫번째 index 는 사용하지 않습니다.

Heap 구현이 꼭 필요하지 않은 경우

Heap에 대한 원리는 파악하고 있어야 하지만 실제 코딩테스트 환경에서 구현하는데 큰 부담이 있습니다.

1. 최대, 최소 값을 계속 추척해야하는 문제

-> 테스트 케이스 범위와 실행 시간이 여유롭다면 min, max 메서드로 코드를 작성해봅니다. 시간 복잡도에 큰 손해가 있지만 우선 동작에 초점을 맞춥니다.

-> 시간 초과가 발생하거나 시험 여유 시간이 남는다면 다시 Heap으로 리팩토링합니다.

2. 최단거리를 구하는 문제

-> 다익스트라 알고리즘 대신 SPFA 알고리즘을 사용합니다. SPFA는 Queue를 사용하기 때문에 구현에 큰 어려움이 없고 일반적인 상황에서 O(V+E)으로 동작합니다.

-> 다만 테스트 케이스가 까다롭다면 O(V*E)으로 동작하기 때문에 Heap을 사용하는 다익스트라 알고리즘으로 구현해야 합니다.

* leetcode를 통해 동작을 확인했지만 틀린부분이 있을 수 있습니다. 잘못된 부분은 말씀해주시면 감사하겠습니다.

8개월간 같은 iOS 앱을 리팩토링하며 배운점

heoblitz — Sat, 20 Nov 2021 12:20:54 +0900

https://github.com/ModuTeam/LinkMoa_iOS

"링크모아" 는 사용자의 북마크를 쉽게 관리하고 공유할 수 있는 앱 서비스입니다. 20년 12월 기획을 시작으로 디자이너 1명, 백엔드 개발자 2명, iOS 개발자 2명이 협업하며 21년 3월에 개발을 완료했습니다.

iOS 개발자와 처음으로 협업을 하며 이론적으로만 알고있던 git-flow 를 적용하고 merge 시에는 코드 리뷰를 꼭 거치도록 했습니다.

잠깐이지만 앱 스토어 생산성 부문에서 160위 내에 들었고 동아리 데모데이 대상을 받는 등, 저에게 있어 무척 뜻 깊은 프로젝트입니다.

데모데이 이후에 프로젝트가 마무리될거라고 생각했지만 같이 협업을 했던 iOS 개발자분이 한 가지 제안을 주셨습니다.

"현업에서 사용하는 기술들을 적용해보고 지속적으로 같이 리팩토링 해봐요."

매번 기능 개발만 진행하고 프로젝트가 종료되어서 유지보수와 좋은 코드에 대한 아쉬움이 컸었는데요. 팀원분이 주신 제안에 깊히 공감하게 되어 개발 완료 이후에 리팩토링을 진행하게 되었습니다.

RxSwift 공부하고 적용하기

ReactiveX/RxSwift

RxSwift 는 마이크로소프트에서 만든 ReactiveX 를 Swift 로 구현한 프레임워크입니다.
비동기 코드를 "함수형과 선언형 프로그래밍" 통해 간단히 작성할 수 있습니다.

MVVM 코드 패턴과 같이 사용하면 데이터 바인딩을 간결하게 할 수 있다는 장점이 있습니다.
여러 MVVM 패턴의 장단점을 정리한 내용을 아래 포스팅으로 남겼습니다.

iOS MVVM 패턴 구현 정리: https://linux-studying.tistory.com/28

또한 복잡한 비동기 코드를 작업할 때 위와 같이 클로저가 중첩되며 가독성이 무척 떨어지는 문제점이 있었는데요. RxSwift 를 사용하면 flatMap 을 통해 여러 비동기 코드를 체이닝으로 연결하여 작업할 수 있습니다.

위처럼 RxSwift를 사용하여 비동기 클로저가 중첩하여 발생하는 코드 Depth 를 상당히 줄일 수 있습니다. 그 외에도 RxDataSource, RxGesture, RxMoya... 등등 여러 서포트 프레임워크를 통해 가독성 좋은 코드를 작성할 수 있었습니다.

Tuist 와 앱 모듈화

Tuist

Tuist 는 Xcode 프로젝트 파일을 Swift 로 관리할 수 있도록 도와주는 프레임워크입니다.
git binary merge 설정을 해도 발생하는 프로젝트 충돌을 해결하기 위해 도입했습니다.

https://engineering.linecorp.com/ko/blog/improving-build-performance-line-ios-bazel/

다만 Tuist 적용을 위해 예시 프로젝트를 살펴보니 상당히 많은 앱들이 모듈로 구성되어 있었습니다. 전에 Line 기술 블로그를 보며 "앱이 수백 개의 모듈로 구성되어 있다." 라는 의미를 정확하게 이해하지 못했는데요. Tuist 의 방향성에 맞게 링크모아에도 앱 모듈화가 필요하다는 판단을 하여 학습하게 되었습니다.

<참고한 자료 및 프로젝트>

민소네님, Let us go 2019 프레임워크 주도 개발: https://www.youtube.com/watch?v=YiEpuZQPuko
Soojin Ro님, BookStore-iOS: https://github.com/nsoojin/BookStore-iOS
라인 개발자가 말하는 대규모 iOS 앱 개발 썰: https://youtu.be/wZh8WXPAIeg?t=583
Kanghoon님, Xcode 프로젝트 관리를 위한 Tuist 알아보기: https://okanghoon.medium.com/xcode...

앱 모듈화의 장점은 다음과 같습니다.

1. 빌드 속도를 줄일 수 있습니다.

( * 클린 빌드는 예외, 코드가 변경된 모듈만 빌드하기 때문에 빌드 속도 개선이 가능합니다. )

2. 큰 프로젝트에서 많은 개발자와 협업을 진행할 수 있는 환경입니다.

( * 기능들을 모듈로 나누고 각각 Git 서브 모듈로 구성하면 한 앱을 여러개의 프로젝트로 작업할 수 있습니다. )

3. 각 기능별 의존성을 명확하게 지정할 수 있습니다.

( * 기본 키워드인 Internal 는 다른 모듈에서 접근이 불가하기 때문에 접근하려면 명시적으로 Open 또는 Public 을 사용해야 합니다. )

4. 기능 간 결합도를 낮추어서 유연한 서비스를 제작할 수 있습니다.

( * 모듈을 통해 쉽게 다른 프레임워크로 교체할 수 있고 또한 필요한 모듈은 새로운 프로젝트에 다시 재사용할 수 있습니다. )

LinkMoa Dependency Graph

<리팩토링 후 링크모아 구조>

LinkMoa: iOS 앱
LinkMoaShareExtension: Share Extension ( 공유하기 기능 )
LinkMoaWidget: 위젯
LinkMoaBottomSheet: Custom Bottom Sheet 프레임워크
LinkMoaCore: 네트워크 및 저장소 프레임워크
LinkMoaKit: Assets, Fonts 및 Helper Class 프레임워크

링크모아에서는 Tuist 를 통해 프로젝트 머지 충돌을 해결할 수 있었고 앱 모듈화를 통해 각 코드에 대한 의존성을 명확하게 구분할 수 있었습니다.

테스트 가능한 코드로 리팩토링하기

앱 구조 리팩토링 이후에 프로젝트 코드를 검증하기 위해 테스트 코드를 작성을 시작했습니다. 다만 테스트를 작성하면서 FIRST 원칙이 전혀 지켜지지 않고 있다는 생각이 들었습니다.

네트워크는 실제 서버 API에 호출하여 매우 느리고 반복하기에는 상당히 불안정했습니다. 또한 UserDefault는 실제 앱에서 사용하는 저장소에 테스트 코드가 접근할 수 있었고 이는 전혀 고립되지 않은 테스트 환경이였습니다.

따라서 먼저 Testable 한 코드를 파악하는 능력을 기르고 리팩토링을 진행하고자 하였습니다.

WWDC17 Engineering for Testability

WWDC 에서 학습한 테스트 가능한 코드의 특성은 다음과 같습니다.

1. 모든 입력 값들은 제어 가능해야 합니다.
2. 생성되는 출력을 검사할 수 있는 방법을 제공해야 합니다.
3. 코드의 동작의 영향을 미칠 수 있는 내부 상태에 의존하지 않습니다.

WWDC17 Engineering for Testability

위 코드는 싱글톤을 사용하므로 전역 시스템 상태에 의존하게 됩니다. 또한 open 을 통해 실제로 원하는 동작이 수행됐는지 유닛 테스트를 통해 확인하기 어렵습니다.

WWDC17 Engineering for Testability

이를 프로토콜과 매개변수화를 통해 testable 하게 코드를 리팩토링할 수 있습니다. 필요한 의존성을 모두 외부에서 주입하도록 합니다. 그리고 필요한 동작을 정의한 Protocol 을 가르키게 합니다.

위와 같이 변경하면 해당 Protocol 를 준수한 어떠한 객체도 주입이 가능하게 됩니다. 이때 Protocol 을 준수한 Mock 을 주입하면 행위와 상태 검증을 수행할 수 있습니다.

WWDC17 Engineering for Testability

링크모아에서도 내부에 의존성을 가지고 있는 경우는 의존성 주입을 통해 외부에서 전달받도록 변경했습니다. 또한 모의 객체가 필요한 부분은 Protocol 를 구성하여 테스트에 필요한 Mock 객체를 만들었습니다.

테스트 코드 작성하기

유닛 테스트 작성시에 유의했던 부분은 "개발자의 관점에 따라 테스트 입력 값이 변경될 수 있다." 였습니다.

sungdoo 님, [서평] 지식 제로부터 배우는 소프트웨어 테스트: https://www.sungdoo.dev/post/review/book/...

위와 같이 양의 정수만을 문자열로 변경하는 프로그램이 있을 때, 음수가 들어가는 경우에 대한 테스트가 꼭 필요합니다.

하지만 실제 프로젝트의 함수는 더 복잡하고 많은 일을 수행합니다. 따라서 테스트 코드 작성시에는 더 작은 기능들로 분리하여 함수의 역할을 명확하게 하거나 테스트시에 어떤 값이 들어갈 수 있는지 한번 더 고민하였습니다. 또한 테스트 코드 가독성을 위해 Given, When, Then 을 구분지어 사용하는 GWT 방식을 사용했습니다.

Int 값을 한글로 변경하는 메서드, 10개의 테스트 케이스로 검증

폴더를 추가하는 API 메서드, 명세서 Code 에 해당하는 모든 케이스를 검증

LinkMoa Kit, Core, BottomSheet

174 개의 테스트 메서드

heoblitz, iOS URLSession Test Double 만들기: https://linux-studying.tistory.com/31
heoblitz, iOS 뷰 컨트롤러 간단하게 테스트 코드 연습하기: https://linux-studying.tistory.com/33

그 결과 Kit, Core, BottomSheet 각 프레임워크에 대한 테스트 코드 작성을 하였고 평균 테스트 커버리지는 70%, 테스트 메서드 개수는 174개로 구성되었습니다.

중복되는 코드를 줄이고 재사용하기

Apple 에서는 Swift 를 프로토콜 지향 언어라 말합니다. POP 라 불리는 프로토콜 중심 프로그래밍을 통해 수평 확장이 가능하고 또한 OOP 를 통한 수직 확장을 통해 여러 중복 코드를 제거하고 재사용할 수 있습니다.

Protocol

Protocol 과 extension 을 조합하여 만들고 특정 객체에서 채택하면 cellIdentifier를 일일히 지정하지 않아도 됩니다.

위 예시도 BackgroundBlur 를 채택하면 필요한 메서드를 간단하게 확장하여 사용할 수 있습니다.

Inheritance

위 처럼 프로젝트에서 반복되어 사용되는 코드가 있다고 가정해보겠습니다. 이때 LinkMoaNavigationController 를 상속하여 사용하면 코드 중복을 상당히 줄일 수 있습니다.

혹은 UI 가 동일하지만 다른 동작이 필요할 때 상속(Inheritance) 과 재정의(Override) 를 통해 자식 객체에서 필요한 기능을 구현할 수 있습니다. 상속을 활용하면 AddLinkVC 내부에 분기처리를 제거할 수 있으므로 SOLID 의 개방-폐쇄 원칙을 준수할 수 있습니다.

더 나아가야 할 방향

UI 컴포넌트 재사용하기

웹 프론트엔드 분야에서 재사용 가능한 컴포넌트로 작업하는 것은 무척 중요합니다. 반복되는 UI를 컴포넌트화하고 이를 재사용하여 중복코드를 줄일 수 있습니다.

iOS 앱인 링크모아에서도 TableView 혹은 CollectionView 에서 사용하는 Cell 이나 Supplementary View 는 XIB 로 구현하여 다른 화면에서 재사용하고 있습니다.

하지만 동일한 Style 의 버튼이나 Label, 특정 View 들은 Storyboard 에서 각각 구현되어 있는 경우가 많습니다. 혹은 커스텀 클래스로 구현되어 있는 경우에도 @IBDesignable 어노테이션이 없어서 Storyboard 에서 바로 확인할 수 없습니다.

개발 당시에는 UI 구조화에 대한 이해도가 높은 편이 아니였고 기능 개발에만 집중했기 때문에 뷰 재사용이 미숙했다고 생각됩니다. 가능하면 리팩토링과 더불어 다음 프로젝트에서는 UI 컴포넌트 재사용에 대해서 고민해보고 작업을 할 계획입니다.

Storyboard 일 필요가 없다면 XIB 로 생성하기

링크모아는 Storyboard 가 많아 질수록 느려지는 문제를 해결하기 위해 Storyboard 하나당 한개의 Initial ViewController 가 할당되어 있습니다. 개발 당시에는 가장 좋은 방식이라고 생각했었습니다.

하지만 Storyboard 는 여러개의 뷰 컨트롤러의 전체적인 흐름을 파악하는데 장점이 있지만 링크모아와 같이 한개의 뷰 컨트롤러만 할당한다면 XIB 가 더 적합하다고 생각합니다.

그 이유는 Storyboard 는 파라미터가 필요한 ViewController를 초기화할 때 더 복잡한 방식을 거치기 때문입니다.

위처럼 스토리보드를 생성하고 다시 instantiateInitialViewController 를 통해 다시 ViewController를 생성해야 합니다. 따라서 UIKit 을 사용한 새로운 프로젝트를 진행할 때에는 XIB 로 제작해야겠다는 생각을 했습니다.

iOS Dependency Injection 개념 파악하기

heoblitz — Wed, 3 Nov 2021 11:10:16 +0900

Photo by Bozhin Karaivanov on Unsplash

의존성 주입이란?

iOS 테스트 코드를 공부하며 상당히 많이 접했던 단어입니다. "의존성 주입" 은 무엇일까요?
이론적인 개념은 다음과 같습니다.

```
소프트웨어 엔지니어링에서 의존성 주입(dependency injection)은 하나의 객체가 다른 객체의 의존성을 제공하는 테크닉이다. 클라이언트가 어떤 서비스를 사용할 것인지 지정하는 대신, 클라이언트에게 무슨 서비스를 사용할 것인지를 말해주는 것이다. "주입"은 의존성(서비스)을 사용하려는 객체(클라이언트)로 전달하는 것을 의미한다.
```
출처: https://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EC%84%B1_%EC%A3%BC%EC%9E%85

대부분의 프로그램은 객체들의 조합인 Composition 으로 이루어집니다. 의존성 주입은 객체가 서로 의존 관계에 있을 때 "직접 생성하는" 것이 아니라 "제공 받는" 형태를 말합니다. 이를 예시 코드로 살펴보겠습니다.

MVC 패턴에서 주로 ViewController에서 Network 관련 객체를 생성하고, 이를 토대로 로직을 구성하게 됩니다. 이를 Dependency Injection ( 의존성 주입 ) 으로 바꾸면 다음과 같습니다.

NetworkProtocol 를 구현하고 NetworkProvider 에서는 해당 프로토콜을 채택합니다.
ViewController 에서는 이니셜라이저를 통해 필요한 의존성을 주입 받게 됩니다.

ViewController 에서는 더 이상 NetworkProvider 가 아닌 NetworkProtocol 를 가르키게 됩니다.
따라서 NetworkProtocol 를 채택한 어떤 객체도 주입 가능하게 됩니다.

이러한 프로토콜을 통한 간접화는 의존성을 쉽게 치환할 수 있습니다.
또한 해당 프로토콜을 준수한 Mock 객체를 만들어서 주입하면 쉽게 테스트 환경을 만들 수 있습니다.

의존성 주입은 좋은 방식인가? 장점은 무엇일까

Uber 에서 만든 Needle 프레임워크는 예시와 함께 의존성 주입의 장점에 대해서 설명합니다.

사진을 검색하는 앱을 만든다고 가정해보겠습니다. PhotosViewController는 PhotosService를 통해 서버에서 사진을 가져와서 보여주게 됩니다. 
이때 PhotosService는 내부에서 생성하도록 구현되어 있습니다.

위와 같은 강한 커플링 구조는 다음과 같은 이슈를 만들 수 있습니다. 


1. PhotosService의 코드를 수정하려면 PhotosViewController 또한 코드를 수정해야 합니다. 
( 두개의 클래스에서는 괜찮아 보이지만 실제 수백개의 클래스가 있는 현업 앱에서는 앱 반복을 늦추게 됩니다. ) 
* 필자는 개발 주기로 이해했습니다. 

2. PhotosService를 교체하려면 PhotosViewController 또한 코드를 수정해야 합니다.
( 성능을 개선한 PhotosServiceV2 를 사용하려 할 때 PhotosViewController 코드를 일일히 파악하고 수정해야 합니다. ) 

3. PhotosService의 호출 없이 PhotosViewController 유닛 테스트가 불가합니다. 
( 내부에서 의존성을 생성하므로 테스트시에 주입이 불가합니다. ) 

4. PhotosViewController 와 PhotosService 를 동시에 개발할 수 없습니다. 
( 작은 규모의 앱에서는 큰 문제가 아닌 것 처럼 보일 수 있지만 실제 팀에서는 엔지니어가 끊임없이 막힐 수 있습니다. ) 

* 의역이 있을 수 있습니다. 자세한 내용은 링크를 참고해주시면 감사하겠습니다.

https://github.com/uber/needle/blob/master/WHY_DI.md

의존성 주입은 testable 한 코드와도 무척 연관이 깊습니다. 어떤 객체가 다른 객체와 연관이 있을 때
이를 여러가지 방법(이니셜라이저, 프로퍼티, 메서드)를 통해 외부에서 주입할 수 있는 방식을 말합니다.

의존성 주입은 위와 같이 협업에서 발생할 수 있는 이슈나 유닛 테스트시에 발생하는 문제를 해결합니다.

의존성 주입의 단점

의존성 주입을 했을 때에는 결합도(coupling) 가 적다고 표현할 수 있습니다.

https://ko.wikipedia.org/wiki/%EA%B2%B0%ED%95%A9%EB%8F%84

이때 낮은 결합도를 가진 구조는 구조화가 잘 되어있다고 표현할 수 있으며 좋은 설계로 표현될 수 있습니다. 이와 반대로 높은 결합도를 가진 구조는 높은 가독성과 유지보수성을 가진다고 할 수 있습니다.

따라서 의존성 주입 패턴은 생성자가 다른 코드에 위치하기 때문에 상대적으로 낮은 가독성을 가질 수 있다는 것이 단점입니다.

* 유지보수성의 경우에는 팀원이 많을 수록 늘어난다고 생각합니다.

의존성은 어디에서 주입되는가?

의존성 주입은 의존 관계에 있는 객체를 직접 생성하는 것이 아닌 제공받는것이라고 개념을 정리했습니다.
그러면 iOS 앱에서는 의존성을 어디에서 주입해야할까요? 크게 2가지 방식이 있습니다.

1. DI Container

의존성을 관리해주는 별도의 컨테이너를 사용하는 방식을 말합니다. 대표적으로 Swinject 라는 프레임워크가 있습니다.
DI Container는 등록하는 register 와 의존성을 풀어내는 resolve 를 지원합니다. iOS 에서는 앱 시작점 (AppDelegate)에서 필요한 의존성들을 register 하고 필요한 부분에서 resolve 하여 사용합니다.

주로 DI Container 는 싱글톤으로 구현되는 경우가 많기 때문에 어떤 지점에서도 접근이 가능합니다. 따라서 필요한 의존성을 DI Container 를 통해 직접 생성하거나 이전 뷰 컨트롤러에서 resolve 하여 주입하는 방식을 사용합니다.

2. Pure DI

https://freecontent.manning.com/dependency-injection-in-net-2nd-edition-understanding-the-composition-root/

DI Container 를 사용하지 않고 모든 의존성을 Compostion Root 에서 관리하는 방식을 말합니다. iOS 에서 Compostion Root 는 AppDelegate 에 해당됩니다.

Compostion Root 에서는 의존성 트리를 구성하고 Factory 형식으로 하위 객체에 필요한 의존성을 모두 제공하게 됩니다. 클로저로 이어지는 이니셜라이저 Depth 를 줄이기 위하여 Pure 라는 프레임워크를 사용할 수 있습니다.

정리

포스팅을 작성하며 의존성 주입은 iOS 뿐만 아니라 소프트웨어 공학에서 널리 사용되는 개념임을 알게 되었습니다. 따라서 개발자에 따라서 이해도나 관점이 다르기 때문에 더 많은 레퍼런스를 찾아보는 것이 좋겠다는 생각을 했습니다.

더 학습하며 잘못된 내용은 수정하고 추가할 내용은 덧붙여서 게시글을 계속 업데이트할 예정입니다.

참고 자료

IoC? DIP? IoC Container? DI? DI Framework? 도대체 그게 뭔데?

여러분이 자바 혹은 C#을 사용한다면 제목과 같은 용어들을 봐왔을겁니다. 하지만 보면 볼수록 매우 혼란스럽게 느껴질 것 입니다. 이렇게 복잡하게 느껴지는 이유는 이러한 용어들이 긴 시간에

velog.io

초보 개발자가 오픈소스에 기여하는 방법

heoblitz — Mon, 11 Oct 2021 14:11:24 +0900

Photo by Stephen Picilaidis on Unsplash

필자는 깃허브에 있는 오픈소스 프로젝트를 자주 들여다 봅니다.
뛰어난 개발자분들이 작성한 코드를 보고 새로운 언어 기능이나 구조를 보며 배우는 것이 무척 많습니다.

그러던 중 기여할 수 있는 부분이 생기면 여러번 고민해보고 PR 을 보내기도 합니다.
처음에는 확신이 없었고 민폐가 아닌가? 하는 생각이 들었지만
에러를 해결하고 나서 많은 분들이 좋은 피드백을 주셨던 경험이 있습니다.

그 후 개선할 부분을 발견하면 이슈를 꼼꼼히 확인하고 PR 을 올리는 습관을 가질 수 있었습니다.

Swift 첫 오픈 소스 기여 후기 ( Open Source PR )

오픈소스라 하면 거대한 프로젝트이고, 뛰어난 개발자분들이 기여하기 때문에, 입문 개발자가 쉽게 접근하기 어렵다고 생각했습니다. 하지만 베타 Xcode 에서 컴파일 에러를 해결하여, 입문 개발

linux-studying.tistory.com

이번 포스팅에서는 초보 개발자가 관심이 있는 프로젝트에 기여하고 싶을 때
어떻게 시작할 수 있는지에 대해서 다루어 보겠습니다.

* Github 를 기준으로 작성하였습니다. 필자도 많이 미숙하지만 관련된 내용을 정리하면 좋겠다는 생각에 포스팅을 작성하게 되었습니다.

pull request 는 "제가 작업한 코드를 확인하고 브랜치를 병합해주세요." 라는 일련의 과정을 말합니다.
권한이 있는 저장소에서 작업할 경우에는 직접 브랜치를 만들고 내부에서 pull request 가 가능합니다.

하지만 오픈 소스의 경우 main contributors 를 제외한 개발자들은 push 권한이 없기 때문에 다음과 같은 과정을 거쳐야 합니다.

< Pull Request 과정 요약 >

A: 해당 오픈소스 저장소
B: fork 한 저장소

`A 저장소를 fork` -> `B 에서 commit` -> `B 에서 push` -> `A 에게 pull request 요청`

< Github Pull Request 과정 >

1 - 해당 오픈소스 저장소를 fork 합니다.

2 - fork 한 저장소에서 작업하고 commit 을 push 합니다.
3 - New pull request 를 생성합니다.

4 - 해당 저장소와 브랜치를 설정하고 양식에 맞게 작성하면 됩니다.
( 각 프로젝트에 맞는 contributing guide 를 참고하는 것이 가장 좋습니다. )

2. 버그 및 수정사항 발견하기

< 오픈소스 사용중에 문제가 발생하는 경우 >

컴파일 도중에 에러가 발생하거나 혹은 오동작이 발생하는 버그를 발견했을 때
로그와 실행 환경을 파악하여 어떤 것이 문제인지 살펴봅니다.

* Github issue 를 확인하여 같은 문제가 발생한 유저가 있는지, 이에 대한 문제 해결이 진행되는지 확인해보면 더 좋습니다.

오픈소스 자체의 문제라고 생각되면 Issue 를 등록하거나 수정한 코드로 해결된다면 PR 을 요청해봅니다.

* Issue, pull request 에 대한 규칙이 각 오픈소스에 있는 경우가 많습니다. 꼭 확인 후 진행하는 것을 추천드립니다.

최신 버전 IDE 에서 발생한 컴파일 에러를 해결하고 PR

< Github Issue 확인하기 >

Github Issue 는 프로젝트에 대한 기능, 버그, 제안등의 여러가지 이슈를 등록할 수 있는 기능입니다.
해당 이슈에 대한 수정이나 개선이 가능하다면 pull request 에 다음과 같이 Issue 번호를 붙여서 작성할 수 있습니다.

프로젝트 방향성에 맞게 기능을 구현하고 PR

< README 에 있는 오타, 코드 컨벤션 수정하기 >

코드에 변수 명이나 주석 철자에 오타가 있거나 README 에 있는 문서가 잘못 링크가 되어있는 경우에도
간단하게 수정해서 PR 할 수 있습니다.

코드 컨벤션이 잘못된 경우

3. 마무리

오픈소스의 이슈를 해결하는 것은 무척이나 까다롭고 어려운 작업이라고 생각합니다.
특히 기능을 개선하거나 새롭게 만들 때에는 상황에 따라 테스트 코드 작업도 필요한 경우가 있습니다.

* 일정 규모 이상의 오픈소스는 CI/CD 환경이 구축되어 PR 과정에 테스트를 수행합니다.

다만 꼭 기여를 하지 않더라도 오픈소스를 통해 다양한 사람들의 코드를 살펴볼 수 있고 점차 코드를 이해하는 능력이 성장하는 것을 느낍니다. 이러한 과정은 본인만의 오픈소스 라이브러리를 만들 수 있는 토대가 될 수 있다고 생각합니다.

마지막으로 Github Issue 통한 프로그래밍 학습법을 소개하고 포스팅을 마치겠습니다. 읽어주셔서 감사합니다!

How To Rapidly Improve At Any Programming Language

Last year, I submitted a PR to the Clojure web request routing library, Compojure. Even though I was doing Clojure full time at work, there was still a lot for me to learn and always will be. Opening a PR for an open source library I was familiar with and

www.cbui.dev

Swift Reference Count 고찰 ( with side table )

heoblitz — Fri, 8 Oct 2021 18:32:39 +0900

Photo by Alexandre Lecocq on Unsplash

Swift ARC 의 기본적인 개념은 아래 포스팅을 참고해주시면 감사하겠습니다.

Swift ARC ( Automatic Reference Counting ) 정리

추상적으로 "메모리를 관리해주는 것" 으로 이해하고 있었지만, JAVA 의 GC ( 가비지 컬렉터 ) 와의 차이점을 명확하게 설명하게 어려워서 포스팅을 작성했습니다. 프로그래밍 언어의 메모리 관리

linux-studying.tistory.com

필자는 iOS 를 처음 공부하며 클로저 캡처리스트를 작성할 때 unowned 를 남발했던 기억이 있습니다.

그 후 앱 크래시를 유발할 수 있다는 조언을 듣고 강한 순환 참조가 발생할 수 있는 상황에서는 weak 키워드를 사용했습니다.

weak 와 unowned 를 사용하면 레퍼런스 카운트가 올라가지 않고 self 가 옵셔널이라는 차이가 있다는

단편적인 이해를 하고 넘어갔었지만, 이번 포스팅에서는 조금 더 자세하게 ARC 동작에 대해서 다루겠습니다.

Swift Reference Count

Swift "RefCount.h" 헤더 파일의 주석을 참고하면 레퍼런스 카운트는 다음과 같이 3개로 나누어 집니다.

Strong RC

- 오브젝트를 참조할 때 기본적으로 사용되는 방식입니다.

- Strong 카운터 가 0이 되면 오브젝트가 deinited 됩니다. ( 메모리에서 해제를 의미하지는 않습니다. )

- String 카운터가 0일 때 unowned 레퍼런스를 읽으면 error, weak 레퍼런스는 nil 이 됩니다.

Unowned RC

- 오브젝트를 미소유(unonwned) 로 참조할 때 해당됩니다.

- 참조될 때 Unowned RC 카운트가 올라가고 해당 카운트는 오브젝트가 deinited 될 때 카운트가 내려갑니다.

- Unowned 카운터 가 0이 되면 오브젝트가 메모리에서 해제(free) 됩니다.

Weak RC

- 오브젝트를 약하게(weak) 참조할 때 해당됩니다.

- 참조될 때 Weak RC 카운트가 올라가고 해당 카운트는 오브젝트가 해제(free) 될 때 카운트가 내려갑니다.

- Weak 카운터 가 0이 되면, 해당 오브젝트의 Side Table 또한 해제됩니다.

* 코드 주석에 맞게 오브젝트로 용어를 통일하였습니다.

정리하자면 다음 그림과 같이 오브젝트 해제가 이루어집니다.

https://www.vadimbulavin.com/

What is Side Table?

사이드 테이블은 Swift 4.0 버전부터 새롭게 도입된 기능입니다.

기존 방식은 Strong 과 Weak 두 가지의 참조 카운트를 가지고 있었습니다.

Strong 카운터가 0이 되면 deinit 되지만, 메모리에서 바로 free 되지는 않았습니다.

이처럼 메모리에 계속 남는 것을 좀비 오브젝트라고 불렀고, 그 후 weak 참조로 다시 접근하면

그제서야 메모리 해제가 이루어졌습니다.

이 방식은 매우 간단한 설계였지만 사용하지않는 오브젝트가 메모리에 계속 남는 것은 비효율적인 방식입니다. 따라서 Side Table 이라는 별도의 관리 개체를 만들게 되었습니다.

https://maximeremenko.com/swift-arc-weak-references

위 그림처럼 Strong 과 Unowned 는 오브젝트를 직접 가르키고, weak 는 side table 를 가르키게 됩니다.

해당 사이드 테이블은 다음과 같은 조건으로 생성됩니다.

1. Strong 혹은 Unowned 카운트가 오버플로우 될 때

2. Weak 참조를 사용할 때

이러한 side table 덕분에 Strong 카운트가 0가 되면 deinit 에서 메모리가 해제되는 과정을 거치게됩니다.

Weak vs Unowned?

Mike Ash 개발자에 따르면 side table 이 필요한 오브젝트는 추가 비용이 발생할 수 있다고 합니다.

* 구글링을 통해 weak unowned 키워드에 따른 유의미한 성능 차이는 찾지 못했습니다. 다만 별도의 오브젝트를 사용하므로

할당/해제에 발생하는 오버헤드가 있는 것은 분명한 사실입니다.

개발자가 오브젝트의 생명주기를 확실하게 파악한 상태이면 Unowned 키워드를 사용하고,

그 외의 경우라면 안전한 코딩을 위해 weak 키워드를 사용하는 것이 좋겠다는 생각이 들었습니다.

* unowned 키워드는 RxSwift, Alamofire 같은 유명한 라이브러리에서도 사용된

코드를 발견할 수 있었습니다. 상황에 따라 적절하게 사용가능할 것으로 보입니다.

참고:

mikeash.com: Friday Q&A 2017-09-22: Swift 4 Weak References

Friday Q&A 2017-09-22: Swift 4 Weak References This article is also available in Chinese (translation by Xiang Deng). Soon after Swift was initially open sourced, I wrote an article about how weak references are implemented. Time moves on and things change

mikeash.com

Discover Side Tables - Weak Reference Management Concept in Swift

Swift 5 and iOS development blog: free step-by-step tutorials authored by Maxim Eremenko since 2019.

maximeremenko.com

iOS 뷰 컨트롤러 간단하게 테스트 코드 연습하기 ( with Unit Test )

heoblitz — Sun, 26 Sep 2021 23:03:20 +0900

UIKit 환경에서 뷰 컨트롤러는 3가지 방식으로 구성할 수 있습니다.

( Xib, Storyboard, Code Base )

해당 방식으로 구성된 뷰 컨트롤러를 인스턴스화 하는 방법을 먼저 살펴보겠습니다.

뷰 컨트롤러 인스턴스 가져오기

Xib, Code Base

- 별도의 파라미터가 없는 경우 바로 인스턴스화 가능합니다.

Storyboard

- 먼저 UIStoryboard 인스턴스에 접근하고, 해당 메서드로 생성해야 합니다. 참고

뷰 컨트롤러 view 로드하기

이렇게 가져온 뷰 컨트롤러는 따로 view 를 로드하는 과정을 거쳐야 합니다.

XIB 와 Storyboard 기반의 vc 는 loadViewIfNeeded() 를 통해 Outlet 들을 구성하고 연결할 수 있게 됩니다.

Code Base 로 구성된 뷰 컨트롤러도 해당 메서드를 호출하면 viewDidLoad 도 이어서 실행되기 때문에

loadViewIfNeeded() 를 동일하게 사용할 수 있습니다.

* 다음과 같은 코드도 loadViewIfNeeded() 와 같은 동작을 합니다.

뷰 컨트롤러 view 테스트 하기

IBAction 으로 연결된 버튼을 누르면, textLabel 이 변경되는 간단한 앱을 테스트 해보겠습니다.

button 을 누르면 text 가 바뀌는 앱

뷰 컨트롤러 코드는 다음과 같습니다.

그 다음 유닛 테스트에서 필요한 환경을 구성합니다.

* 1: @testable 어노테이션과 함께 import 하면 private 를 제외한 모든 요소에 접근할 수 있습니다.

* 2: sut 는 system under test 의 약어로서 테스트할 대상을 말합니다.

* 3: 유닛 테스트는 각 메서드 마다 서로 다른 인스턴스를 생성하여 테스트합니다.

즉 필요한 객체를 생성하고 해제하지 않는다면, 해당 테스트가 전부 끝날 때 까지 sut 가 메모리에 남게됩니다.

따라서 tearDown 에서 레퍼런스 카운트를 줄이는 과정이 필요합니다.

( 순서 setUp -> 테스트 메서드 -> tearDown )

위와 같이 환경을 구축하고 테스트 메서드를 작성해보겠습니다.

1. loadViewIfNeeded 를 통해 Outlet 과 Action 을 구성합니다.

2. UIButton 의 sendActions 메서드를 통해 터치 이벤트를 전달합니다.

3. XCTAssertEqual 로 값이 맞게 들어갔는지 검증합니다.

네비게이션 컨트롤러 push 테스트 하기

이번에는 버튼을 누르면 NavigationVC 에서 push 되는 상황을 테스트 해보겠습니다.

버튼을 누르면 push 되는 앱

뷰 컨트롤러 코드는 다음과 같습니다.

테스트 메서드를 작성해보겠습니다.

* 1: push 와 같은 동작은 유닛 테스트 환경에서 동작되지 않을 수 있습니다. 따라서 런 루프에 있는 이벤트를

처리하기 위하여 다음과 같은 코드로 런 루프를 실행시킵니다. 이는 다른 UIKit 컴포넌트 테스트에서도 동일하게

사용할 수 있습니다.

* 2: navigation controller 는 viewControllers 를 통해 현재 가지고 있는 뷰 컨트롤러들에 접근할 수 있습니다.

따라서 count 를 통해 push 된 VC 가 있는지 파악할 수 있습니다.

연습을 마무리하며 "UITest VS Unit Test?"

View 와 관련된 요소는 UITest 를 통해서도 테스트할 수 있습니다.

다만 뷰 컨트롤러를 Unit Test 로 테스트하게 되면 다음과 같은 장점이 있습니다.

1. 테스트할 때 컨트롤러에 다른 의존성을 주입할 수 있습니다.

실제 앱의 경우 서로 다른 의존성들이 컨트롤러에 존재하게 됩니다. ( MVVM 의 경우 ViewModel )

이때 Mock 으로 구현된 객체를 주입하면 반복 가능하고 환경에 영향을 받지 않는 테스트가 가능해집니다.

2. Unit Test는 UITest 보다 속도가 빠릅니다.

속도가 빠른 이점을 이용해서 빠르게 성공/실패 피드백을 받고 이를 개발 프로세스에 적용시킬 수 있습니다.

3. 앱 시작점 부터 탐색할 필요가 없이 바로 테스트가 가능합니다.

UITest 는 앱 시작점 부터 테스트를 시작하게 됩니다.

이는 필요한 테스트 영역까지 탐색해서 들어가야 한다는 것을 말합니다.

이와 달리 Unit Test 는 필요한 객체를 생성하고 바로 테스트 할 수 있습니다.

언제 UITest 를 사용하면 좋을까?

UITest 는 End To End 테스트에 적합합니다. 사용자가 직접 사용하는 것 처럼

GUI 환경에서 시나리오, 기능 테스트를 진행하는 것을 의미합니다.

Apple WWDC 18, Testing Tips and Tricks

애플 WWDC 세션 자료를 참고하면 UITest 가 테스트 피라미드에 가장 높은 곳에 위치한 것을 볼 수 있습니다. 이는 Unit 테스트에 비해서 개수가 적고 변경되기 쉬우며, 통합 테스트에 가장 적합하다는 것을 말합니다.

UITest 는 다른 테스트 러너에서 실행되어서 의존성을 주입하기 어렵다는 단점이 있지만 테스트시에 앱 시작점에서 BaseURL 를 변경하고 그에 맞게 테스트 서버를 준비하면 요청을 Stub 할 수 있게 됩니다.

참고한 자료:

GitHub - nsoojin/BookStore-iOS:  Sample iOS App - A collection of examples and patterns for Unit Testing, UI Testing, handli

 Sample iOS App - A collection of examples and patterns for Unit Testing, UI Testing, handling Result/Optionals, writing documentation, and more. Details in README. - GitHub - nsoojin/BookStore-i...

github.com

iOS Unit Testing by Example

Fearlessly change the design of your iOS code with solid unit tests. Use Xcode's built-in test framework XCTest and Swift to get rapid feedback on all your code - including legacy code. Learn the tricks and techniques of testing all iOS code, especially vi

books.google.co.jp

iOS JSON 을 Decoding 하는 여러 가지 방식들

heoblitz — Thu, 26 Aug 2021 16:03:46 +0900

JSON 는 자바스크립트에서 객체를 표현하는 방식으로 REST API 에서 널리 사용되는 방식입니다.

iOS 에서는 Codable 을 통해 쉽게 JSON 을 디코딩할 수 있는데요.

Codable 과 Dictionary 로 디코딩 하는 방법을 살피고 예외적인 상황까지 이번 포스팅에서 다루고자 합니다.

Codable

Codable 은 Decodable & Encodable 프로토콜을 모두 준수하는 타입입니다.

따라서 Encode 할 필요가 없다면 Decodable 만 채택해도 네트워킹 처리에는 문제가 없습니다.

Decodable 는 프로토콜이기 때문에 Class, Struct, Enum 모두 채택할 수 있습니다.

추가적으로 CodingKeys 를 통해 Key 값을 변경할 수 있습니다.

Encode and Decode Manually

위 같이 JSON 요청과 모델의 구조가 일치하는 경우에는 직관적으로 Decoding 을 수행할 수 있습니다.

하지만 JSON 과 Model 의 구조가 다른 경우에는 커스텀하게 Decode 을 진행해야 합니다.

기존 구조와 달리 small 과 large 프로퍼티가 모두 TestResponse 안으로 들어가도록 변경되었습니다.

이때 CodingKeys 안에는 JSON 과 같은 형태인 image case 와 ImageKeys 를 추가합니다.

그 후 코드 가독성을 위해 Extension 으로 Decodable 를 채택하고, 이니셜 라이저를 작성합니다.

먼저 가장 상위 Codingkeys 를 통해 직접 Decode 를 진행합니다.

그 다음 nestedContainer 를 통해 ImageKeys 에 접근하고 하위 프로퍼티들을 Decode 해주면 끝입니다.

jsonserialization 를 통한 디코딩

Codable 이 존재하지 않을 때 iOS 5 버전부터 지원한 방식입니다.

리턴 값이 딕셔너리 [String: Any] 값으로 각각 타입 캐스팅을 통해 모델을 구성해야 합니다.

key 값으로 직접 접근할 수 있다는 장점이 있지만, 많은 타입 캐스팅 구문을 사용해야하기 때문에

레거시를 지원해야 하는 경우가 아니라면 Codable 를 사용하는 것이 좋을 것 같습니다.

참고 문서:

Apple Developer Documentation

developer.apple.com

Apple Developer Documentation

developer.apple.com

iOS URLSession Test Double 만들기

heoblitz — Tue, 17 Aug 2021 21:38:27 +0900

iOS 에서 네트워크를 테스트하는 방법은 크게 두가지가 있습니다.

1. 실제 서버(혹은 테스트 서버) 에 직접 요청하기

2. Stub 을 통해 실제 네트워크에 요청하지 않고 테스트하기

네트워크 요청은 느리고, 실패 가능성이 있으며 불확실성이 높은 요소입니다.

이런 경우에는 일정한 요청을 return 하는 Stub 을 제작하는 2번으로 주로 테스트를 진행하게 됩니다.

출처: https://developer.apple.com/

URLSessionDataTask vs URLSession 어떤 것을 Stubbing 할까?

테스트 코드 학습을 위해 가장 처음 접했던 포스팅은

배달의 민족 기술블로그 조원님의 "iOS Networking and Testing" 입니다.

( Moya 기반의 test code 코드 작성법도 기술되어 있으니, 꼭 읽어보시면 좋습니다. )

위에서는 MockURLSession 과 MockURLSessionDataTask 를 통해 DataTask 를 Mocking 하여

dataTask 메서드를 통해 특정한 응답을 갖는 stub 으로 변경하는 방식입니다.

하지만 iOS 13 에서는 URLSessionDataTask 이니셜라이저가 deprecated 되어 컴파일 경고가

발생하게 되었고, 추후에 나올 iOS 버전에서는 해당 방법을 적용하기 어렵다고 판단했습니다.

그 후 다른 방법을 찾기 시작했습니다.

URLSession Stubbing 하기

WWDC 18 에 소개되었던 방식입니다. URLSession 를 상속받는 MockURLSession 을 구현합니다.

WWDC 18, Testing Tips & Tricks

이때 오버라이드해야 하는 메서드는 총 4개입니다.

1. canInit : 요청이 처리할 수 있는지 등록된 프로토콜을 확인하는 메서드 입니다. 구현에서는 true 로 고정합니다.

2. canonicalRequest : 요청을 대체할 수 있는 메서드입니다. 구현에서는 파라미터에 주어진 request 를 그대로 리턴합니다.

3. startLoading : 요청을 처리하는 메서드 입니다. 해당 메서드에서 URLProtocolClient 에 있는 메서드를 호출하여 Stub 처리를 할 수 있습니다.

4. stopLoading : 해당 메서드가 호출되면 요청 작업을 취소해야 합니다. Mock 에서는 해당 메서드는 비워둡니다.

WWDC 예제와는 조금 다르게 클로저가 아닌, Dictionary 로 Stub 을 등록하기 쉽게 구현하였습니다.

클래스 프로퍼티인 success/failureMock 를 각 유닛 테스트에 맞게 지정해주면 간단하게 이용할 수 있습니다.

startLoading 메서드 에서는 해당 Stub 이 존재하면 성공/실패 요청을 보내게 되고,

Dictionary 에 없는 값이 요청되면 MockSessionError 가 발생하게 됩니다.

Test Code 작성하기

구현한 Mock Protocol 을 사용하려면 Network 을 수행하는 클래스에서 의존성 주입으로

URLSession 을 넣어주어야 합니다. ( 방법에는 이니셜라이저, 프로퍼티, 팩토리 방식이 있습니다. )

각자의 NerworkService ( or Provider ) 는 이미 구현되어 있다고 가정해보겠습니다.

URLSessionConfiguration.ephemeral ( 로컬에 캐싱하지 않는 옵션 ) 을 통해 config 을 생성하고,

protocolClasses 를 아까 구현한 MockProtocol 로 지정해줍니다.

그 다음 urlSession 을 생성하고, 각자 의존성 주입 방식에 맞게 테스트 하려는 네트워크 객체에 주입합니다.

* Behaviour Driven Development 기반으로 테스트 코드를 작성하였습니다.

가장 핵심은 "MockURLProtocol.successMock[urlString] = Data(responseString.utf8)" 코드를 통해

네트워크 요청을 간편하게 Stub 할 수 있습니다. 그 후에는 각 프로젝트 상황에 맞게 Data 를 검증하면 됩니다.

## 필자가 더 공부가 필요한 부분

Mock 과 Stub은 Test Double 에서 나온 용어로서, 상태 검증과 행위 검증에 따라 구분한다는 것을 알게되었습니다.

다만 Apple 에서는 MockURLProtocol 로 네이밍을 했지만 개인적으로는 Stubbing 에 더 가깝다는 생각을 했습니다.

학습을 위해 다른 게시글과 자료들을 찾아보아도 Stub 과 Mock 을 혼용하는 예제들을 많이 보게 되었고,

명확하게 구분하기 어려운 개념이 아닐까 단편적으로 이해한 상태입니다.

추후에 이해도가 높아지면 내용을 추가하려 합니다.

* 현업에서는 상태와 행위 검증이 동시에 이루어지는 경우가 많기 때문에 Mock 으로 많이 사용한다는 말씀을 들었습니다.

iOS 에서 Void Observable 테스트 코드 작성하기

heoblitz — Tue, 13 Jul 2021 09:55:25 +0900

RxSwift 에서 다음 이벤트로 값을 전달할 필요가 없는 경우에는 Void Observable 를 사용합니다.

viewModel 에서 화면 전환에 사용 중인 Relay

그리고 테스트 코드를 작성하기 위해서는 RxTest 에 있는 TestScheduler 를 이용하여

가상 시간의 이벤트들을 방출하는 옵저버블을 만들고, XCTAssertEqual 을 통해 events 를 비교하게 됩니다.

Bool 옵저버블을 비교하는 Test Code

Bool Observable 은 문제 없이 테스트 가능하지만 여기서 Void Observable 에서 문제점이 발생하게 됩니다.

.next 로 들어가는 요소는 Equatable 을 준수해야 하기 때문입니다.

RxSwift 저장소에서 해당 문제가 논의되며 PR이 올라왔었지만, 현재는 메인 저장소에 반영되지 않았습니다.

이를 해결하는 방식은 크게 2가지가 있습니다.

1. 별도의 테스트 객체를 선언하고, Event Time 으로 Equtable 을 준수한다.

2. map 을 통해 Boolean 이벤트로 변경하여 테스트한다.

-> 적은 코드로 해결할 수 있으므로 개인적으로 가장 선호하는 방식입니다.

map 으로 Bool 이벤트로 변경하기

다음과 같이 코드를 작성하면 Void 옵저버블을 쉽게 테스트할 수 있습니다.

Blitz.dev

정적 분석으로 iOS 앱 구조 파악하기

iPA

iPA 다운 받기

정적 분석

iPA 구조

1. ( root ) /

2. _CodeSignature

3. Frameworks

Mach-O

Mach-O Header

Load commands

Data

코딩테스트를 위한 Swift 필수 자료구조 구현하기

Queue

Double Array를 활용한 Queue

Cursor를 활용한 Queue

Heap ( Priority Queue )

Heap 구현이 꼭 필요하지 않은 경우

8개월간 같은 iOS 앱을 리팩토링하며 배운점

RxSwift 공부하고 적용하기

Tuist 와 앱 모듈화

테스트 가능한 코드로 리팩토링하기

테스트 코드 작성하기

중복되는 코드를 줄이고 재사용하기

Protocol

Inheritance

더 나아가야 할 방향

UI 컴포넌트 재사용하기

Storyboard 일 필요가 없다면 XIB 로 생성하기

iOS Dependency Injection 개념 파악하기

의존성 주입이란?

의존성 주입은 좋은 방식인가? 장점은 무엇일까

의존성 주입의 단점

의존성은 어디에서 주입되는가?

정리

참고 자료

초보 개발자가 오픈소스에 기여하는 방법

목차

1. Pull Request 에 대해서 이해하기

2. 버그 및 수정사항 발견하기

3. 마무리

Swift Reference Count 고찰 ( with side table )

Swift Reference Count

Strong RC

Unowned RC

Weak RC

What is Side Table?

Weak vs Unowned?

iOS 뷰 컨트롤러 간단하게 테스트 코드 연습하기 ( with Unit Test )

뷰 컨트롤러 인스턴스 가져오기

뷰 컨트롤러 view 로드하기

뷰 컨트롤러 view 테스트 하기

네비게이션 컨트롤러 push 테스트 하기

연습을 마무리하며 "UITest VS Unit Test?"

언제 UITest 를 사용하면 좋을까?

iOS JSON 을 Decoding 하는 여러 가지 방식들

Codable

Encode and Decode Manually

jsonserialization 를 통한 디코딩

iOS URLSession Test Double 만들기

URLSessionDataTask vs URLSession 어떤 것을 Stubbing 할까?

URLSession Stubbing 하기

Test Code 작성하기

iOS 에서 Void Observable 테스트 코드 작성하기