테스트 백과사전

문제 신고open_in_new 소스 보기open_in_new

테스트 실행 환경의 전체 사양

배경

Bazel 빌드 언어에는 여러 언어로 자동화된 테스트 프로그램을 정의하는 데 사용할 수 있는 규칙이 포함되어 있습니다.

테스트는 bazel test를 사용하여 실행됩니다.

사용자가 테스트 바이너리를 직접 실행할 수도 있습니다. 이러한 호출은 아래 설명된 의무 조항을 준수하지 않으므로 허용되지만 보장되지는 않습니다.

테스트는 밀폐되어야 합니다. 즉, 선언된 종속 항목이 있는 리소스에만 액세스해야 합니다. 테스트가 적절하게 밀폐되지 않으면 역사적으로 재현 가능한 결과를 제공하지 않습니다. 이는 문제의 원인(테스트를 중단한 변경사항 결정), 출시 엔지니어링 감사 가능성, 테스트의 리소스 격리와 관련된 중요한 문제가 될 수 있습니다. 일부 테스트에서는 통신이 발생하기 때문에 자동 테스트 프레임워크에서 서버를 배포하지 않아도 됩니다.

목표

이 페이지의 목표는 Bazel 테스트의 런타임 환경과 예상되는 동작을 공식적으로 설정하는 것입니다. 또한 테스트 실행기와 빌드 시스템에도 요구사항을 적용합니다.

테스트 환경 사양은 테스트 작성자가 지정되지 않은 동작에 의존하지 않도록 하여 테스트 인프라가 더 자유롭게 구현을 변경할 수 있도록 합니다. 이 사양은 밀폐, 확정적, 재진입이 아니더라도 현재 많은 테스트를 통과할 수 있도록 몇 가지 구멍을 강화합니다.

이 페이지는 표준 및 공신력 있는 정보를 제공하기 위한 것입니다. 이 사양과 테스트 실행기의 구현된 동작이 일치하지 않으면 사양이 우선합니다.

제안된 사양

키워드 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' 및 'OPTIONAL'은 IETF RFC 2119에 명시된 대로 해석되어야 합니다.

테스트 목적

Bazel 테스트의 목적은 저장소에 체크인된 소스 파일의 일부 속성을 확인하는 것입니다. 이 페이지의 '소스 파일'에는 테스트 데이터, 골든 출력, 버전 제어에 유지되는 기타 항목이 포함됩니다. 한 사용자는 유지관리할 것으로 예상되는 불변 항목을 어설션하는 테스트를 작성합니다. 다른 사용자는 나중에 테스트를 실행하여 불변이 손상되었는지 확인합니다. 밀폐되지 않은 소스 파일이 아닌 다른 변수에 테스트가 종속되는 경우 테스트의 통과가 중지될 때 이후 사용자는 변경사항의 결함을 확신할 수 없으므로 값이 감소합니다.

따라서 테스트 결과는 다음에만 의존해야 합니다.

• 테스트에 선언된 종속 항목이 있는 소스 파일
• 테스트에서 선언된 종속 항목이 있는 빌드 시스템의 제품
• 테스트 실행기가 동작을 일정하게 유지하는 것이 보장되는 리소스

현재 이러한 동작은 적용되지 않습니다. 그러나 테스트 실행기는 향후 이러한 시정 조치를 추가할 권리를 보유합니다.

빌드 시스템의 역할

테스트 규칙은 각각 실행 가능한 프로그램을 생성해야 한다는 점에서 바이너리 규칙과 유사합니다. 일부 언어의 경우 언어별 하네스와 테스트 코드를 결합하는 스텁 프로그램입니다. 테스트 규칙은 다른 출력도 생성해야 합니다. 기본 테스트 실행 파일 외에도 테스트 실행기에는 runfiles 매니페스트와 런타임 시 테스트에 사용할 수 있는 입력 파일이 필요하며 테스트 유형, 크기, 태그 관련 정보가 필요할 수 있습니다.

