You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BookReview[88283:2308525] [db] _LSSchemaConfigureForStore failed with error Error Domain=NSOSStatusErrorDomain Code=-10817
Xcode 13.0 상에서 시뮬레이터 실행 후 TextView 입력 활성화 시에 뜨는 로그 👉🏻 관련 솔루션 1 - Just log noise, 신경쓰지 말자
x86_64 Rosetta에서 Xcode 및 시뮬레이터를 실행할 때 API가 실패 👉🏻 관련 솔루션 2 - scheme argument 설정을 통한 메시지로 해결 가능
프로토콜 활용
비동기적으로 서로의 뷰에서 데이터를 연결하고 주고 받는 것에 있어서 delegate 패턴을 구성하는데 프로토콜을 활용하고 구성하고, MVVM의 아키텍쳐 구성에 있어서 로직을 분리하여 뷰는 보여주는 역할만, presenter는 나머지 로직을 수행하도록 구성하는 패턴을 만들어보았다.
확실히 프로토콜이라는 청사진 자체가 의존성을 분리시켜 구분 짓고 경계선을 나뉜다는 개념이 모호했는데, 조금은 와닿았다. 설계에 있어서 이를 고려하고 짤 수 있다면 조금은 더 효율적인 코드를 구성하는 게 가능할 듯
HTML 형식의 tag 변환
네이버 검색 API 사용시 관련 tag <b>, </b>가 포함되서 data가 날아오는 경우 발생, extension을 구성하여 Html 변환 코드 구현
Unit Test Code
동료 개발자에게서 TDD 관련하여 궁금증이 많이 생겨서 여러 의견을 모았었다. 서비스에 따라 시간에 급박하여 이런거는 오히려 리소스 낭비라고 생각하는 의견과 더불어 차후에 유지보수도 편하고 QA를 줄일 수 있다는 점에서 유용하다고 생각하는 등 다양한 의견이 많았다. 그래도 아직까지는 호의적인 편이다.
튜토리얼을 진행하면서 Rx + MVVM에서의 로직 분리를 통한 테스트 코드 작성과 MVP에서 프로토콜 기반의 로직 분리를 통한 테스트 코드를 작성하였다. 의존성을 최대한 분리하고 독립적인 로직이 구성 되었을 때 보다 테스트가 쉬워진다. init()을 활용하여 의존성을 주입하는 방식으로 class를 구성하는 것을 통하여, 내부 프로퍼티에 인스턴스로 무조건 초기화하여 할당하는 것을 지양해야할 것 같았다. 나중에 주입하는데 매우매우 귀찮아진다. Mock에서도 유사하게 구현하기 때문에.. 그리고 케이스를 구성하면서 몇 가지 정리하면 다음과 같다. 몇 가지 고민한 부분을 토대로 아티클을 찾아봐야할 듯..
네트워크 패칭의 결과를 목업과 비교하여 해당 테스트 구성
원하는 로직 자체의 구성을 유사하게 만든 Mock_ViewController를 구성하여 해당 프로토콜을 통해서 메서드의 실행 여부 확인
실질적인 해당 메서드의 동작 확인 + 데이터의 비교를 통한 케이스 통과 구성이 필요
테스터블하게 구현에 있어서 BDD의 필요성 - 테스트 케이스마다 주석을 대체하고 보다 명료해진다
고민
회고
M1 시뮬레이터
Xcode 13.0 상에서 시뮬레이터 실행 후 TextView 입력 활성화 시에 뜨는 로그
👉🏻 관련 솔루션 1 - Just log noise, 신경쓰지 말자
x86_64 Rosetta에서 Xcode 및 시뮬레이터를 실행할 때 API가 실패
👉🏻 관련 솔루션 2 - scheme argument 설정을 통한 메시지로 해결 가능
프로토콜 활용
비동기적으로 서로의 뷰에서 데이터를 연결하고 주고 받는 것에 있어서 delegate 패턴을 구성하는데 프로토콜을 활용하고 구성하고, MVVM의 아키텍쳐 구성에 있어서 로직을 분리하여 뷰는 보여주는 역할만, presenter는 나머지 로직을 수행하도록 구성하는 패턴을 만들어보았다.
확실히 프로토콜이라는 청사진 자체가 의존성을 분리시켜 구분 짓고 경계선을 나뉜다는 개념이 모호했는데, 조금은 와닿았다. 설계에 있어서 이를 고려하고 짤 수 있다면 조금은 더 효율적인 코드를 구성하는 게 가능할 듯
HTML 형식의 tag 변환
네이버 검색 API 사용시 관련 tag <b>, </b>가 포함되서 data가 날아오는 경우 발생, extension을 구성하여 Html 변환 코드 구현
Unit Test Code
동료 개발자에게서 TDD 관련하여 궁금증이 많이 생겨서 여러 의견을 모았었다. 서비스에 따라 시간에 급박하여 이런거는 오히려 리소스 낭비라고 생각하는 의견과 더불어 차후에 유지보수도 편하고 QA를 줄일 수 있다는 점에서 유용하다고 생각하는 등 다양한 의견이 많았다. 그래도 아직까지는 호의적인 편이다.
튜토리얼을 진행하면서 Rx + MVVM에서의 로직 분리를 통한 테스트 코드 작성과 MVP에서 프로토콜 기반의 로직 분리를 통한 테스트 코드를 작성하였다. 의존성을 최대한 분리하고 독립적인 로직이 구성 되었을 때 보다 테스트가 쉬워진다. init()을 활용하여 의존성을 주입하는 방식으로 class를 구성하는 것을 통하여, 내부 프로퍼티에 인스턴스로 무조건 초기화하여 할당하는 것을 지양해야할 것 같았다. 나중에 주입하는데 매우매우 귀찮아진다. Mock에서도 유사하게 구현하기 때문에.. 그리고 케이스를 구성하면서 몇 가지 정리하면 다음과 같다. 몇 가지 고민한 부분을 토대로 아티클을 찾아봐야할 듯..
참고
👉🏻 UILabel-HTML
👉🏻 기본적인 Unit 테스트 구성
The text was updated successfully, but these errors were encountered: