# Bazel ტესტების ინსაიტები {#bazel-test-insights}

> [!IMPORTANT]
> **მოთხოვნები**
>
> - Bazel-ის სამუშაო სივრცე, დაკავშირებული `tuist bazel setup`-ით, როგორც აღწერილია <.localized_link href="/guides/get-started/bazel-project">Bazel-ის პროექტის დაწყება</.localized_link>-ში.

`tuist bazel setup` აკონფიგურირებს თითოეული შემთხვევის შესახებ ანგარიშგებას `.bazelrc.tuist`-ში, ამიტომ ჩვეულებრივი `bazel test` აგზავნის ცალკეულ სატესტო შემთხვევებს იმავე დაშბორდებზე, რომლებსაც ყველა სხვა ბილდის სისტემა იყენებს:

```bash
bazel test //app:tests
```

<.localized_link href="/guides/features/test-insights/flaky-tests/bazel">კარანტინის</.localized_link> გამოყენებისთვის, გაუშვით ტესტები Tuist-ის გარსაცმის მეშვეობით. არგუმენტები `--`-ის შემდეგ გადაეცემა `bazel test`-ს:

```bash
tuist bazel test -- //app:tests
```

## რა ფიქსირდება {#what-is-tracked}

Tuist პარსავს `test.xml` ანგარიშებს და იღებს `test.log` გამოტანას, რომელსაც Bazel ქმნის თითოეული სატესტო მიზნისთვის, შემდეგ კი აერთიანებს მათ საერთო ტესტების გაშვების მოდელში. თითოეული გაშვება იწერს:

- ცალკეული სატესტო შემთხვევის წარმატების, შეცდომის და გამოტოვების სტატუსს, ხანგრძლივობასთან ერთად.
- სატესტო მიზნის, კლასის და საიტის სტრუქტურას.
- გამეორების მცდელობებს, როდესაც Bazel კონფიგურირებულია არასტაბილური ტესტების გამეორებისთვის.
- შეცდომის გამოტანას, აღებულს მიზნის `test.log`-დან.

**ტესტების გაშვებები**, **სატესტო შემთხვევები** და ცალკეული ტესტების გვერდები Bazel-ისთვის ისევე მუშაობს, როგორც სხვა ბილდის სისტემებისთვის.

## თითოეული შემთხვევის JUnit ანგარიშების გენერირება {#per-case-junit-reports}

თითოეული შემთხვევის სტრიქონები დამოკიდებულია იმაზე, რომ სატესტო მიზანი წერდეს JUnit `test.xml`-ს `$XML_OUTPUT_FILE` გზაზე, რომელსაც Bazel უზრუნველყოფს. როდესაც გამშვები არ წერს მას, Bazel იყენებს სინთეზურ ერთ-შემთხვევიან ანგარიშს, რომელიც სახელდება მიზნის მიხედვით, და Tuist აჩვენებს ერთ სტრიქონს თითოეული მიზნისთვის (მონიშნული როგორც **Bazel მიზანი** სატესტო შემთხვევების სიაში), სადაც ნედლი `test.log` კვლავ ხელმისაწვდომია გაშვების გვერდზე.

Bazel-ის უმეტესი სატესტო წესები უკვე ქმნიან რეალურ `test.xml`-ს:

- `java_test` და `kt_jvm_test`: JUnit ჩაშენებულია.
- `cc_test` GoogleTest-ით: გამშვები წერს JUnit-ს, როდესაც კომპილირებულია ახალი gtest-ის წინააღმდეგ; ძველი კონფიგურაციები საჭიროებენ `--gtest_output=xml:$XML_OUTPUT_FILE`-ს.
- `py_test`: გამოიყენეთ pytest `--junitxml=$XML_OUTPUT_FILE`-ით, ან `rules_python` pytest გამშვები.
- `go_test`: გადაამისამართეთ `go test -json` `gotestsum --junitfile=$XML_OUTPUT_FILE`-ში, ან შეფუთეთ დამხმარე საშუალებით, რომელიც გამოსცემს JUnit-ს.

`rust_test` `rules_rust`-დან და `rules_rs`-დან აწარმოებს სტანდარტულ `libtest` ჰარნესს, რომელიც არ წერს JUnit-ს სტაბილურ Rust-ზე. შეფუთეთ სატესტო მიზანი სკრიპტით, რომელიც პარსავს `libtest` გამოტანას და წერს JUnit-ს `$XML_OUTPUT_FILE`-ში; თქვენ ინარჩუნებთ თითოეული შემთხვევის სტრიქონებს Tuist-ში და იგივე გაშვება რჩება ერთ Bazel სატესტო მიზნად.

## ტესტის იდენტურობა {#test-identity}