빌드 시스템은 runfile을 사용하여 데이터와 데이터를 함께 제공할 수 있습니다. 이는 동적 링크 사용 등을 통해 테스트 간에 파일을 공유하여 각 테스트 바이너리를 더 작게 만드는 최적화로 사용할 수 있습니다. 빌드 시스템은 생성된 실행 파일이 소스 또는 출력 트리의 절대 위치에 하드코딩된 참조 대신 테스트 실행기에서 제공한 runfiles 이미지를 통해 이러한 파일을 로드하도록 해야 합니다.

테스트 실행기의 역할

테스트 실행기의 관점에서 각 테스트는 execve()로 호출할 수 있는 프로그램입니다. 테스트를 실행하는 다른 방법이 있을 수 있습니다. 예를 들어 IDE를 통해 프로세스 내에서 자바 테스트를 실행할 수 있습니다. 그러나 테스트를 독립형 프로세스로 실행한 결과는 신뢰할 수 있는 이메일로 간주됩니다. 테스트 프로세스가 완료될 때까지 실행되고 종료 코드가 0인 정상적으로 정상적으로 종료되면 테스트가 통과됩니다. 다른 모든 결과는 테스트 실패로 간주됩니다. 특히 stdout에 PASS 또는 FAIL 문자열을 쓰는 것은 테스트 실행기에 중요하지 않습니다.

테스트를 실행하는 데 시간이 너무 오래 걸리거나 리소스 한도를 초과하거나 테스트 실행기가 금지된 동작을 감지하는 경우 테스트를 종료하고 테스트를 실패로 처리할 수 있습니다. 실행기는 테스트 프로세스 또는 그 하위 요소에 신호를 전송한 후 테스트를 통과한 것으로 보고해서는 안 됩니다.

개별 메서드나 테스트가 아닌 전체 테스트 대상에 완료될 때까지 제한된 시간이 주어집니다. 테스트 시간 제한은 다음 표에 따라 timeout 속성을 기반으로 합니다.

시간 초과	시간 제한 (초)
short	60
보통	300
long	900
영원	3600

시간 제한을 명시적으로 지정하지 않은 테스트에는 다음과 같이 테스트의 size에 기반한 암시적 시간 제한이 있습니다.

크기	암시적 제한 시간 라벨
small	short
중간	보통
대형	long
거대한	영원

명시적인 제한 시간 설정이 없는 '대형' 테스트는 900초에 할당됩니다. 제한 시간이 'short'인 '중간' 테스트에는 60초가 할당됩니다.

timeout와 달리 size는 일반 정의에 설명된 대로 로컬에서 테스트를 실행할 때 다른 리소스 (예: RAM)의 가정된 최대 사용량을 추가로 결정합니다.

size 및 timeout 라벨의 모든 조합은 합법적이므로 '대형' 테스트는 제한 시간이 'short'로 선언될 수 있습니다. 매우 끔찍한 일을 빠르게 할 겁니다.

테스트는 제한 시간에 관계없이 임의로 반환될 수 있습니다. 경고가 초과될 수 있지만 과도한 시간 초과로 인해 테스트에 불이익을 받지는 않습니다. 일반적으로 결함을 일으키지 않고 제한 시간을 최대한 가깝게 설정해야 합니다.

느리다고 알려진 조건에서 수동으로 실행할 경우 테스트 제한 시간은 --test_timeout 베젤 플래그로 재정의할 수 있습니다. --test_timeout 값은 초 단위입니다. 예를 들어 --test_timeout=120는 테스트 제한 시간을 2분으로 설정합니다.

다음과 같이 테스트 제한 시간에 권장되는 하한값도 있습니다.

시간 초과	최소 시간 (초)
short	0
보통	30
long	300
영원	900

예를 들어 '보통' 테스트가 5.5초 내에 완료되면 timeout = "short" 또는 size = "small"를 설정하는 것이 좋습니다. bazel --test_verbose_timeout_warnings 명령줄 옵션을 사용하면 지정된 크기가 너무 큰 테스트가 표시됩니다.

