학습내용

---

성장하는 iOS 개발자 되기 - 전수열

1. 테스트

무엇을 테스트할 것인가?

• End-To-End

  • 예): 전체 구매 과정

• Integration

  • 예): 상품 상세 화면

• Unit

  • 예): 상품 가격 뷰

1. 테스트 하기 쉬운 것 부터

유틸리티: 입력이 같으면 출력이 같다를 증명하는 테스트!

2. 이런 것도 굳이 테스트를 작성해야 할까?

사소한 것이라도 시간만 허락해진다면 하는게 좋다.

테스트는 숙련도의 문제이다.

• 테스트 메서드는 최대한 자세하게 작성한다.
• 그러다 보면 테스트 스펙이 곧 기능 명세가 된다.

func testPriceView_whenNotDiscounted_displyasPriceOnly()
func testPriceView_whenDiscounted_displaysDscountRateAndPrice()

2. 점점 복잡해진다면

네트워크 요청, 시스템 프레임워크, 서드파티 라이브러리

입력이 같아도 출력이 달라진다.

이럴때는:

테스트 대역을 사용한다 (Test double)

• Dummy: 파라미터를 채우기 위해 필요한 개체 [길거리의 행인과 같은 요소]
  • e.g. 프로필 뷰를 테스트할 때 넘기는 User 개체
• Fake: 작동하긴 하지만 테스트만을 위해서 만들어진 구현체
  • e.g. 실제 키체인에 저장하지 않고 메모리에서만 관리하는 키체인
• Stub: 미리 지정한 결과를 반환할 수 있는 구현체
  • e.g. 미리 지정한 이미지 선택 결과를 반환하는 UIImagePickerStub
• Spy: Stub에 더해서 함수 호출을 기록할 수 있는 구현체
  • e.g. 호출된 메서드를 기록하는 MFMailComposeViewControllerSpy
• Mock: 원하는 메서드가 의도한 대로 잘 호출되었는지를 검증할 수 있는 구현체
  • e.g. 의도한 메서드가 호출되지 않으면 실패시키는 무언가

의존선 주입(Dependency Injection)

stub 사용

TDD (Test Driven Development)

1. 실패하는 테스트부터 작성
2. 테스트를 통과하는 최소한의 구현 작성
3. 지저분한 구현 개선

리팩토링의 진짜의미는 재작성

• 설계 변경 없이 구현만 개선하는 것

2. CI/CD 파이프라인

지속적 통합 Continuous Integration

테스트 작성도 중요하지만 테스트가 계속 실행되고 검증되는지 확인하는 것도 중요하다.

지속적 배포 Continuous Delivery

3. 함께 성장하기

피드백 루프 만들기

짝 프로그래밍(실시간 패드백)

• 역할 자주 바꾸기
• 서로의 암묵지 꺼내기
• 놓쳤다면 바로 질문하기

코드 리뷰(작업 단위 피드백)

• 문제가 없는지 검증하는 것
• 배경이나 의사결정 등 맥락 전달
• PR 본문도 리뷰의 대상
• 좋은 PR은 리뷰어가 리뷰하기 좋은 PR
• 코딩 스타일은 웬만하면 기계가 하도록

*코드리뷰 템플릿

​ 배경: 어떠한 생각을 가지고 작성 했는지

​ 작업내용: 실제로 작성한 코드를 요약하는 것

​ 테스트 방법: 내 코드를 사용하는 방법에 대해 가이드라인 남기는 것

​ 리뷰 노트: 더 나은 방법 요청, 리뷰어에게 부가적인 정보 남기기(어떻게 읽는게 수월할 지)

​ 스크린샷:

회고 (이터레이션 단위 피드백)

• 탓하는 과정이 아니라 더 나아지기 위한 과정

• 감정에 더 솔직해지고 감정 상태를 더 많이 공유하기

• 왜 그런 감정을 느꼈는지에 대해서 집중적으로 회고해보기

팀 회고

• 만족: 다음번에도 그대로 할 것들
• 반성: 다음번에는 다르게 할 것들
• 개선: 개선할 수 있을 것들

개인 회고

• Fact 무엇을 했고
• Feeling 무엇을 느꼈고
• Finding 어떤 교훈이 있었다
  • Future Action: 다음 번에는 더 시도해 봐야할 것들