შემთხვევები იდენტიფიცირდება მიზნის ლეიბლით, კლასის სახელით (საიტის სახელზე დაბრუნებით) და ტესტის სახელით. ეს ინარჩუნებს იდენტური სახელის მქონე მეთოდებს სხვადასხვა კლასებში განცალკევებულად. ძველი ანგარიშები, რომლებიც იყენებდნენ განსხვავებულ შემომსაზღვრელ საიტის სახელს, ინარჩუნებენ ისტორიას ძველი იდენტურობის ქვეშ; ძველ იდენტურობაზე გამოყენებული სტატუსის ცვლილებები უნდა განმეორდეს ახალზე, და ბრძანება გაფრთხილებთ, როდესაც შეცდომა ემთხვევა ძველ იდენტურობას, რათა იცოდეთ, რომელი პოლიტიკა გადაიტანოთ.

## CI კონტექსტის მიწოდება {#providing-ci-context}

Tuist კითხულობს git კომიტის და შტოს ინფორმაციას Bazel-ის ბილდის მეტამონაცემებიდან, რათა იგივე კომიტზე გაშვებები შედარდეს გარემოებს შორის. უმეტესი უწყვეტი ინტეგრაციის სისტემები უკვე აყენებს მათ; როდესაც თქვენი არ აკეთებს, გადაეცით ისინი ცალსახად:

```bash
tuist bazel test -- \
  --build_metadata=CI=true \
  --build_metadata=GIT_COMMIT="$GIT_COMMIT" \
  --build_metadata=GIT_BRANCH="$GIT_BRANCH" //app:tests
```

იგივე `--build_metadata` ფლაგი არის ის, რასაც <.localized_link href="/guides/features/build-insights/bazel#custom-metadata">Bazel ბილდის ინსაიტები</.localized_link> გვერდი აღწერს გამოძახებების მონიშვნისთვის, ამიტომ ფლაგების ერთი ნაკრები ფარავს ორივე ზედაპირს.

## არასტაბილური ტესტები და კარანტინი {#flaky-tests-and-quarantine}

გამეორებები, გაშვებებს შორის არასტაბილურობის აღმოჩენა და თითოეული შემთხვევის კარანტინი (ჩუმად და გამოტოვება) ყველა მუშაობს `tuist bazel test`-ის მეშვეობით. სრული სამუშაო პროცესისთვის იხილეთ <.localized_link href="/guides/features/test-insights/flaky-tests/bazel">Bazel არასტაბილური ტესტები</.localized_link>.

## მონაცემთა შენახვა {#data-retention}

Tuist ინარჩუნებს Bazel-ის გამოძახებას, რომელმაც წარმოქმნა ტესტების გაშვება, მის ლოგებს და მოლოდინში მყოფ ტესტების მიღების ჩანაწერებს 90 დღის განმავლობაში. სატესტო შემთხვევები და მათი გაშვების ისტორია იყენებენ იგივე მოდელს, როგორც ყველა სხვა ბილდის სისტემა და არ ექვემდებარებიან ამ ვადას. სრული პოლიტიკისთვის იხილეთ <.localized_link href="/guides/server/data-retention">მონაცემთა შენახვა</.localized_link>.

Bazel ტესტების ინსაიტები

მოთხოვნები

Bazel-ის სამუშაო სივრცე, დაკავშირებული tuist bazel setup-ით, როგორც აღწერილია Bazel-ის პროექტის დაწყება-ში.

tuist bazel setup აკონფიგურირებს თითოეული შემთხვევის შესახებ ანგარიშგებას .bazelrc.tuist-ში, ამიტომ ჩვეულებრივი bazel test აგზავნის ცალკეულ სატესტო შემთხვევებს იმავე დაშბორდებზე, რომლებსაც ყველა სხვა ბილდის სისტემა იყენებს:

bash

bazel test //app:tests

კარანტინის გამოყენებისთვის, გაუშვით ტესტები Tuist-ის გარსაცმის მეშვეობით. არგუმენტები ---ის შემდეგ გადაეცემა bazel test-ს:

bash

tuist bazel test -- //app:tests

რა ფიქსირდება#

Tuist პარსავს test.xml ანგარიშებს და იღებს test.log გამოტანას, რომელსაც Bazel ქმნის თითოეული სატესტო მიზნისთვის, შემდეგ კი აერთიანებს მათ საერთო ტესტების გაშვების მოდელში. თითოეული გაშვება იწერს:

ცალკეული სატესტო შემთხვევის წარმატების, შეცდომის და გამოტოვების სტატუსს, ხანგრძლივობასთან ერთად.
სატესტო მიზნის, კლასის და საიტის სტრუქტურას.
გამეორების მცდელობებს, როდესაც Bazel კონფიგურირებულია არასტაბილური ტესტების გამეორებისთვის.
შეცდომის გამოტანას, აღებულს მიზნის test.log-დან.

ტესტების გაშვებები, სატესტო შემთხვევები და ცალკეული ტესტების გვერდები Bazel-ისთვის ისევე მუშაობს, როგორც სხვა ბილდის სისტემებისთვის.

თითოეული შემთხვევის JUnit ანგარიშების გენერირება#

