자동화된 테스트는 일반적으로 스크립트를 수동으로 실행하거나 테스트 실행기라고 하는 테스트 프레임워크의 도우미를 사용하여 테스트를 찾고 실행하는 방식으로 실행할 수 있습니다. 하지만 항상 스크립트를 수동으로 실행해야 하는 것은 아닙니다. 개발 수명 주기의 여러 지점에서 의견을 제공하고 신뢰도를 높일 수 있는 테스트 실행 방법에는 여러 가지가 있습니다.
기본 요건 스크립트
일반적으로 웹 프로젝트에는 npm, pnpm, Bun 또는 유사한 방식으로 설정되는 구성 파일(package.json 파일)이 있습니다. 이 구성 파일에는 프로젝트의 종속 항목 및 기타 정보와 도우미 스크립트가 포함됩니다. 이러한 도우미 스크립트에는 프로젝트를 빌드, 실행 또는 테스트하는 방법이 포함될 수 있습니다.
package.json 내에서 테스트 실행 방법을 설명하는 test라는 스크립트를 추가해야 합니다. npm이나 이와 유사한 도구를 사용할 때 'test' 스크립트가 특별한 의미가 있기 때문에 이 작업이 중요합니다.
이 스크립트는 node tests.js와 같은 예외를 발생시키는 단일 파일을 가리킬 수 있지만 설정된 테스트 실행기를 가리키는 데 사용하는 것이 좋습니다.
Vitest를 테스트 실행기로 사용하는 경우 package.json 파일은 다음과 같습니다.
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
이 파일로 npm test를 실행하면 Vitest의 기본 테스트 세트가 한 번 실행됩니다. Vitest에서 기본값은 '.test.js'로 끝나는 모든 파일을 찾아 실행하는 것이 또는 이와 비슷합니다. 선택한 테스트 실행기에 따라 명령어가 약간 다를 수 있습니다.
이 과정 전반에서 예를 들어 점점 인기를 얻고 있는 테스트 프레임워크인 Vitest를 사용하기로 했습니다. 이 결정에 관한 자세한 내용은 테스트 실행기로서의 Vitest를 참고하세요. 그러나 테스트 프레임워크와 실행기는 물론, 심지어는 언어에 상관없이 공통의 언어를 사용하는 경향이 있다는 점을 기억해야 합니다.
수동 테스트 호출
자동화된 테스트를 수동으로 트리거하는 방법 (예: 이전 예에서 npm test 사용)은 코드베이스를 적극적으로 사용하는 동안 실용적일 수 있습니다.
기능을 개발하는 동안 기능 테스트를 작성하면 기능이 작동하는 방식을 파악할 수 있습니다. 이는 테스트 기반 개발 (TDD)의 개념을 다룹니다.
테스트 실행기에는 일반적으로 테스트 일부 또는 전체를 실행하기 위해 호출할 수 있는 짧은 명령어와 테스트를 저장할 때 테스트를 재실행하는 감시자 모드가 있을 수 있습니다. 이러한 옵션은 모두 새 기능을 개발할 때 유용한 옵션이며 빠른 피드백을 통해 새 기능, 테스트 또는 둘 다를 쉽게 작성할 수 있도록 설계되었습니다. 예를 들어 Vitest는 기본적으로 감시자 모드에서 작동합니다. vitest 명령어는 변경사항을 감시하고 발견된 테스트를 다시 실행합니다. 테스트를 작성하는 동안 다른 창에 이 창을 열어두는 것이 좋습니다. 그래야 개발 중에 테스트에 관한 의견을 빠르게 얻을 수 있습니다.
일부 실행기를 사용하면 코드에서 테스트를 only로 표시할 수도 있습니다. 코드에 only 테스트가 포함되어 있으면 테스트를 실행할 때 이러한 테스트만 트리거되므로 테스트 개발을 더 빠르고 쉽게 해결할 수 있습니다. 모든 테스트가 빠르게 완료되더라도 only를 사용하면 오버헤드를 줄이고 작업 중인 기능이나 테스트와 관련 없는 테스트 실행으로 인한 혼란을 없앨 수 있습니다.
소규모 프로젝트, 특히 개발자가 한 명인 프로젝트의 경우 코드베이스의 전체 테스트 모음을 정기적으로 실행하는 습관을 기르는 것이 좋습니다. 이는 테스트가 작고 모든 테스트에 몇 초 이내에 신속하게 완료되는 경우에 유용하므로 계속하기 전에 모든 것이 제대로 작동하는지 확인할 수 있습니다.
사전 제출 또는 검토의 일부로 테스트 실행
많은 프로젝트에서 코드를 main 브랜치로 다시 병합할 때 코드베이스가 올바르게 작동하는지 확인합니다. 처음 테스트를 시작했지만 이전에 오픈소스 프로젝트에 참여한 적이 있다면 pull 요청 (PR) 프로세스의 일부가 프로젝트의 모든 테스트를 통과했음을 확인했을 수 있습니다. 즉, 새로운 기여가 기존 프로젝트에 부정적인 영향을 미치지 않았음을 의미합니다.
로컬에서 테스트를 실행하는 경우 프로젝트의 온라인 저장소 (예: GitHub 또는 다른 코드 호스팅 서비스)는 테스트가 통과하는지 알 수 없으므로 사전 제출 작업으로 테스트를 실행하면 모든 것이 제대로 작동하고 있음을 모든 기여자에게 명확하게 알 수 있습니다.
예를 들어 GitHub에서는 이를 GitHub 작업을 통해 추가할 수 있는 '상태 확인'이라고 합니다. GitHub 작업은 기본적으로 일종의 테스트입니다. 작업이 통과하려면 각 단계가 성공해야 합니다 (실패하거나 Error이 발생하지 않음). 프로젝트의 모든 PR에 작업을 적용할 수 있으며, 프로젝트에서는 코드를 제공하기 전에 작업을 통과하도록 요구할 수 있습니다. GitHub의 기본 Node.js 작업은 npm test를 단계 중 하나로 실행합니다.
이 테스트 접근 방식은 테스트를 성공적으로 실행하지 않는 코드를 허용하지 않음으로써 코드베이스가 항상 '그린' 상태인지 확인합니다.
지속적 통합의 일부로 테스트 실행
그린 PR이 승인되면 대부분의 코드베이스가 이전 PR이 아닌 프로젝트의 main 브랜치를 기반으로 테스트를 다시 실행합니다. 이 작업은 즉시 또는 정기적으로 (예: 시간별 또는 야간) 발생할 수 있습니다. 이러한 결과는 전반적인 프로젝트 상태를 보여주는 지속적 통합 (CI) 대시보드의 일부로 표시되는 경우가 많습니다.
이 CI 단계는 특히 코드베이스가 작은 프로젝트에서 중복되어 보일 수 있습니다. 즉, 검토 중에 테스트가 통과되므로 변경사항이 적용되면 통과해야 합니다. 하지만 항상 그런 것은 아닙니다. 녹색 결과가 성공적으로 생성된 후에도 테스트가 갑자기 실패할 수 있습니다. 여기에는 다음과 같은 이유가 있습니다.
- 여러 변경사항이 '한 번에' 허용(경합 상태라고도 함)되었으며 테스트되지 않은 미묘한 방식으로 서로 영향을 미칩니다.
- 테스트를 재현할 수 없거나 '불안정한' 코드를 테스트합니다. 즉, 코드 변경 없이 통과할 수도 있고 실패할 수도 있습니다.
- 코드베이스 외부의 시스템을 사용하는 경우 이러한 문제가 발생할 수 있습니다. 프록시의 경우
Math.random() > 0.05테스트라고 가정해 보겠습니다. 이 경우 확률 5%가 무작위로 실패합니다.
- 코드베이스 외부의 시스템을 사용하는 경우 이러한 문제가 발생할 수 있습니다. 프록시의 경우
- 엔드 투 엔드 테스트 (자세한 내용은 자동 테스트 유형 참고)와 같이 일부 테스트는 모든 PR에서 실행하기에는 너무 비용이 많이 들거나 비용이 많이 들며, 시간이 지나면서 항상 알림 없이 중단될 수 있습니다.
이러한 모든 문제를 극복할 수 있는 것은 없지만 일반적으로 테스트와 소프트웨어 개발이 결코 정확하게 과학이 될 수는 없다는 점을 인지해야 합니다.
롤백의 막간
테스트가 지속적 통합의 일부로 실행되고 상태 확인의 일부로 실행되는 경우에도 빌드가 '빨간색' 상태로 남거나 테스트가 실패함을 의미하는 또 다른 상태가 될 수 있습니다. 앞서 언급했듯이 이 문제는 테스트 제출 시의 경합 상태 또는 불안정한 테스트 등 여러 가지 이유로 발생할 수 있습니다.
소규모 프로젝트는 위기 상황으로 간주할 수도 있습니다. 모든 것을 중지하고, 문제가 되는 변경사항을 롤백하거나 되돌린 후 알려진 정상 상태로 되돌립니다. 이는 유효한 접근 방식이 될 수 있지만 테스트 (및 일반적으로 소프트웨어)는 그 자체가 목표가 아니라 목적을 향한 수단이라는 점을 기억해야 합니다. 목표는 모든 테스트를 통과하는 것이 아니라 소프트웨어를 작성하는 것입니다. 대신 실패한 테스트를 수정하는 다른 변경을 통해 브레이킹 체인지의 후속 조치를 통해 롤포워드할 수 있습니다.
반면에 영구적으로 손상된 상태로 존재하는 대규모 프로젝트를 보거나 작업한 적이 있을 것입니다. 더 심각한 문제는 이 대규모 프로젝트에는 개발자가 알람 피로를 유발할 만큼 자주 중단되는 불안정한 테스트가 있습니다. 이는 리더가 해결해야 할 실존적 문제입니다. 이러한 테스트는 '개발에 방해가 되는' 것으로 보이기 때문에 꺼져 있을 수도 있습니다.
이 문제에 대한 빠른 해결책은 없지만 더 자신 있게 작성 테스트 (업스킬링)를 하고 테스트 범위를 줄임 (단순화)하여 실패를 더 쉽게 식별할 수 있습니다. 구성요소 테스트 또는 통합 테스트의 수가 늘어나면 (자동 테스트 유형의 유형에 관해 자세히 설명됨) 유지하기 어렵고 한 번에 모든 것을 실행하려고 하는 하나의 대규모 엔드 투 엔드 테스트보다 더 큰 신뢰도를 얻을 수 있습니다.
자료
이해도 테스트
npm 및 유사 프로그램이 테스트 중에 찾는 특수 스크립트의 이름은 무엇인가요?