테스트 크기 및 제한 시간은 여기의 사양에 따라 BUILD 파일에 지정됩니다. 지정하지 않으면 테스트 크기가 기본적으로 'medium'으로 설정됩니다.

테스트의 기본 프로세스가 종료되지만 하위 요소 중 일부가 아직 실행 중인 경우 테스트 실행기는 실행을 완료된 것으로 간주하고 기본 프로세스에서 관찰된 종료 코드를 기반으로 성공 또는 실패로 집계해야 합니다. 테스트 실행기는 잘못된 프로세스를 종료할 수 있습니다. 테스트에서 이 방식으로 프로세스를 누출해서는 안 됩니다.

테스트 샤딩

테스트는 테스트 샤딩을 통해 병렬 처리할 수 있습니다. 테스트 샤딩을 사용 설정하려면 --test_sharding_strategy 및 shard_count를 참고하세요. 샤딩을 사용 설정하면 테스트 실행기가 샤드당 한 번씩 실행됩니다. 환경 변수 TEST_TOTAL_SHARDS는 샤드 수이고 TEST_SHARD_INDEX는 0부터 시작하는 샤드 색인입니다. 실행기는 이 정보를 사용하여 실행할 테스트를 선택합니다(예: 라운드 로빈 전략 사용). 일부 테스트 실행기는 샤딩을 지원하지 않습니다. 실행기에서 샤딩을 지원하는 경우 실행기는 TEST_SHARD_STATUS_FILE에서 지정된 파일의 마지막 수정일을 만들거나 업데이트해야 합니다. --incompatible_check_sharding_support가 사용 설정된 경우 샤딩되면 Bazel이 테스트에 실패합니다.

초기 조건

테스트를 실행할 때 테스트 실행기는 특정 초기 조건을 설정해야 합니다.

테스트 실행기는 argv[0]의 테스트 실행 파일 경로로 각 테스트를 호출해야 합니다. 이 경로는 상대적이며 테스트의 현재 디렉터리(runfiles 트리에 있음) 아래에 있어야 합니다. 테스트 실행기는 사용자가 명시적으로 요청하지 않는 한 다른 인수를 테스트에 전달해서는 안 됩니다.

초기 환경 블록은 다음과 같이 구성됩니다.

