-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#178] 테스트코드 작성 전 코드 리팩토링 #197
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
상세 내용
테스트코드 작성하는 시스템을 선제적으로 적용해보려고 이것저것 문서들을 참고해봤는데, 현재 코드로는 쉽지가 않은 것 같다고 판단이 서서 우선 완료함쪽 코드 리팩토링을 전체적으로 진행했습니다.
테스트코드 작성이 어렵다고 판단한 이유로 몇가지 이유가 있는데, 정리하면 다음과 같았습니다
전체적인 리팩토링은 다음 레포를 참조했습니다.
리팩토링 1. Input & Output 정의
ViewModelType
이라는 프로토콜을 새로 정의했습니다. 뷰모델 클래스들은 해당 프로토콜을 채택합니다.위와 같은 형태로 구현됩니다. 기본적으로 인풋 & 아웃풋 & 트랜스폼의 절차는
완료함 메인화면 기준으로 인풋을 정의해보면 다음과 같은 것들이 있습니다.
viewDidAppear
- 완료함 진입 인풋 트리거이후 API 요청selection
- 테이블뷰 선택 이벤트retrieveNextPageTrigger
- 해당 뷰에 대해서만 적용되는 특수한 상황인데,viewDidLoad
함수가 네비게이션 컨트롤러에 새로운 뷰를 푸시 & 팝 할때 두 상황 모두 호출이 되어버려서 내부적으로 로직을 추가해두었습니다.viewDidAppear를 기준으로 설명하면, 트랜스폼을 통한 데이터의 정제 과정이 아래와 같이 이루어집니다.
이렇게 되면 회고작성 가능한 갯수가 뷰 컨트롤러에 아웃풋을 통해 전달되고 해당 데이터를 뷰에 바인딩해주면 됩니다.
리팩토링 2. 네트워크 함수 Single Trait 적용
현재 네트워크 요청은
Observable<Result<Success, Failure>>
를 기반으로 처리하여, 구독자가onNext
내에서switch - case
로 failure 케이스 내에서 에러처리를 진행하고 있습니다.이렇게 되면 사실상 에러가 반환된 데이터임에도
next
이벤트로 방출되어 에러처리가 어렵다는 문제가 있습니다.Single
Trait을 사용하면 이러한 문제를 쉽게 해결 가능합니다.리팩토링 과정중이라, 기존 코드를 모두 수정할 수는 없어서 실험적으로 완료함에만 적용하기 위해 APIService, APISession 프로토콜에 함수 하나를 추가했습니다.
requestSingle
함수가 Single 기반으로 네트워크를 요청하는 함수인데, 뷰모델에서ServiceGoalList
와 같이 API 요청 함수들을 모아둔 프로토콜을 채택하기 때문에ServiceGoalList
프로토콜에서 옵저버블을 리턴하는 함수가 아닌 Single을 리턴하는 함수를 추가합니다.이렇게 되면 옵저버블에서 에러처리를 할때
onNext
에서 하는것이 아닌onError
에서 처리할 수 있게 되어 코드 직관성이 더 좋아질거라 생ㄱ각합니다.기타
리팩토링 적용은 제가 독립적으로 맡은 부분에만 적용되도록 구성해놓아서 다른 곳에 영향은 없는 상태입니다!
뷰모델 정의시 Input & Output 기반으로 생각하면 서로 코드 리뷰에도 도움이 많이 될 것 같아서 PR 확인 & 레퍼런스로 달아둔 문서들 읽어보시공 자유롭게 코멘트 주세요 !
Reference
셀프 체크리스트