테스트 백과사전

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

테스트 실행 환경의 포괄적인 사양.

배경

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

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

사용자는 테스트 바이너리를 직접 실행할 수도 있습니다. 허용되기는 하지만 권장하지는 않습니다 이러한 호출은 아래에 설명된 위임장을 준수하지 않는 것으로 간주됩니다.

테스트는 밀폐되어야 합니다. 즉, 해당 리소스에만 액세스할 수 있어야 합니다. 종속 항목이 선언되어 있습니다. 테스트가 제대로 밀폐되지 않은 경우 역사적으로 재현 가능한 결과를 제공하지 않습니다. 이는 범인 발견에 중대한 문제가 있는 경우 (어떤 변화가 테스트를 중단했는지 파악) 출시 엔지니어링 감사 가능성, 테스트 리소스 격리 (자동화 DDoS는 서버에 DDoS를 일으키지 않아야 합니다. 왜냐하면 일부 테스트는 합니다.

목표

이 페이지의 목표는 GKE 클러스터를 위한 런타임 환경을 Bazel 테스트의 예상 동작입니다. 또한 인코더-디코더 아키텍처를 빌드 시스템이 포함됩니다

테스트 환경 사양은 테스트 작성자가 불특정한 동작으로 인해 테스트 인프라가 구현을 변경하세요. 이 사양은 현재 밀폐가 제대로 되지 않더라도 많은 테스트를 통과할 수 있지만, 결정론적, 재진입이 있습니다

이 페이지는 표준적이고 신뢰할 수 있는 정보를 제공하는 데 목적이 있습니다. 만약 테스트 실행기의 구현 동작이 일치하지 않는 경우 사양이 우선 적용됩니다

제안 사양

키워드에는 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'OPTIONAL' 는 다음과 같이 해석됩니다. IETF RFC 2119에 설명되어 있습니다.

테스트 목적

Bazel 테스트의 목적은 소스 파일의 일부 속성을 확인하는 것입니다. 확인할 수 있습니다 (이 페이지에서 '소스 파일'에는 테스트 데이터, 골든 출력 및 버전 제어하에 유지되는 다른 모든 것은 가능합니다.) 한 사용자는 테스트를 통해 유지될 것으로 예상되는 불변값을 어설션합니다. 다른 사용자 나중에 테스트를 실행하여 불변 항목이 손상되었는지 확인합니다. 만약 테스트는 소스 파일 (비밀폐 아님) 이외의 변수에 종속되며, 그 값은 나중의 사용자는 자신의 변경사항에 문제가 있다는 것을 확신할 수 없으므로 테스트 통과가 중지될 때

따라서 테스트 결과는 다음에만 종속되어야 합니다.

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

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

빌드 시스템의 역할

테스트 규칙은 각각 실행 가능한 파일을 생성해야 한다는 점에서 바이너리 규칙과 유사합니다. 있습니다. 일부 언어의 경우 이 프로그램은 언어별 하네스를 테스트할 수 있습니다. 테스트 규칙은 확인할 수 있습니다 기본 테스트 실행 파일 외에도 사용할 수 있도록 제공되어야 하는 입력 파일인 runfiles의 매니페스트가 필요합니다. 테스트의 대상이 될 수 있으며 유형, 크기 및 테스트 태그입니다.

빌드 시스템은 실행 파일을 사용하여 코드와 데이터를 전달할 수 있습니다. 이 각 테스트 바이너리를 공유하여 각 테스트 바이너리를 작게 만드는 최적화로 테스트 간에 파일을 주고받을 수 있습니다. 빌드 시스템 생성된 실행 파일이 실행 파일을 통해 이러한 파일을 로드하도록 해야 합니다. 테스트 실행기에서 제공한 이미지(절대 참조에 대한 하드코딩이 아닌 위치를 지정할 수 있습니다

테스트 실행기 역할

테스트 실행기의 관점에서 볼 때 각 테스트는 execve()로 호출됩니다. 테스트를 실행하는 다른 방법이 있을 수 있습니다. 예를 들어 IDE는 프로세스 내에서 Java 테스트 실행을 허용할 수 있습니다. 그러나 테스트를 독립형 프로세스로 실행하는 것이 신뢰할 수 있는 것으로 간주되어야 합니다. 만약 테스트 프로세스가 완료될 때까지 실행되고 일반적으로 다음과 같은 종료 코드로 종료됩니다. 테스트가 통과된 것입니다. 다른 결과는 모두 테스트 실패로 간주됩니다. 포함 특히 PASS 또는 FAIL 문자열을 stdout에 작성하면 중요하다는 사실을 알 수 있습니다.

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

개별 메서드나 테스트가 아닌 전체 테스트 타겟에 시간이 얼마나 걸릴까요? 테스트 시간 제한은 timeout 속성 다음 표로 업데이트합니다.

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

제한 시간을 명시적으로 지정하지 않는 테스트는 테스트의 size를 다음과 같이 바꿉니다.

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

'대형' 명시적인 제한 시간 설정이 없는 테스트에 900이 할당됩니다. 초 단위로 실행할 수 있습니다 '매체' 'short'의 제한 시간으로 테스트 할당 될 60 초 단위입니다.

timeout와 달리 size는 다른 리소스 (예: RAM)와 같은 다른 리소스도 일반적인 정의.

size 및 timeout 라벨의 모든 조합은 합법적이므로 테스트 'short'의 시간 제한이 있는 것으로 선언될 수 있습니다. 그것은 정말로 끔찍한 일들을 빨리 감당할 수 있습니다.

테스트는 제한 시간과 관계없이 임의로 빠르게 반환될 수 있습니다. 테스트에 불이익이 주어지지 않음 경고가 표시될 수 있지만 시간 초과로 인해 일반적으로 제한 시간을 최대한 짧게 설정해도 문제가 발생하지 않습니다.

테스트 제한 시간은 다음과 같은 경우 --test_timeout bazel 플래그로 재정의할 수 있습니다. 수동으로 실행하는 데 사용할 수 있습니다. 이 --test_timeout 값은 초 단위입니다. 예: --test_timeout=120 테스트 제한 시간을 2분으로 설정합니다.

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

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

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

테스트 크기와 제한 시간은 자세한 내용은 여기를 참조하세요. 만약 지정되지 않은 경우 테스트 크기는 기본적으로 'medium'으로 설정됩니다.

테스트의 기본 프로세스는 종료되었지만 그 하위 요소 중 일부가 계속 실행 중인 경우 테스트 실행기는 실행이 완료된 것으로 간주하고 성공 또는 종료 코드를 기반으로 오류를 표시합니다 테스트 실행기 잘못된 프로세스를 종료할 수 있습니다 테스트는 이러한 방식으로 프로세스를 유출해서는 안 됩니다.

테스트 샤딩

테스트는 테스트 샤딩을 통해 병렬화될 수 있습니다. 자세한 내용은 --test_sharding_strategy 및 shard_count을(를) 출발하여 테스트 샤딩을 사용 설정합니다. 샤딩을 사용 설정하면 테스트 실행기가 한 번 실행됩니다. 샤드당 환경 변수 TEST_TOTAL_SHARDS 는 샤드 수이고 TEST_SHARD_INDEX는 샤드 수입니다. 샤드 색인으로, 0부터 시작합니다. 실행기는 이 정보를 사용하여 어떤 테스트를 실행할지 선택합니다. 예를 들어 라운드 로빈 전략을 사용할 수 있습니다. 일부 테스트 실행기는 샤딩에 사용될 수 있습니다. 실행기가 샤딩을 지원하는 경우 실행기는 마지막 파일의 수정된 날짜 TEST_SHARD_STATUS_FILE 그렇지 않고 --incompatible_check_sharding_support 사용 설정된 경우 Bazel이 샤딩된 경우 테스트에 실패합니다.

초기 조건

테스트 실행 시 테스트 실행기는 명확한 조건일 수 있습니다

테스트 실행기는 argv[0] 이 경로는 상대 경로여야 하며 테스트의 현재 디렉터리 아래에 위치해야 합니다. (실행 파일 트리에 있습니다. 아래를 참조하세요.) 테스트 실행기는 기타 인수를 테스트에 사용할 수 없습니다.

초기 환경 블록은 다음과 같이 구성되어야 합니다.

변수 값 상태
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 프로토버퍼 로그) 선택사항
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 실행 파일 트리의 기본 절대 경로 필수
TEST_TOTAL_SHARDS 합계 shard count님, sharding를 사용하는 경우 선택사항
TEST_TMPDIR 비공개 쓰기 가능한 디렉터리의 절대 경로 필수
TEST_WORKSPACE 로컬 저장소의 작업공간 이름 선택사항
TEST_UNDECLARED_OUTPUTS_DIR 쓰기 가능한 비공개 디렉터리의 절대 경로입니다 (선언되지 않은 파일을 작성하는 데 사용됨). 테스트 출력). 서버에 작성된 모든 파일은 TEST_UNDECLARED_OUTPUTS_DIR 디렉터리가 압축되고 다음 위치에 있는 outputs.zip 파일에 추가됨 bazel-testlogs입니다. 선택사항
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)은(는) 서면으로 작성할 수 있지만 첨부된 항목은 다음과 같습니다. 지정되지 않았습니다. 터미널, 파이프, 일반 파일 또는 그 외 다른 모든 것이 될 수 있습니다. 지정할 수 있습니다. 열려 있는 파일 테이블의 항목을 공유할 수 있습니다. (즉, 독립적으로 탐색할 수 없음) 테스트는 어떤 것도 상속해서는 안 됩니다. 다른 열린 파일 설명자에 적용됩니다.