변수	가치	상태
HOME	$TEST_TMPDIR의 값	추천 커뮤니티
LANG	unset	필수
LANGUAGE	unset	필수
LC_ALL	unset	필수
LC_COLLATE	unset	필수
LC_CTYPE	unset	필수
LC_MESSAGES	unset	필수
LC_MONETARY	unset	필수
LC_NUMERIC	unset	필수
LC_TIME	unset	필수
LD_LIBRARY_PATH	공유 라이브러리가 포함된 콜론으로 구분된 디렉터리 목록	선택사항
JAVA_RUNFILES	$TEST_SRCDIR의 값	지원 중단됨
LOGNAME	$USER의 값	필수
PATH	/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.	권장
PWD	$TEST_SRCDIR/workspace-name	권장
SHLVL	2	추천 커뮤니티
TEST_INFRASTRUCTURE_FAILURE_FILE	쓰기 가능한 디렉터리의 비공개 파일에 대한 절대 경로입니다. 이 파일은 테스트의 불안정한 오류를 보고하는 일반적인 메커니즘이 아닌 테스트 인프라에서 발생한 오류를 보고하는 데만 사용해야 합니다. 이 컨텍스트에서 테스트 인프라는 테스트와 관련 없지만, 오작동으로 인해 테스트 실패가 발생할 수 있는 시스템 또는 라이브러리로 정의됩니다. 첫 번째 줄은 장애를 일으킨 테스트 인프라 구성요소의 이름이며 두 번째 줄은 실패를 사람이 읽을 수 있는 설명입니다. 추가 행은 무시됩니다.)	선택사항
TEST_LOGSPLITTER_OUTPUT_FILE	쓰기 가능한 디렉터리의 비공개 파일에 대한 절대 경로 (Logsplitter protobuffer 로그를 작성하는 데 사용됨)	선택사항
TEST_PREMATURE_EXIT_FILE	쓰기 가능한 디렉터리에 있는 비공개 파일의 절대 경로 (exit() 호출을 포착하는 데 사용됨)	선택사항
TEST_RANDOM_SEED	--runs_per_test 옵션을 사용하면 TEST_RANDOM_SEED는 각 테스트 실행마다 run number(1부터 시작)로 설정됩니다.	선택사항
TEST_RUN_NUMBER	--runs_per_test 옵션을 사용하면 TEST_RUN_NUMBER는 각 테스트 실행마다 run number(1부터 시작)로 설정됩니다.	선택사항
TEST_TARGET	테스트할 대상의 이름	선택사항
TEST_SIZE	테스트 size	선택사항
TEST_TIMEOUT	테스트 timeout(초)	선택사항
TEST_SHARD_INDEX	샤드 색인(sharding가 사용되는 경우)	선택사항
TEST_SHARD_STATUS_FILE	sharding 지원을 나타내기 위해 터치할 파일 경로	선택사항
TEST_SRCDIR	runfiles 트리의 기본 경로를 가리키는 절대 경로	필수
TEST_TOTAL_SHARDS	sharding가 사용되는 경우 총 shard count	선택사항
TEST_TMPDIR	비공개 쓰기 가능 디렉터리의 절대 경로	필수
TEST_WORKSPACE	로컬 저장소의 작업공간 이름	선택사항
TEST_UNDECLARED_OUTPUTS_DIR	선언되지 않은 테스트 출력을 작성하는 데 사용되는 비공개 쓰기 가능 디렉터리의 절대 경로입니다. TEST_UNDECLARED_OUTPUTS_DIR 디렉터리에 작성된 모든 파일은 압축되어 bazel-testlogs 아래의 outputs.zip 파일에 추가됩니다.	선택사항
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR	선언되지 않은 테스트 출력 주석 .part 및 .pb 파일을 작성하는 데 사용되는 비공개 쓰기 가능 디렉터리의 절대 경로입니다.	선택사항
TEST_WARNINGS_OUTPUT_FILE	쓰기 가능한 디렉터리의 비공개 파일에 대한 절대 경로 (테스트 타겟 경고를 작성하는 데 사용됨)	선택사항
TESTBRIDGE_TEST_ONLY	--test_filter 값(지정된 경우)	선택사항
TZ	UTC	필수
USER	getpwuid(getuid())->pw_name의 값	필수
XML_OUTPUT_FILE	테스트 작업이 테스트 결과 XML 출력 파일을 작성할 위치입니다. 그렇지 않으면 Bazel이 테스트 작업의 일부로 테스트 로그를 래핑하는 기본 XML 출력 파일을 생성합니다. XML 스키마는 JUnit 테스트 결과 스키마를 기반으로 합니다.	선택사항
BAZEL_TEST	테스트 실행 파일이 bazel test에 의해 구동되고 있음을 나타냅니다.	필수

환경에는 추가 항목이 포함될 수 있습니다. 테스트는 위에 나열되지 않은 환경 변수의 존재, 부재 또는 값에 의존해서는 안 됩니다.

초기 작업 디렉터리는 $TEST_SRCDIR/$TEST_WORKSPACE여야 합니다.

현재 프로세스 ID, 프로세스 그룹 ID, 세션 ID, 상위 프로세스 ID가 지정되지 않았습니다. 이 프로세스는 프로세스 그룹 리더 또는 세션 리더일 수도 있고 아닐 수도 있습니다. 프로세스에 제어 터미널이 있을 수도 있고 없을 수도 있습니다. 프로세스에 실행 중이거나 처리되지 않은 하위 프로세스가 0개 이상 있을 수 있습니다. 테스트 코드가 제어권을 획득할 때 프로세스에는 스레드가 여러 개 있어서는 안 됩니다.

