---
# System prepended metadata

title: Untitled

---

## 테스트
모두가 필요하다고 하지만 모두가 하지는 않는 것
덤벨을 들 줄 안다고 해서 근육이 만들어지는 것은 아니다.

테스트를 작성하면 요구사항이 명확해진다.
테스트는 기능 명세가 된다.

## TDD
RED-GREEN-REFACTOR
리팩토링
설계 변경없이 구현만 개선하는 것
테스트가 변경되지 않는 다는 얘기

## CI/CD 파이프라인
테스트 작성도 중요하지만
테스트가 계속 실행되고 검증되는 것도 중요하다.

CI - 지속적 통합
개발 - 푸시 - 린트 - 빌드 - 테스트

푸시 - 린트 사이에서 지속적 통합이 들어감.

테스트 성공여부에 따라서 
PR을 쓸 때 실패를 한 부분을 알려서 개선하기도 하고
coverage가 부족한 부분을 알려주어서 개선하는 식

CD - 지속적 배포
개발 - 푸시 - 빌드 - 배포

스테이징 - 배포할 때 테스트플레이스로 올라감
프로덕션 - 배포할 때 앱스토어로 올라감

파이어베이스 디스트리뷰션 에서 버전관리를 해놓음

CI/CD 는 사람이 할 일을 기계가 대신하는 것
그 시간에 코드를 더 짜게 해줌.

## 피드백 루프
어떤 행동을 하고 피드백을 받고 개선을 하고
행동 - 피드백 - 개선 을 반복하면 성장을 하게 된다.

주기적으로 유효한 피드백을 동료들과 나눌 수 있는 환경을 만드는 것이 중요

짝 프로그래밍 (실시간)
코드리뷰 (작업 단위)
회고 (이터레이션 단위)

## 코드리뷰
25:00~

PR 본문이 좋은 게 리뷰하기 좋은 PR

배경
작업 내용
테스트 방법
리뷰 노트
스크린샷

## 회고
탓하는 과정이 아니라 더 나아지기 위한 과정
논리를 가지고 해야되는 직업이지만
사람과 일을 하는 것이기 때문에 감정이 굉장히 중요하다

논리적이었다고 생각했던 것도 나중에 돌이켜보면 감정에 의해서 결정이 되고 논리를 붙인것도 실제로 많다.

왜 그런 감정을 느꼈는지에 대해서 구체적으로 회고

구체적이라는 건 주관적일 수 있기 때문에
특정 사건에 대해서 상세히 회고.

만족 - 다음에도 그대로 유지할 것
반성 - 다음에는 좀 바꿀 것
개선 - 개선할 수 있을 것?

개인회고도 중요함.
내가 작업에 임하는 태도

3F
Fact - 무엇을 했고
Feeling - 무엇을 느꼈고
Finding - 어떤 교훈이 있었다















네트워크 요청을 테스트 할때는
테스트 대역을 사용한다.
여기서 대역은 연기의 대역같은 느낌을 뜻함

- Dummy
    - 파라미터를 채우기 위한 개체
- Fake
    - 테스트만을 위해 만들어진 구현체
- Stub
    - 지정한 결과를 반환하는 구현체
- Spy
    - stub에 추가로 함수 호출을 기록할 수 있는 구현체
- Mock
    - 의도대로 잘 호출되었는지 검증하는 구현체


## 의존성 주입
좌표
