오늘의 공부
- Operation, GCD에 대한 간단한 학습
- 알쓸신잡(전수열님)
비동기프로그래밍
GCD(DispatchQueue) / OperationQueue
- 직접적으로 쓰레드를 관리하지 않고, 큐(Queue)라는 개념을 이용해 작업을 분산 처리
- 쓰레드의 갯수를 시스템에서 알아서 관리함
- 쉽게 다른 쓰레드에서 (오래걸리는)작업들이 "비동기적으로 동작"하도록 만들어준다
(어떤 API들은 내부적으로 비동기적으로 실행되도록 설계되어 있다
참고)
앨런 유튜브 : https://www.youtube.com/watch?v=whGgi2KK4ok&list=PLqK3bFbiW77MBn0ofPRjGDBU9Ytnz9-6S&index=7
OperationBlock에 대한 포스팅 : https://soooprmx.com/swift-blockoperation-사용하기/
알쓸신잡을 들으며...👨🏻💻
전수열님의 테스트에 대한 생각!
처음에 무엇을 테스트할지를 정하는 것이 매우 중요하다!
- End - to - End 테스트 (테스트 양이 적으며, 어렵다)
- 실제 앱을 사용하는 것처럼 테스트 하는 것 - Integration 테스트
- 앱을 구성하는 여러 요소들이 합쳐졌을 때 잘 작동하는 지 - Unit 테스트 (테스트 양이 많으며, 쉽다)
테스트 하기 쉬운 것부터 하는 것이 좋다
- 가격 포맷터
- 날짜 포맷터
- Codable 변환
- String 익스텐션
와 같이 입력이 같으면 출력이 같은 것들, 사이드 이펙트가 없는 것들
테스트를 하면서 "아.. 이런 것도 내가 테스트 해야된다고??" 라는 생각이 들어도, 해라!!!!
무조건 해야된다!
테스트는 익숙해지는 것이 중요하다
지식의 영역이 아니라 숙달의 영역이다!!!
그리고 테스트를 계속하다보면 요구사항이 더욱 더 명확해진다. 방향을 잡기 편해진다!
그리고 테스트 스펙이 곧 기능 명세가 된다
이후,
테스트가 어려운 것들(입력이 같아도, 출력이 달라지는 것들)을 테스트 할 때는??
테스트 대역(Test Doubles)를 사용해서 테스트를 진행한다
- Dummy : 파라미터를 채우기 위해 필요한 개체
- 프로필 뷰를 테스트할 때 넘기는 User개체 - Fake : 작동하긴 하지만 테스트만을 위해서 만들어진 구현체
- 실제 키체인에 저장하지 않고 메모리에서만 관리하는 키체인 - Stub : 미리 지정한 결과를 반환할 수 있는 구현체
- 미리 지정한 이미지 선택 결과를 반환하는 UImagePickerStub - Spy : Stub에 더해서 함수 호출을 기록할 수 있는 구현체
- 호출된 메서드를 기록하는 구현체 - Mock : 원하는 메서드가 의도한 대로 잘 호출되었는지를 검증할 수 있는 구현체
- 의도한 메서드가 호출되지 않으면 실패시키는 무언가
여튼 이런 것들이 있고 우리는 입력이 같아도, 출력이 달라지는
즉, 의존성을 가지고 있는 것들에 대해 의존성을 갈아끼우기 위해서 Test Double을 사용하는 것이다
의존성 주입은?? (Dependency Injection)
의존성 주입(dependency injection)은 하나의 객체가 다른 객체의 의존성을 제공하는 것
네트워크를 통해서 위치를 받아오고 그것에 대한 정보를 출력하는 테스트를 한다고 했을 때
위치가 바뀔 때마다 출력이 바뀌는 상황이 생긴다
항상 똑같은 테스트 결과를 낼 수 있도록, 의존성 주입을 하는 것이다!
TDD(Test Driven Development)
RED - 실패하는 테스트부터 작성
GREEN - 테스트를 통과하는 최소한의 구현 작성
REFACTOR - 지저분한 구현 개선
이 세 과정을 반복하는 개발 과정이다
리팩토링 :
1. 실패하는 테스트가 존재할 때 진행
2. 테스트를 통과하는 최소한의 구현이 존재할 때 진행
리팩토링의 진짜 의미
다시 작성하는 것 -> 재작성
설계 변경 없이 구현만 개선하는 것
CI/CD 파이프라인
테스트 작성도 중요하지만
테스트가 계속 실행되고 검증되는 것이 중요하다
CI / CD??
Continuous Integration (지속적 통합)
개발 -> 푸쉬 -> 린트 -> 빌드 -> 테스트
Continuous Delivery(지속적 배포)
개발 -> 푸쉬 -> 빌드 -> 배포
이것이 중요한 점은 사람이 할 일을 기계가 대신한다는 것이다
사람은 더 중요한 일에 집중!!!
함께 성장하기
팀원들과 여러가지 피드백 환경을 통해서 성장하자!!
짝 프로그래밍(실시간)
코드리뷰(작업 단위)
회고(이터레이션 단위)
짝 프로그래밍
- 역할 자주 바꾸기!
- 서로의 암묵지 꺼내기
- 놓쳤다면 바로 질문하기
코드 리뷰
- 문제가 없는지 검증하는 것은 기본
- 배경이나 의사결정 등 맥락 전달
- PR 본문도 리뷰의 대상
- 좋은 PR은 리뷰어가 리뷰하기 좋은 PR
리뷰 노트
ex) 현재는 이것이 최상의 방법이라고 하였는데, 다른 방법이 있으면 알려주세요
commit 단위로 해주세요 등등 테스트할 때 편할 수 있게 해주는 방법에 대해서 명시
회고
(이터레이션 단위 피드백)
탓하는 과정이 아니라 더 나아지기 위한 과정, 감정에 더 솔직해지고 감정 상태를 더 많이 공유하기
팀 회고
만족 : 다음번에도 그대로 할 것들
반성 : 다음번에는 다르게 할 것들
개선 : 개선할 수 있는 것들
개인 회고
Fact 무엇을 했고
Feeling 무엇을 느꼈고
Finding 어떤 교훈이 있었다
