run-acceptance-tests

run-acceptance-tests 스킬 개요

이 스킬이 하는 일

run-acceptance-tests 스킬은 Terraform provider acceptance tests를 올바르게 실행하도록 도와줍니다. 특히 TestAcc 접두사로 시작하는 테스트를 다룰 때 유용합니다. 이 스킬은 Acceptance Testing의 run-acceptance-tests 워크플로우에 맞춰 설계되어 있어, 단순히 “테스트를 실행한다”가 아니라 올바른 환경에서 실행하고, 실패 원인을 해석하고, provider별 추가 설정이 필요한 시점을 판단하는 데 초점을 둡니다.

누가 사용하면 좋은가

Terraform provider를 작업 중이고, 로컬 검증이나 CI 문제 해결, 불안정한 결과 재현을 위한 실용적인 run-acceptance-tests 가이드가 필요하다면 이 스킬을 사용하세요. 이미 특정 acceptance test를 염두에 두고 있고, 플래그나 환경 변수를 추측하지 않고 신뢰할 수 있게 실행하는 방법이 필요할 때 특히 유용합니다.

무엇이 다른가

이 스킬은 중요한 실행 순서에 대해 분명한 기준을 갖고 있습니다. 먼저 go test -run=...처럼 범위를 좁힌 뒤, 첫 실행만으로 충분하지 않을 때에만 -count=1, -v, TF_LOG=debug, 그리고 workspace persistence를 추가합니다. 덕분에 run-acceptance-tests 스킬은, 즉흥적으로 해보라고 하는 일반적인 프롬프트보다 훨씬 낫습니다. 진단용 단계가 이미 정리되어 있기 때문입니다.

run-acceptance-tests 스킬 사용 방법

스킬 설치하기

다음 명령으로 run-acceptance-tests 스킬을 설치하세요:
npx skills add hashicorp/agent-skills --skill run-acceptance-tests

Terraform provider 워크플로우에서 run-acceptance-tests 설치를 검토 중이라면, 먼저 Go 테스트를 실행할 수 있는 환경인지와 필요할 때 provider credentials를 안전하게 설정할 수 있는지 확인하세요. 이 스킬은 독립적인 데모 프로젝트가 아니라 acceptance-testing 환경을 전제로 합니다.

정확한 테스트 대상을 알려 주세요

가장 좋은 입력은 “provider tests를 확인해줘” 같은 막연한 요청이 아니라, 구체적인 TestAcc 이름입니다. 예를 들어 “TestAccFeatureHappyPath를 실행하고 누락된 env vars가 있으면 진단해줘”처럼 요청하세요. 대상 테스트 이름, provider, 기대 동작이 명확할수록 이 스킬은 더 잘 작동합니다.

먼저 확인할 파일과 신호

먼저 SKILL.md를 읽고, 저장소의 README.md, AGENTS.md, metadata.json, 그리고 있으면 rules/, resources/, references/, scripts/ 폴더도 살펴보세요. 이 저장소에서는 핵심 안내가 SKILL.md에 집중되어 있어서, 대형 스킬보다 파일 트리 탐색의 비중은 낮지만, 숨은 도우미 파일이 없는지 확인하는 일은 여전히 유용합니다.

실행과 디버깅은 단계적으로 진행하세요

일반적인 실행은 TF_ACC=1 go test -run=TestAccFeatureHappyPath로 시작하고, 처음에는 출력을 verbose하게 만들지 마세요. 테스트가 실패하면 캐시된 결과를 피하기 위해 -count=1로 다시 시도하고, 그다음 -v, 그다음 TF_LOG=debug를 추가하세요. 그리고 나서야 단계 사이의 Terraform state를 살펴보기 위해 TF_ACC_WORKING_DIR_PERSIST=1을 고려하면 됩니다. 이 단계적 워크플로우가 run-acceptance-tests 사용 방식의 핵심입니다.

run-acceptance-tests 스킬 FAQ

이것은 Terraform provider acceptance tests에만 해당되나요?

네. run-acceptance-tests 스킬은 Terraform provider acceptance testing, 특히 TestAcc 명명 규칙을 따르는 Go 테스트에 범위가 맞춰져 있습니다. unit test나 일반적인 Go test suite, 또는 다른 인프라 점검용으로는 사용하지 않습니다.

테스트에 추가 환경 변수가 필요하면 어떻게 하나요?

그건 정상입니다. 이 스킬은 일부 provider가 추가 환경 변수를 필요로 할 수 있다는 점을 전제로 하며, 테스트 출력에서 누락된 변수를 찾아 안전하게 설정하라고 안내합니다. credentials나 endpoints가 없다면, 그것은 run-acceptance-tests 가이드의 일부로 다뤄야지 스킬의 문제로 볼 일은 아닙니다.

일반 프롬프트 대신 이 스킬이 꼭 필요한가요?

반복 가능한 절차가 필요할 때 이 스킬을 사용하세요. 일반 프롬프트는 “테스트를 실행해라” 정도만 알려줄 수 있지만, run-acceptance-tests 스킬은 첫 시도가 실패했을 때나 통과했더라도 검증이 더 필요할 때 어떤 플래그, 환경 변수, 단계적 에스컬레이션을 써야 하는지까지 알려줍니다.

초보자도 쓰기 쉬운가요?

Go 명령을 실행할 수 있고 기본적인 환경 변수를 이해한다면 그렇습니다. 이 스킬은 집중된 명령과 명확한 디버그 에스컬레이션부터 시작해 초보자의 시행착오를 줄여 줍니다. 다만 provider별 credentials, Terraform 동작, 테스트 명명 규칙은 여전히 이해하고 있어야 합니다.

run-acceptance-tests 스킬 개선 방법

테스트 맥락을 더 구체적으로 제공하세요

가장 유용한 입력은 정확한 테스트 이름, provider 패키지, 그리고 재현하려는 증상입니다. “acceptance tests를 실행해줘”는 너무 넓습니다. “internal/provider 패키지에서 TestAccResourceBasic를 실행하고 누락된 TF_LOG 단서를 조사해줘”처럼 주면 스킬이 더 빨리 올바른 경로를 고를 수 있습니다.

실패 상태만 말하지 말고 실패 내용을 함께 공유하세요

첫 실행이 실패했다면 전체 테스트 출력, 누락된 변수 메시지, 그리고 -count=1이나 -v를 적용한 뒤 결과가 달라졌는지도 함께 알려 주세요. run-acceptance-tests 스킬은 실제 실패 형태를 받아야 더 좋아집니다. provider acceptance tests는 인증 문제, 원격 API 준비 상태, state drift, 테스트 불안정성 등 서로 다른 이유로 실패하는 경우가 많기 때문입니다.

디버그 옵션은 올바른 순서로 사용하세요

처음에는 꼭 필요한 최소한의 에스컬레이션만 요청하고, 증거가 요구할 때만 범위를 넓히세요. run-acceptance-tests 사용에서는 보통 하나의 집중된 TestAcc 이름으로 시작한 뒤, 필요한 것을 확인할 수 있을 때만 verbose output, debug logs, workspace persistence를 추가하는 방식이 가장 좋습니다.

명령만 반복하지 말고 테스트 자체를 조정하세요

통과한 테스트가 정말 의미 있는지 확인해야 한다면, 같은 명령만 되풀이하지 말고 체크 한 개나 단계 한 개를 바꾼 뒤 다시 실행하세요. 이렇게 해야 run-acceptance-tests 스킬이 Acceptance Testing에서 더 유용해집니다. 진짜 통과와 우연한 음성을 구분하는 데 도움이 되고, 시간이 지나면서 테스트의 신호도 더 정교해집니다.