초기 우마스크는 022 또는 027이어야 합니다.

알람 또는 인터벌 타이머는 보류 중이어서는 안 됩니다.

차단된 신호의 초기 마스크는 비어 있어야 합니다. 모든 신호는 기본 작업을 수행합니다

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

리소스 한도
RLIMIT_AS 무제한
RLIMIT_CORE 지정되지 않음
RLIMIT_CPU 무제한
RLIMIT_DATA 무제한
RLIMIT_FSIZE 무제한
RLIMIT_LOCKS 무제한
RLIMIT_MEMLOCK 무제한
RLIMIT_MSGQUEUE 지정되지 않음
RLIMIT_NICE 지정되지 않음
RLIMIT_NOFILE 최소 1024
RLIMIT_NPROC 지정되지 않음
RLIMIT_RSS 무제한
RLIMIT_RTPRIO 지정되지 않음
RLIMIT_SIGPENDING 지정되지 않음
RLIMIT_STACK 무제한 또는 2044KB <= rlim <= 8192KB

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

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

호스트 시스템의 역할

테스트에서 직접 제어하는 사용자 컨텍스트 외에도 실행기에 있는 경우, 테스트가 실행되는 운영 체제는 특정 요구 사항을 충족해야 합니다. 속성이 있어야 합니다.

