테스트가 실행되는 위치

자동 테스트는 일반적으로 스크립트를 수동으로 실행하거나 테스트 실행기라고 하는 테스트 프레임워크의 도우미를 사용하여 있습니다 하지만 스크립트를 항상 수동으로 실행해야 할 필요는 없습니다. 테스트를 실행하는 방법으로는 피드백을 제공하고 개발 수명 주기 동안 여러 시점에서 서로 다른 지점에 대한 신뢰도를 높일 수 있습니다.

기본 요건 스크립트

웹 프로젝트에는 일반적으로 구성 파일(package.json 파일)이 있습니다. npm, pnpm, Bun 등으로 설정할 수도 있습니다. 이 구성 파일에는 프로젝트의 종속 항목 및 기타 정보와 도우미 스크립트를 제공합니다. 이러한 도우미 스크립트에는 프로젝트를 빌드, 실행 또는 테스트하는 방법이 포함될 수 있습니다.

package.json 내에서 다음을 설명하는 test라는 스크립트를 추가해야 합니다. 알아보겠습니다. 이것이 중요한 이유는 npm이나 이와 유사한 "test" 스크립트는 특별한 의미가 있습니다. 이 스크립트는 예외가 발생하는 단일 파일을 가리킬 수 있습니다. URL을 node tests.js 테스트할 수 있습니다.

Vitest를 테스트 실행기로 사용하는 경우 package.json 파일은 다음과 같습니다.

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

이 파일로 npm test를 실행하면 Vitest의 기본 테스트 세트가 한 번 실행됩니다. 포함 Vitest는 기본적으로 '.test.js'로 끝나는 모든 파일을 찾습니다. 또는 유사하여 실행합니다. 사용 중인 명령어가 약간 다를 수 있습니다

Google은 더 인기 있는 테스트 프레임워크인 Vitest를 사용하여 예시를 살펴보겠습니다 자세한 내용은 테스트 실행기로 Vitest에서 이 결정을 내립니다. 그러나 테스트 프레임워크와 실행기는 공통의 모국어를 사용하는 경향이 있습니다.

수동 테스트 호출

