🐢꾸준함의 미학

그룹프로젝트_2주차_마스터클래스

12 min read

소프트웨어 테스트

정량적인 코드의 품질을 위한 소프트웨어 테스트 아래 링크의 4가지 레벨이 일반적인 테스트 종류로 본다.

http://www.seguetech.com/the-four-levels-of-software-testing/

  • unit test : 소프트웨어의 최소단위, 보통 함수를 가리킴
  • Integration test : 단위 기능이 합쳐진 기능에 대한 테스트
  • System test : 위 내용보다 더 큰 개념, 전체 시스템에 대한 동작 테스트
  • Acceptance(인수) Test : 고객이 ok할 수 있는지 판단하기 위한 테스트 최근에 많이 쓰는 용어
  • UI 테스트 : FE에서 존재하는 개념으로, UI 기능 단위로 진행하는 테스트. 보통 Unit test와 system test 사이라고 볼 수 있음.
  • E2E Test: End-to-end 테스트. Integration Test와 비슷한 느낌 테스트를 하는 이유 → 유지보수의 측면에서 대비하기 위해 사용하는 테스트
  • 회귀 테스트(regretion test) : 이전에 돌렸던 코드가 마이그레이션 이후 잘 동작되는지 확인

리액트의 단위 테스트 → 컴포넌트 테스트 순수함수 → 어떠한 입력에 부수효과 없는 결과가 나오는지 확인하고 순수함수 형태로 만들어야 함 Test Runner → Jest, mocha 등. 확장자는 spec.ts, test.js 등으로 표현 한 순수 함수를 테스트하는 경우에는 정확한 결과가 나오는지만 보면 되지만 함수 안에 다른 함수를 호출하는 코드가 된다면 그 안에서 호출한 함수가 잘못되었을 수도 있음

  1. 최소 단위 함수부터 테스트
  2. 테스트 케이스 도출
  3. 테스트 가능한 함수로 리팩토링
  4. given → when → then 패턴
    • 일관된 방식의 테스트 코드 구현을 위해서 given(테스트에 필요한 값) → when(실행) → then(테스트)
  • 테스트코드 → 마이그레이션에 효과적
  • 소프트웨어의 의존성이 강해지면 나중에 테스트가 잘못될 수도 있기 떄문

워크플로

  • 조직에 맞는 워크플로를 하자

  • gitflow는 추천하기 어렵다

    • 필요하다면 커스텀해서 사용할 것

  • Bisect - 이진탐색으로 탐색

    • 어떤 커밋에서 버그가 발생하는지 빠르게 추적
    • 기본적인 사용 방법은 다음과 같습니다:
    1. 시작: git bisect start 명령으로 시작합니다.
    2. 범위 설정:
      • 버그가 없었던 마지막 좋은 커밋을 지정하기 위해 git bisect good <커밋 해시>를 입력합니다.
      • 버그가 발생한 나쁜 커밋을 지정하기 위해 git bisect bad <커밋 해시>를 입력합니다.
    3. 이진 검색 진행: 이후 Git은 중간 커밋을 체크아웃해줍니다. 문제가 발생했는지 확인한 후 git bisect good 또는 git bisect bad를 입력하면, Git은 다음 중간 커밋으로 이동해 점진적으로 범위를 좁혀갑니다.
    4. 결과 확인: 버그가 발생한 커밋을 찾으면 Git에서 해당 커밋 정보를 표시해주며, git bisect reset 명령으로 원래 브랜치 상태로 돌아갑니다.

Git Bisect는 특히 긴 커밋 히스토리에서 버그를 정확히 찾는 데 시간을 절약해주기 때문에, 디버깅 시 매우 효율적입니다.

What is GithubAction!

workflow를 자동화할 수 있도록 도와주는 도구 (ex. 빌드, 테스트 및 배포 파이프라인)

  • 레포지토리에서 PR이 열리거나 이슈 생성 등의 이벤트가 발생했을 떄 이를 트리거로 설정할 수 있다.
  • 순차 혹은 병렬로 실행될 수 있는 Job 하나 이상을 포함
  • 각각의 Job은 독립적인 가상 머신 Runner 혹은 Container 안에서 실행되고 스크립트를 실행하거나 Action을 실행하는 하나 이상의 Step으로 구성된다.
  • Action은 워크 플로우를 단순화할 수 있는 재사용 가능한 확장

What is Workflow!

  • 하나 이상의 Job을 실행하는 설정 가능한 자동화 프로세스
  • workflow는 레포지토리에 있는 YAML 파일로 정의
  • 레포지토리에서 이벤트가 발생할 때 수동으로 혹은 지정된 일정에 따라 트리거되어 실행됨
  • workflow는 ./github/workflows 에 정의
  • 하나의 레포지토리는 여러 workflow를 가질 수 있음
  • workflow는 다양한 작업 수행 가능
    • PR 빌드하고 테스트하기
    • 릴리즈 생성될 때마다 앱 배포
    • 새 이슈 열릴 때마다 레이블 추가