파일 설명자 0 (stdin)은 읽기를 위해 열려 있어야 하지만 연결된 항목이 지정되지 않았습니다. 여기에서 테스트는 읽어서는 안 됩니다. 파일 설명자 1 (stdout)과 2(stderr)는 쓰기 작업을 위해 열려 있지만 연결된 파일은 지정되지 않았습니다. 터미널, 파이프, 일반 파일 또는 그 밖에 문자가 작성될 수 있는 모든 것일 수 있습니다. 열린 파일 테이블의 항목을 공유할 수도 있습니다. 즉, 독립적으로 탐색할 수 없습니다. 테스트는 다른 열린 파일 설명자를 상속해서는 안 됩니다.

초기 umask는 022 또는 027이어야 합니다.

대기 중인 알람 또는 간격 타이머가 없습니다.

차단된 신호의 초기 마스크는 비어 있습니다. 모든 신호는 기본 작업으로 설정됩니다.

소프트 및 하드 등 초기 리소스 한도는 다음과 같이 설정해야 합니다.

리소스	한도
RLIMIT_AS	unlimited
RLIMIT_CORE	미지정
RLIMIT_CPU	unlimited
RLIMIT_DATA	unlimited
RLIMIT_FSIZE	unlimited
RLIMIT_LOCKS	unlimited
RLIMIT_MEMLOCK	unlimited
RLIMIT_MSGQUEUE	미지정
RLIMIT_NICE	미지정
RLIMIT_NOFILE	최소 1,024
RLIMIT_NPROC	미지정
RLIMIT_RSS	unlimited
RLIMIT_RTPRIO	미지정
RLIMIT_SIGPENDING	미지정
RLIMIT_STACK	무제한 또는 2044KB <= rlim <= 8192KB

초기 처리 시간 (times()에서 반환) 및 리소스 사용률(getrusage()에서 반환)은 지정되지 않습니다.

초기 예약 정책 및 우선순위가 지정되지 않았습니다.

호스트 시스템의 역할

테스트 실행기가 직접 제어하는 사용자 컨텍스트의 측면 외에도, 테스트가 실행되는 운영체제가 테스트 실행이 유효하려면 특정 속성을 충족해야 합니다.

파일 시스템

테스트에서 관찰된 루트 디렉터리는 실제 루트 디렉터리일 수도 있고 아닐 수도 있습니다.

/proc가 마운트되어야 합니다.

모든 빌드 도구는 로컬 설치에서 사용되는 /usr 아래의 절대 경로에 있어야 합니다.

/home로 시작하는 경로를 사용하지 못할 수 있습니다. 테스트는 이러한 경로에 액세스해서는 안 됩니다.

/tmp는 쓰기 가능하지만, 이러한 경로는 사용하지 않아야 합니다.

테스트를 배타적으로 사용할 수 있는 상수 경로가 있다고 가정해서는 안 됩니다.

테스트는 마운트된 파일 시스템에 타임이 사용 설정되어 있다고 가정해서는 안 됩니다.

사용자 및 그룹

사용자 루트, 없음, unittest가 있어야 합니다. 그룹 루트, 없음, 엔지니어링이 존재해야 합니다.

테스트는 루트가 아닌 사용자로 실행되어야 합니다. 실제 사용자 ID와 유효 사용자 ID는 그룹 ID에서도 동일해야 합니다. 이 외에도 현재 사용자 ID, 그룹 ID, 사용자 이름, 그룹 이름이 지정되지 않습니다. 추가 그룹 ID 집합은 지정되지 않습니다.

현재 사용자 ID와 그룹 ID에는 getpwuid() 및 getgrgid()로 검색할 수 있는 해당 이름이 있어야 합니다. 보조 그룹 ID의 경우도 마찬가지입니다.

현재 사용자에게는 홈 디렉터리가 있어야 합니다. 쓰기가 불가능할 수 있습니다. 테스트는 여기에 쓰려고 해서는 안 됩니다.

네트워킹

호스트 이름이 지정되지 않았습니다. 점이 포함될 수도 있고 포함되지 않을 수도 있습니다. 호스트 이름을 확인하려면 현재 호스트의 IP 주소를 제공해야 합니다. 첫 번째 점 이후에 잘린 호스트 이름도 확인되어야 합니다. 호스트 이름 localhost는 확인되어야 합니다.