자동화된 테스트를 수동으로 실행 (예: npm test 이러한 방식은 코드베이스 작업을 하는 동안 실용적일 수 있습니다. 기능 개발 과정에서 테스트를 작성하면 기능이 작동해야 하는 방식에 대한 감각을 키워야 합니다. 테스트 기반 개발 (TDD)

테스트 실행기에는 일반적으로 일부 또는 그리고 저장할 때 테스트를 재실행하는 감시자 모드도 필요할 수 있습니다. 있습니다. 이것들은 모두 새로운 기능을 개발할 때 유용한 옵션이며 새 기능이나 테스트 또는 둘 다를 쉽게 작성할 수 있도록 고안되었습니다. 빠르게 피드백을 받을 수 있습니다. 예를 들어 Vitest는 기본적으로 감시자 모드에서 작동합니다. vitest 명령어는 변경사항을 감시하고 찾은 테스트를 다시 실행합니다. 테스트를 작성하는 동안 이 창을 다른 창에서 열어두는 것이 좋습니다. 테스트를 개발하면서 테스트에 대한 빠른 피드백을 얻을 수 있습니다.

일부 실행기를 사용하면 코드에서 테스트를 only로 표시할 수도 있습니다. 코드가 only 테스트를 포함하는 경우 테스트를 실행할 때 이러한 테스트만 트리거됩니다. 테스트 개발의 속도 향상과 문제 해결이 쉬워집니다 모든 데이터가 테스트가 빠르게 완료되므로 only를 사용하면 오버헤드를 줄이고 방해받지 않도록 조심하세요.

소규모 프로젝트, 특히 개발자가 한 명만 있는 프로젝트의 경우 코드베이스의 전체 테스트 모음을 정기적으로 실행하는 습관을 들이는 것이 좋습니다. 이는 테스트가 소규모이고 신속하게 완료될 때 (테스트가 몇 초 이상 지속) 이 문제를 해결할 수 있습니다.

사전 제출 또는 검토의 일부로 테스트 실행

많은 프로젝트에서는 코드베이스가 올바르게 작동하는지 확인하기 위해 main 브랜치로 다시 병합되어야 합니다. 초보자이지만 오픈소스 프로젝트에 참여한 적이 없다면 풀 요청 (PR) 프로세스의 일부로 프로젝트의 모든 테스트가 새 기여가 귀하의 캠페인에 부정적인 영향을 주지 않았음을 의미합니다. 확인할 수 있습니다

로컬에서 테스트를 실행하면 프로젝트의 온라인 저장소 (예: GitHub 또는 다른 코드 호스팅 서비스)에서 테스트 통과 여부를 알지 못하는 경우 테스트를 사전 제출 작업으로 실행하면 모든 것이 잘 작동합니다.

예를 들어 GitHub에서는 이를 '상태 확인'이라고 합니다. 추가 가능한 GitHub 작업 GitHub 작업은 기본적으로는 일종의 테스트입니다. 각 단계는 성공해야 합니다 (실패하거나 Error)를 포함해야 합니다. 프로젝트의 모든 PR에 작업을 적용할 수 있습니다. 프로젝트에서 코드를 기여하기 전에 작업이 통과하도록 요구할 수 있습니다. GitHub 기본 Node.js 작업은 단계 중 하나로 npm test를 실행합니다.

</ph>

이 테스트 접근 방식은 코드베이스가 항상 '녹색'인지 확인하려고 시도합니다. 테스트를 실행하지 못하는 코드를 허용하지 않음을 의미합니다.

지속적 통합의 일부로 테스트 실행

녹색 PR이 승인되면 대부분의 코드베이스는 다음을 기반으로 다시 테스트를 실행합니다. 이전 PR이 아닌 프로젝트의 main 브랜치를 사용하세요. 발생할 수 있는 상황 즉시 또는 정기적으로 (예: 매시간 또는 야간) 이러한 결과는 종종 지속적 통합 (CI) 대시보드의 일부로 전반적인 프로젝트 상태를 보여줍니다

이 CI 단계는 중복처럼 보일 수 있으며, 특히 코드베이스가 작은 프로젝트에서는 더욱 그렇습니다. 테스트를 통과해야 하므로 변경사항이 있으면 통과해야 합니다. 하지만 항상 그렇지는 않습니다! 성공적으로 실행되었는데도 테스트가 갑자기 실패할 수 있습니다. 얻을 수 있습니다. 여기에는 다음과 같은 이유가 있습니다.

• 여러 변경사항이 '한 번에' 허용되었으며 이는 경합 상태라고도 하며 미묘하고 검증되지 않은 방식으로 서로 영향을 미칩니다
• 테스트를 재현할 수 없거나 '불안정'한 테스트를 테스트합니다. 둘 다 코드 변경 없이 실패합니다
  • 코드베이스 외부의 시스템을 사용하는 경우 이러한 상황이 발생할 수 있습니다. Math.random() > 0.05인지 테스트한다고 가정해 보겠습니다. 임의적으로 5%에서 실패합니다. 확인할 수 있습니다.
• 엔드 투 엔드와 같은 일부 테스트는 모든 PR에서 실행하기에는 너무 비싸거나 비용이 많이 듭니다. 테스트 (자동 테스트 유형에서 자세히 설명) 시간이 지나면서 항상 경고 없이 다운될 수 있습니다.

극복할 수 없는 문제는 없지만 소프트웨어 개발과 관련된 모든 개념이 정확한 것은 결코 제공합니다.

롤백 시의 중단

테스트가 지속적 통합의 일부로 실행되는 경우, 그리고 테스트가 상태 확인의 일부로 실행되는 경우 빌드가 '빨간색'으로 끝날 수 있습니다 또는 테스트가 실패하고 있음을 의미하는 다른 상태입니다. 앞서 언급했듯이 테스트에서의 경합 상태 등 여러 가지 이유로 발생할 수 있습니다. 불안정한 테스트가 있을 수 있습니다.

소규모 프로젝트의 경우 본능적으로 이를 위기로 취급할 수 있습니다. 중지 문제가 되는 변경사항을 롤백하거나 되돌리고 알려진 상태를 유지합니다. 이는 유효한 접근 방식일 수 있지만 테스트 (그리고 일반적으로 소프트웨어!)는 목적을 위한 수단일 뿐 있습니다. 목표는 모든 테스트를 통과하는 것이 아니라 소프트웨어를 작성하는 것일 수 있습니다. 대신 다른 변경사항으로 브레이킹 체인지의 후속 조치를 취하여 롤포워드할 수 있습니다. 수정할 수 있습니다

한편, Google Cloud 프로젝트에 존재하는 대규모 프로젝트를 고장난 상태로 있게 됩니다. 또는 대규모 프로젝트에는 불안정한 테스트가 알람 피로를 유발할 정도로 자주 고장남 살펴봤습니다 이는 리더가 해결해야 할 실존적 문제인 경우가 많습니다. '사용하는 데 방해가 되는 참조하세요.

이 문제를 빠르게 해결할 방법은 없지만, 더 자신 있게 글을 작성하는 데 도움이 될 수 있습니다. 테스트 (역량 강화), 테스트 범위 축소 (단순화)를 통해 장애를 더 쉽게 식별할 수 있습니다 구성요소 테스트의 수 증가 또는 통합 테스트 (유형은 자동화된 테스트 유형 테스트)을 사용하면 더 높은 신뢰도를 하나의 대규모 엔드 투 엔드 테스트보다 훨씬 효율적입니다. 할 수 있습니다.

리소스

• 야간 빌드의 이점

이해도 확인