파일 시스템

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

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

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

/home로 시작하는 경로는 사용하지 못할 수도 있습니다. 테스트는 않습니다.

/tmp는 쓰기 가능해야 하지만 테스트에서는 이러한 경로를 사용해서는 안 됩니다.

테스트는 배타적인 단일 경로에 특정 경로를 사용할 수 있다고 가정해서는 안 됩니다. 사용합니다

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

사용자 및 그룹

사용자 root, nobody, unittest가 있어야 합니다. 그룹 루트, nobody 및 eng이 있어야 합니다.

테스트는 루트가 아닌 사용자로 실행해야 합니다. 실제 유효한 사용자 ID는 같아야 합니다. 그룹 ID도 마찬가지입니다. 이 외에도 현재 사용자 ID, 그룹 ID, 사용자 이름 및 그룹 이름이 지정되지 않았습니다. 보조 그룹 ID 집합은 지정되지 않았습니다.

현재 사용자 ID와 그룹 ID에는 해당하는 이름이 있어야 합니다. getpwuid() 및 getgrgid()를 사용하여 가져옵니다. 또한 보조 그룹 ID입니다.

현재 사용자에게 홈 디렉터리가 있어야 합니다. 쓰기가 불가능할 수 있습니다. 테스트는 반드시 쓰려고 시도하지 않습니다

네트워킹

호스트 이름이 지정되지 않았습니다. 마침표를 포함할 수도 있고 포함하지 않을 수도 있습니다. 이러한 문제를 호스트 이름은 현재 호스트의 IP 주소를 제공해야 합니다. 호스트 이름 잘라내기 해결 도 작동해야 합니다. 호스트 이름 로컬 호스트가 확인되어야 합니다.

기타 리소스