기타 자료

테스트에는 하나 이상의 CPU 코어가 부여됩니다. 다른 유형도 사용할 수 있지만 보장되지는 않습니다. 이 코어의 다른 성능 측면은 지정되지 않습니다. 테스트 규칙에 'cpu:n' 태그(n은 양수)를 추가하여 더 많은 CPU 코어로 예약을 늘릴 수 있습니다. 머신의 총 CPU 코어 수가 요청한 것보다 적은 경우에도 Bazel은 테스트를 실행합니다. 테스트에서 샤딩을 사용하는 경우 각 개별 샤드는 여기에 지정된 CPU 코어 수를 예약합니다.

테스트에서 하위 프로세스를 만들 수 있지만 프로세스 그룹 또는 세션은 만들 수 없습니다.

테스트에서 사용할 수 있는 입력 파일 수에는 제한이 있습니다. 이 한도는 변경될 수 있지만 현재 수만 개의 입력 범위 내에 있습니다.

시간 및 날짜

현재 시간과 날짜가 지정되지 않았습니다. 시스템 시간대가 지정되지 않았습니다.

X Windows를 사용할 수도 있고 사용하지 못할 수도 있습니다. X 서버가 필요한 테스트는 Xvfb를 시작해야 합니다.

파일 시스템과의 상호작용 테스트

달리 지정되지 않는 한, 테스트 환경 변수에 지정된 모든 파일 경로는 로컬 파일 시스템의 어딘가를 가리킵니다.

테스트는 $TEST_TMPDIR 및 $TEST_UNDECLARED_OUTPUTS_DIR (설정된 경우)에 의해 지정된 디렉터리 내에서만 파일을 만들어야 합니다.

이 디렉터리는 처음에는 비어 있습니다.

테스트에서 이러한 디렉터리를 삭제, chmod 또는 달리 변경하려고 해서는 안 됩니다.

이러한 디렉터리는 심볼릭 링크일 수 있습니다.

$TEST_TMPDIR/.의 파일 시스템 유형이 지정되지 않았습니다.

또한 테스트는 $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR에 .part 파일을 작성하여 선언되지 않은 출력 파일에 주석을 달 수 있습니다.

드물지만 테스트에서 /tmp에 파일을 만들어야 할 수 있습니다. 예를 들어 UNIX 도메인 소켓의 경로 길이 제한에는 일반적으로 /tmp 아래에 소켓을 만들어야 합니다. Bazel은 이러한 파일을 추적할 수 없습니다. 테스트 자체는 밀폐되어 있어야 하며 고유 경로를 사용하여 다른 동시 실행 테스트 및 비테스트 프로세스와의 충돌을 방지하고 /tmp에서 생성한 파일을 정리해야 합니다.

JUnit4 TemporaryFolder 또는 Go TempDir와 같은 일부 인기 테스트 프레임워크에는 /tmp 아래에 임시 디렉터리를 만드는 고유한 방법이 있습니다. 이러한 테스트 프레임워크에는 /tmp에서 파일을 정리하는 기능이 포함되어 있으므로 TEST_TMPDIR 외부에서 파일을 만드는 경우에도 사용할 수 있습니다.

테스트는 runfiles 메커니즘 또는 입력 파일을 사용할 수 있도록 특별히 지정된 실행 환경의 다른 부분을 통해 입력에 액세스해야 합니다.

테스트는 자체 실행 파일의 위치에서 추론된 경로에서 빌드 시스템의 다른 출력에 액세스해서는 안 됩니다.

runfiles 트리에 일반 파일, 심볼릭 링크, 혼합이 포함되어 있는지는 지정되지 않습니다. runfiles 트리에 디렉터리에 대한 심볼릭 링크가 포함될 수 있습니다. 테스트는 runfiles 트리 내에 .. 구성요소가 포함된 경로를 사용하지 않아야 합니다.