თითოეული შემთხვევის სტრიქონები დამოკიდებულია იმაზე, რომ სატესტო მიზანი წერდეს JUnit test.xml-ს $XML_OUTPUT_FILE გზაზე, რომელსაც Bazel უზრუნველყოფს. როდესაც გამშვები არ წერს მას, Bazel იყენებს სინთეზურ ერთ-შემთხვევიან ანგარიშს, რომელიც სახელდება მიზნის მიხედვით, და Tuist აჩვენებს ერთ სტრიქონს თითოეული მიზნისთვის (მონიშნული როგორც Bazel მიზანი სატესტო შემთხვევების სიაში), სადაც ნედლი test.log კვლავ ხელმისაწვდომია გაშვების გვერდზე.

Bazel-ის უმეტესი სატესტო წესები უკვე ქმნიან რეალურ test.xml-ს:

java_test და kt_jvm_test: JUnit ჩაშენებულია.
cc_test GoogleTest-ით: გამშვები წერს JUnit-ს, როდესაც კომპილირებულია ახალი gtest-ის წინააღმდეგ; ძველი კონფიგურაციები საჭიროებენ --gtest_output=xml:$XML_OUTPUT_FILE-ს.
py_test: გამოიყენეთ pytest --junitxml=$XML_OUTPUT_FILE-ით, ან rules_python pytest გამშვები.
go_test: გადაამისამართეთ go test -jsongotestsum --junitfile=$XML_OUTPUT_FILE-ში, ან შეფუთეთ დამხმარე საშუალებით, რომელიც გამოსცემს JUnit-ს.

rust_testrules_rust-დან და rules_rs-დან აწარმოებს სტანდარტულ libtest ჰარნესს, რომელიც არ წერს JUnit-ს სტაბილურ Rust-ზე. შეფუთეთ სატესტო მიზანი სკრიპტით, რომელიც პარსავს libtest გამოტანას და წერს JUnit-ს $XML_OUTPUT_FILE-ში; თქვენ ინარჩუნებთ თითოეული შემთხვევის სტრიქონებს Tuist-ში და იგივე გაშვება რჩება ერთ Bazel სატესტო მიზნად.

ტესტის იდენტურობა#

შემთხვევები იდენტიფიცირდება მიზნის ლეიბლით, კლასის სახელით (საიტის სახელზე დაბრუნებით) და ტესტის სახელით. ეს ინარჩუნებს იდენტური სახელის მქონე მეთოდებს სხვადასხვა კლასებში განცალკევებულად. ძველი ანგარიშები, რომლებიც იყენებდნენ განსხვავებულ შემომსაზღვრელ საიტის სახელს, ინარჩუნებენ ისტორიას ძველი იდენტურობის ქვეშ; ძველ იდენტურობაზე გამოყენებული სტატუსის ცვლილებები უნდა განმეორდეს ახალზე, და ბრძანება გაფრთხილებთ, როდესაც შეცდომა ემთხვევა ძველ იდენტურობას, რათა იცოდეთ, რომელი პოლიტიკა გადაიტანოთ.

CI კონტექსტის მიწოდება#

Tuist კითხულობს git კომიტის და შტოს ინფორმაციას Bazel-ის ბილდის მეტამონაცემებიდან, რათა იგივე კომიტზე გაშვებები შედარდეს გარემოებს შორის. უმეტესი უწყვეტი ინტეგრაციის სისტემები უკვე აყენებს მათ; როდესაც თქვენი არ აკეთებს, გადაეცით ისინი ცალსახად:

bash

tuist bazel test -- \
  --build_metadata=CI=true \
  --build_metadata=GIT_COMMIT="$GIT_COMMIT" \
  --build_metadata=GIT_BRANCH="$GIT_BRANCH" //app:tests

იგივე --build_metadata ფლაგი არის ის, რასაც Bazel ბილდის ინსაიტები გვერდი აღწერს გამოძახებების მონიშვნისთვის, ამიტომ ფლაგების ერთი ნაკრები ფარავს ორივე ზედაპირს.

არასტაბილური ტესტები და კარანტინი#

გამეორებები, გაშვებებს შორის არასტაბილურობის აღმოჩენა და თითოეული შემთხვევის კარანტინი (ჩუმად და გამოტოვება) ყველა მუშაობს tuist bazel test-ის მეშვეობით. სრული სამუშაო პროცესისთვის იხილეთ Bazel არასტაბილური ტესტები.

მონაცემთა შენახვა#

Tuist ინარჩუნებს Bazel-ის გამოძახებას, რომელმაც წარმოქმნა ტესტების გაშვება, მის ლოგებს და მოლოდინში მყოფ ტესტების მიღების ჩანაწერებს 90 დღის განმავლობაში. სატესტო შემთხვევები და მათი გაშვების ისტორია იყენებენ იგივე მოდელს, როგორც ყველა სხვა ბილდის სისტემა და არ ექვემდებარებიან ამ ვადას. სრული პოლიტიკისთვის იხილეთ მონაცემთა შენახვა.