2025/09/30 FastAPI -2

복사 붙여넣기가 아닌 옮기기

---

Coverage

---

• poetry run coverage run -m pytest temp.py
  • 다음 명령어를 실행하면 커버리지를 측정하면서 테스트를 수행합니다.
• poetry run coverage report -m
  • 다음 명령어를 실행하면 커버리지 보고서를 출력해줍니다.
  • -m 옵션은 show missing 입니다. 실행되지 않은 라인이 정확히 어디인지 보여줌
• stmts 는 분모 및 분자의 일부가 되는 총 라인 수
• miss 는 전체 테스트를 모두 실행했음에도 불구하고 단 한 번도 실행되지 않은 라인의 개수
• Missing 은 실행되지 않은 라인의 라인 넘버를 보여줌

---

• 테스트 코드는 coverage의 정의에 들어가지 않기 위해서 적절한 omit(제외,생략)의 설정 필요

HTML 페이지에서 보기

---

Dev dependency

• 종속성은 2가지로 나눌 수 있다.
  • 서버가 실행되는 중에 필요한 종속성(예: fastapi, uvicorn, pydantic)
  • 개발하는 중에만 필요하고, 서버가 실행되는 도중에는 전혀 사용되지 않는 종속성
• group=dev 를 사용해서 라이브러리들을 설치 했음
  • "group=dev" 이 종속성은 개발할때만 필요하고, 서버가 실행될 때에는 필요하지 않다
• 종속성을 분리해서 관리하면 쓰지않을 종속성을 설치하느라 시간과 공간을 낭비할 필요 없어짐

---

자동화 테스트가 필요한 이유

기술 부채 : 개발하면서 내린 나쁜 의사결정이 빚처럼 쌓여서 결국 프로젝트를 파멸로 이끔
자동화 테스트 : "수정"을 두려워 하지 않도록 만들어주는 강력한 무기

• 테스트는 작성한 코드가 의도한 대로 동작하는지를 검증해줌
  • 사람이 아니라 코드로 코드를 검증하기 때문에 반복적인 실행에 아주 유리
    • 컴퓨터는 실수하지 않고 반복되는 작업에 지치지 않고 대충하는 일이 없다.

---

테스트 스크립트 작성

async

---

전체 테스트 실행

---

---

---

Github action

• “자동화 도구” 특히 코드가 GitHub에 올라올 때 자동으로 검사·빌드·배포 같은 걸 해줌

• 다른사람이 올린 코드도 자동으로 검사되기 때문에 "안 깨진 코드만 main 브랜치에 남음"

• .github/workflows/~.yml 이라는 파일이 존재하면 (올린 레포에서만 실행)

  • GitHub Actions가 이걸 읽고
    • "push될 때 이 단계들(steps)을 실행하라는 거구나” 하고 자동으로 동작

직렬 vs 병렬

• 병렬
  • jobs: 밑에 static-analysis 와 test 두 개가 따로 있으면, GitHub Actions는 두 job을 동시에 실행
    • 빠르지만, 한쪽에서 실패해도 다른 쪽은 계속 실행됨
• 직렬
  • 특정 job이 끝난 후 다음 job을 실행하려면 needs: 키워드를 써야 함

                      jobs:
                        static-analysis:
                          runs-on: ubuntu-22.04
                          steps:
                            - run: echo "정적 분석"

                        test:
                          runs-on: ubuntu-22.04
                          needs: static-analysis   # static-analysis 끝나야 test 실행
                          steps:
                            - run: echo "테스트 실행"

병렬 vs 직렬의 장단점

• 병렬

  • 장점
    • 여러 작업을 동시에 돌려서 전체 실행 시간이 줄어듦
    • 독립적인 job이면 효율적 (예: lint랑 테스트는 따로 돌아도 상관없음)
  • 단점
    • job 간 순서 제어 불가 (예: 빌드가 끝나야 배포 가능한 경우엔 병렬이면 안 됨)
    • 실패가 한꺼번에 나오니까 디버깅할 때 혼란스러울 수 있음

• 직렬

  • 장점
    • 단계별 파이프라인을 만들 수 있음 (예: 빌드 → 테스트 → 배포)
    • 앞 단계가 실패하면 뒤는 실행 안 하므로 문제 추적이 명확
  • 단점
    • 순차 실행이라 시간이 오래 걸림
    • 독립 작업도 기다려야 해서 비효율적일 수 있음

• 정적 분석과 테스트 실행이 서로 의존하지 않으면 병렬이 좋음

• 정적 분석이 통과해야만 테스트를 돌리겠다면 직렬이 좋음

---