테스트에는 1개 이상의 CPU 코어가 부여됩니다. 다른 도구도 사용 가능할 수 있지만 제공되지 않음 보장 이 코어의 다른 성능 측면은 지정되지 않았습니다. 다음을 수행할 수 있습니다. 태그를 추가하여 예약을 더 많은 CPU 코어로 늘릴 수 있습니다. &quot;cpu:n&quot; (여기서 n은 양수)를 테스트 규칙에 추가합니다. 머신이 더 적은 수의 총 CPU 코어 수보다 많기 때문에 Bazel은 계속 테스트를 실행합니다. 테스트가 샤딩: 각 개별 샤드는 CPU 수를 예약합니다. 코어 수를 기준으로 할 수 있습니다

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

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

시간 및 날짜

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

X Windows는 사용 가능할 수도, 제공되지 않을 수도 있습니다. X 서버가 필요한 테스트를 시작해야 함 Xvfb.

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

테스트 환경 변수에 지정된 모든 파일 경로는 로컬 파일 시스템에서 백업됩니다.

테스트는 $TEST_TMPDIR 및 $TEST_UNDECLARED_OUTPUTS_DIR (설정된 경우)

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

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

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

$TEST_TMPDIR/.의 파일 시스템 유형은 지정되지 않은 상태로 유지됩니다.

테스트는 .part 파일을 $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR: 선언되지 않은 출력 파일에 주석을 추가합니다.

드물지만 테스트가 /tmp에 파일을 만들어야 하는 경우도 있습니다. 예를 들어 Unix 도메인 소켓의 경로 길이 제한 일반적으로 /tmp 아래에 소켓을 만들어야 합니다. Bazel이 다음 작업을 할 수 없게 됩니다 해당 파일을 추적하는 행위 테스트 자체는 밀폐되도록 신경을 쓰고 고유한 동시에 실행 중인 테스트 및 비테스트와의 충돌을 피하기 위한 경로 /tmp에서 만든 파일을 정리하는 데 사용됩니다.

많이 사용되는 테스트 프레임워크(예: JUnit4 TemporaryFolder 또는 TempDir(으)로 이동, /tmp 아래에 임시 디렉터리를 만드는 자신만의 방법을 살펴봤습니다. 이러한 테스트는 프레임워크에는 /tmp의 파일을 정리하는 기능이 포함되어 있으므로 다음을 사용할 수 있습니다. 이는 TEST_TMPDIR 외부에 파일을 만드는 경우에도 마찬가지입니다.

테스트는 runfiles 메커니즘이나 입력 파일을 만들기 위한 용도인 실행 환경입니다. 있습니다.

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

실행 파일 트리에 기호화된 일반 파일이 포함되어 있는지 여부를 지정하지 않았습니다. 혼합된 형태일 수도 있습니다. 실행 파일 트리는 디렉터리에 대한 심볼릭 링크를 포함할 수 있습니다. 테스트는 실행 파일 내에 .. 구성요소가 포함된 경로를 사용하지 않아야 합니다. 있습니다.

실행 파일 트리 내에 디렉터리, 파일 또는 심볼릭 링크가 없어야 함 (실행 파일을 쓰기 가능해야 합니다. (초기 작업이 디렉터리에 쓰기가 가능하지 않아야 합니다.) 테스트에서 실험 과정의 어떤 부분도 runfiles가 쓰기 가능하거나 현재 사용자가 소유하고 있는 경우 (예: chmod 및 chgrp는 있습니다.

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

조기 종료를 포착하기 위해 테스트는 시작 시 TEST_PREMATURE_EXIT_FILE, 종료 시 삭제합니다. Bazel이 파일은 테스트가 너무 일찍 종료되었다고 가정하고 실패한 것으로 표시합니다.

태그 규칙

테스트 규칙의 일부 태그에는 특별한 의미가 있습니다. 자세한 내용은 tags 속성의 Bazel 빌드 백과사전

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

실행 파일

다음에서 *_binary() 규칙이 //foo/bar:unittest에는 라벨이 지정된 규칙에 대한 런타임 종속 항목이 있습니다. //deps/server:server입니다.

위치

대상 //foo/bar:unittest의 실행 파일 디렉터리는 다음과 같은 디렉터리입니다. $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles입니다. 이 경로를 runfiles_dir

종속 항목

runfiles 디렉터리는 *_binary() 규칙 실행 파일 디렉터리 자체는 BUILD 세트에 종속됨 *_binary() 규칙이나 컴파일 시간, 런타임에 영향을 미치는 파일 종속 항목이 포함됩니다 소스 파일을 수정해도 runfiles 디렉터리를 사용하여 재빌드를 트리거하지 않습니다.

목차

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

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