21년 7월 2주차 회고

Swift - Protocol 복습, Property 복습

 

Protocol을 사용하지 않아서 많은 부분을 까먹었다.

이번에 프로젝트에서 사용하면서 다시 공부했다.

 

 

Lazy property에 대해서 자세히 공부했다.

lazy를 프로젝트에서 사용하지 않아서 특징들을 까먹었다.

기본적으로 알고 있던 건 인스턴스 생성시가 아닌 속성에 접근 시에 초기화된다는 점뿐 디테일을 까먹고 있었다.

구조체일 경우 let으로 인스턴스를 만들고 lazy 속성에 접근하면 에러가 발생한다는 점.

lazy를 사용하면 인스턴스 속성을 다른 속성에서 접근이 가능하다.

 

 

---

 

Naming Convention

 

Convention에 관해서 apple에서 제공하는 가이드라인이 있어서 읽어봤다.

이름을 지을때마다 느끼는데 적절한 이름 짓기는 역시 힘들다ㅠㅠ

 

https://swift.org/documentation/api-design-guidelines/

Swift.org

 

---

TDD

 

아직 TestDouble에 대해서는 완벽하게 모르지만 일단 TDD를 적용시켜서 코드를 짜기 시작했다.

계속 완벽히 이해될떄까지 이론을 공부하기보단 직접 만들어보면서 이해하는 게 훨씬 도움이 될 거 같다고 생각했다.

Calendar를 만드는 부분을 TDD를 이용해 작성중인데 확실히 아직 익숙지 않은 부분이라 코드 작성 속도가 느리지만 무엇인가 코드를 이후에 고칠 때 자신감이 생겼다.

 

 

---

 

ViewController Test하기

 

내가 만든 class, struct는 어느 정도 테스트할 수 있는데 ViewContoller는 어떻게 해야 하는지 궁금했다. (사실 오래전에 배우긴 했는데 안 써먹으니 까먹었다...)

그래서 다시 공부를 해봤다.

1. 왜 VC를 테스트해야 하는지
2. 무엇을 테스트하고 무엇을 테스트하면 안 되는지
3. 어떻게 테스트할 것인지

에 대해서 다루는 글을 봤다.

UIViewController와 UIView의 layout styling을 테스트하면 안 된다.

예를 들어 백그라운드 컬러,

Label의 폰트, 사이즈

autolayout 등등

 

Content에 초점을 맞춰야 한다.

cell의 개수

text가 맞는지

버튼이 enabled인지

UIView의 frame이 맞는지

 

ViewController를 테스트하는 방법을 공부하면서 이제 DI(Dependcy Injection)에 대해서 알아야 했다.

꼬리에 꼬리를 무는 공부!

아무튼 DI도 예전에 들어는 봤고 사용도 해봤는데 뭐가 뭔지 정확하게 모르고 사용했었고 뭔지 잘 모르니 이번 기회에 또 공부를 했다.

 

ViewController를 테스트하려면 viewController의 의존성을 mock으로 대체해야 한다. 이때 DI를 사용할 수 있다

여기서 사용한 방식은 MVP 모델을 이용했는데 MVC로는 어려운 건가 궁금하다.

이 글에서는 MVP모델뿐 아니라 여러 모델에서 사용 가능하다고 하는데 Presenter를 한 번도 써 보지 않아서 어떤 식으로 연습을 해봐야 하는지 고민이 됐다.

 

MVP와 MVVM이 나왔으니 이것도 공부를 해봐야겠지..?

 

 

https://www.vadimbulavin.com/unit-testing-view-controller-uiviewcontroller-and-uiviewin-swift/

Unit Testing View Controllers and Views in Swift

 

---

 

DI(Dependency Injection): 의존성 주입

 

필요한 객체를 직접 생성하는 게 아니라 외부에서 받아서 사용하는 방법(테크닉)이다.

DI의 개념은 Dependency Inversion Principle 또한 알고 있어야 했는데 이는 디테일한 하위 모델 구현은 높은 추상화를 가진 상위 모델 구현에 의존해야 한다는 규칙이다.

 

그냥 간단하게 init에서 인자로 받아서 넣는 것으로만 알았는데 이 글을 읽어보니 한 가지 방법 중에 하나일 뿐이고 여러 가지 방법이 있는 것을 알게 됐다.

그리고 이걸 공부하면서 DIP에 대해서도 알게 됐다.

 

https://www.vadimbulavin.com/dependency-injection-in-swift/

Advanced Dependency Injection on iOS with Swift 5

 

---

Test에서 setup() 과 setupWithError() 의 차이

 

기존에 사용하던 setup과 차이는 단지 이름에서 차이 나듯 error를 던지냐 안 던지냐의 차이다.

호출 순서는 setupWithError -> setup -> teardown -> teardownWithError 순으로 실행이 된다.

testMethod안에서 do catch나  try?를 쓰지 않고 그냥 try만 작성해도 됐다.

그리고 에러가 발생하면 Skip이 된다.

 

뭐 그냥 기본으로 만들면 이거로 생성되길래 이걸 사용하기로 했다.

 

 

---

 

Optinal Test

 

구현한 메서드가 중간에 옵셔널 바인딩을 사용해서 바인딩에 성공할 경우는 테스트하기 괜찮았지만 실패했을 경우를 테스트하는 방법이 궁금했다.

이 코드가 바인딩이 안될 경우가 딱히 없었기 때문에 이 부분은 어떻게 해야 하는 걸까???라는 생각이 들었다

 

찾아보다 아래 게시글을 보게 됐다.

바인딩 설명은 없었고 여기서 얻어갈 건 XCTAssertNotNil을 사용하는 거보다 XCTAssertEqual을 이용해서 원하는 값이 들어가 있는지 확인하는 게 더 좋다는 것

 

https://qualitycoding.org/unit-test-optionals-swift/

How to Unit Test Optionals in Swift | Quality Coding

 

---

 

생성한 Date가 UTC로 나오는 현상

 

 

으어아어

이거 때문에 몇 시간을 날린 건지...

분명 생성한 날짜는 2021 7 1 인데 자꾸 9시간 차이나는 UTC로 출력이 됐다.

심지어 calendar와 dateComponents의 timeZone도 Asia/Seoul로도 해보고 current로도 했는데 자꾸 이렇게 나왔다.

검색도 해보고 했는데 찾아본 결과로는.... 아주 황당하게

Date를 출력하면 UTC로 나오는 모양이다. 뭔 짓을 해도 출력을 하면 그냥 저렇게 나온다...

그래서 DateFormatter로 변환해서 출력해봤더니 KTC로 잘 나온다...

이거로 얼마나 헤맸는지....ㅠㅠ

Timezone이 설정 안 되는지 알고 계속 시도해보고 찾아보고 놓친 게 있는 건가 공부했었는데... 그냥 출력 시에는 무조건 UTC로 되는 거였다.

 

---

xcode cannot test target ~~

 

진행하던 프로젝트의 테스트를 아주 오랜만에 실행했더니 testTartget이 맞지 않아서 테스트를 할 수 없다는 경고가 떴다.

으음 건드린 건 딱히 없었는데...

관련 키워드로 검색을 했는데 나오지 않았다.

git을 믿고 그냥 내가 고쳐봐야지 하고 일단 에러에 나온 대로 target을 확인했다.

문제를 해결한 건 Targets의 iOS Deployment Target이 달라서 생긴듯하다.

상용 배포 버전과 맞게 12.1로 바꿔주니 문제가 해결됐다.

 

 

 

---