runfiles 트리 내의 심볼릭 링크 (심볼릭 링크를 통과하는 경로 포함)에 쓰기 작업을 할 수 없어야 합니다. 초기 작업 디렉터리에 쓰기가 불가능해야 합니다. 테스트는 실행 파일의 일부가 쓰기 가능하거나 현재 사용자가 소유하고 있다고 가정해서는 안 됩니다 (예: chmod 및 chgrp가 실패할 수 있음).

심볼릭 링크를 순회하는 경로를 포함한 runfiles 트리는 테스트 실행 중에 변경하면 안 됩니다. 상위 디렉터리와 파일 시스템 마운트는 runfiles 트리 내의 경로 확인 결과에 영향을 미치는 어떠한 방식으로도 변경되어서는 안 됩니다.

조기 종료를 포착하기 위해 테스트에서는 시작 시 TEST_PREMATURE_EXIT_FILE로 지정된 경로에 파일을 만들고 종료 시 삭제할 수 있습니다. 테스트가 완료될 때 Bazel에서 파일을 확인하면 테스트가 조기 종료되었다고 가정하고 실패로 표시합니다.

태그 규칙

테스트 규칙의 일부 태그는 특별한 의미를 갖습니다. tags 속성의 Bazel 빌드 백과사전도 참고하세요.

태그	의미
exclusive	다른 테스트를 동시에 실행하지 않음
external	테스트에 외부 종속 항목이 있습니다. 테스트 캐싱 사용 중지
large	test_suite 규칙, 대규모 테스트 모음
manual *	:..., :* 또는 :all와 같은 와일드 카드 타겟 패턴에 테스트 대상을 포함하지 마세요.
medium	test_suite 규칙, 중간 테스트 모음
small	test_suite 규칙, 소규모 테스트 모음
smoke	test_suite 규칙: 버전 제어 시스템에 코드 변경사항을 커밋하기 전에 실행해야 함을 의미합니다.

실행 파일

다음 예시에서는 //foo/bar:unittest라는 *_binary() 규칙이 있고 //deps/server:server라는 규칙에 런타임 종속 항목이 있다고 가정합니다.

위치

대상 //foo/bar:unittest의 runfiles 디렉터리는 $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles 디렉터리입니다. 이 경로를 runfiles_dir라고 합니다.

종속 항목

runfiles 디렉터리는 *_binary() 규칙의 컴파일 시간 종속 항목으로 선언됩니다. runfiles 디렉터리 자체는 *_binary() 규칙 또는 컴파일 시간이나 런타임 종속 항목에 영향을 미치는 BUILD 파일 집합에 종속됩니다. 소스 파일을 수정해도 runfiles 디렉터리의 구조에 영향을 미치지 않으므로 다시 빌드되지 않습니다.

목차

runfiles 디렉터리에는 다음이 포함됩니다.

• 런타임 종속 항목에 대한 심볼릭 링크: *_binary() 규칙의 런타임 종속 항목인 각 OutputFile 및 CommandRule은 runfiles 디렉터리에 있는 하나의 심볼릭 링크로 표현됩니다. 심볼릭 링크의 이름은 $(WORKSPACE)/package_name/rule_name입니다. 예를 들어 서버의 심볼릭 링크 이름은 $(WORKSPACE)/deps/server/server이고 전체 경로는 $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server입니다. 심볼릭 링크의 대상은 OutputFile 또는 CommandRule의 OutputFileName()이며, 절대 경로로 표현됩니다. 따라서 심볼릭 링크의 대상은 $(WORKSPACE)/linux-dbg/deps/server/42/server일 수 있습니다.
• 하위 실행 파일에 대한 심볼릭 링크: *_binary() C의 런타임 종속 항목인 모든 *_binary() Z의 경우 C의 runfiles 디렉터리에 Z의 실행 파일에 대한 두 번째 링크가 있습니다. 심볼릭 링크의 이름은 $(WORKSPACE)/package_name/rule_name.runfiles입니다. 심볼릭 링크의 대상은 runfiles 디렉터리입니다. 예를 들어 모든 하위 프로그램은 공통 runfiles 디렉터리를 공유합니다.