워크플로에 포함되어야 할 기본 구성요소

  1. 워크플로를 트리거하는 하나 이상의 이벤트.
  2. 하나 이상의 작업 → 하나 이상의 단계를 실행 ( Runner 머신에서 실행)
  3. 각 단계에서 워크플로를 간소화할 수 있는 재사용 가능한 확장인 작업을 정의하거나! 스크립트를 실행할 수 있다..

Workflow Event

트리거란 워크플로를 실행하게 하는 이벤트이다. 아래와 같은 트리거를 사용할 수 있다.

  • 푸시
  • 릴리스 생성
  • 이슈 열리는 경우
  • 예약된 시간
  • 수동

Job

  • 같은 Runner에서 실행되는 workflow의 단계(step)의 집합
  • 각 단계(step)는 실행되는 쉘 스크립트이거나 실행될 액션
  • 단계는 순서대로 실행되며 서로 의존 관계가 있음
  • 각 단계가 동일한 Runner에서 실행되므로 한 단계에서 다른 단계로 데이터를 공유할 수 있음
    • 먼저 앱 빌드 단계 실행 후 빌드된 앱을 테스트하는 단계 수행
  • Job은 다른 Job과의 의존성을 설정할 수 있으며 기본적으로 의존성이 없어 병렬 실행
  • Job이 다른 Job에 의존하게 설정하게 되면 그 Job이 완료될 때까지 기다린 후 실행된다.

Step

  • 정의된 순서대로 실행된다. (서로 종속된다)

Runner

  • event에 의해 workflow가 trigger 될 때 이를 실행하는 서버
  • 각 runner는 한 번에 하나의 Job을 실행할 수 있다.
  • GitHub은 workflow를 실행할 가상머신을 제공 (Ubuntu Linux, Microsoft Windows, MacOS)

Secret

  • API 키, 비밀 번호를 workflow에 사용하기 위해 secret를 활용할 수 있다.
    • Organization 수준의 secret을 사용하면 Organization 안의 여러 repository에서 이를 공유할 수 있다.
    • Repository 수준의 secret을 사용하면 해당 Repository 안에서 secret안의 변수를 사용할 수 있다.
  • Secret 이름 지정 규칙
    • 비밀 이름에는 영숫자 문자([a-z], [A-Z], [0-9]) 또는 밑줄(_)만 사용할 수 있습니다. 공백은 사용할 수 없습니다.
    • 비밀 이름은 GITHUB_ 접두사로 시작할 수 없습니다.
    • 비밀 이름은 숫자로 시작할 수 없습니다.
    • 이름은 대/소문자를 구분하지 않습니다.
    • 비밀 이름은 해당 수준에서 고유해야 합니다.

Workflow의 syntax

GitHub Actions에 대한 워크플로 구문 워크플로 실행 및 배포 관리

  • YAML 파일로 정의되어야 한다. (.yml, .yaml)
  • name
    • GitHub이 Action 탭에서 표시할 workflow의 이름
    • 생략할 경우 해당 yaml 파일의 경로를 표시한다.
  • run-name
  • on
    • workflow를 실행하기 위한 이벤트를 정의할 수 있다.

워크플로 템플릿 사용

깃허브에서 제공하는 템플릿이 존재 또는 커스텀으로 워크플로를 만들 수 있다. Github에서 코드를 분석하여 유용할 수 있는 워크플로 템플릿을 제공 해 준다. → 예를 들어 swift코드가 포함된 경우 swift프로젝트에 대한 제안이 표시된다. 템플릿은 빠르게 시작하고 실행할 수 있도록 설계되어 다음과 같은 다양한 구성을 제공

워크플로 템플릿을 시작으로 커스텀 워크플로를 빌드하거나 사용할 수도 있다.

모노레포

많은 프로젝트를 단일 레포지토리에서 관리하는 방식 애자일한 조직에서는 모노레포를 많이 채용

브랜치 → 커밋의 참조

merge와 rebase의 차이

동작이 다름 merge했을 때

  • fast-forward는 대부분 브랜치만 옮겨짐
    • 명령이 아닌, 별다른 할 일이 없어서 내 브랜치가 옮겨지고 커밋이 옮겨질 때
  • 3-way-merge
    • 베이스 커밋의 내용과 합쳐지는 브랜치, 합쳐질 브랜치를 모두 포괄하여 3-way-merge라고 함
  • rebase
    • 재배치
    • 커밋을 직렬로 바꿈
    • 커밋은 불변객체이기 때문에 다른 커밋으로 만듦
    • 내가 내 커밋을 들어 대상에게 옮기기

그래프 뷰

백링크