# Elixir-ის არასტაბილური ტესტები {#elixir-flaky-tests}

> [!IMPORTANT]
> **მოთხოვნები**
>
> - შეასრულეთ <.localized_link href="/guides/get-started/elixir-project">Elixir-ის საერთო კონფიგურაცია</.localized_link>, რათა დააფიქსიროთ თქვენი ტესტების გაშვებები

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


![Phoenix აპლიკაციის არასტაბილური ტესტები](/images/guides/features/elixir/flaky-tests.png)

## როგორ მუშაობს არასტაბილურობის აღმოჩენა {#how-it-works}

Tuist ორი გზით აღმოაჩენს არასტაბილურ ტესტებს:

### ტესტების ხელახლა გაშვება {#test-retries}

ExUnit თითოეულ ტესტს ერთხელ უშვებს, ამიტომ დროდადრო მწყავარე ტესტი იგივენაირად გამოიყურება, როგორც გაუმართავი. ხელახლა გაშვებების ჩართვისას Hex პაკეტი ისევ უშვებს წარუმატებელ ტესტებს იმ რაოდენობამდე, რაც თქვენ მიუთითეთ. ტესტი, რომელიც ხელახლა გაშვებისას წარმატებით სრულდება, მონიშნულია როგორც არასტაბილური, ხოლო გაშვება წარმატებულად ითვლება, თუ ყველა წარუმატებელი ტესტი საბოლოოდ წარმატებით შესრულდება.

ხელახლა გაშვებები ნაგულისხმევად გამორთულია. მათ ჩასართავად დაამატეთ `test_retries` თქვენს არსებულ Tuist პარამეტრებში `mix.exs` ფაილში:

```elixir
tuist: [project: "account/project", cache: true, test_retries: 2]
```

ან ერთი გაშვებისთვის, ფლაგის ან გარემოს ცვლადის გამოყენებით:

```bash
mix test --retries 2
TUIST_TEST_RETRIES=2 mix test
```

ფლაგს აქვს უპირატესობა გარემოს ცვლადთან შედარებით, ხოლო გარემოს ცვლადს — `mix.exs`-თან შედარებით.

ხელახლა მხოლოდ წარუმატებელი ტესტები გადის, ისევე როგორც `mix test --failed`-ის შემთხვევაში, და დაფზე ნაჩვენებია თითოეული მცდელობა და მისი ხანგრძლივობა. გაშვება, რომელიც ExUnit-მა ადრე შეაჩერა `--max-failures`-ის გამო, არ განმეორდება. ასევე არ განმეორდება გაშვება, რომლის ყველა წარუმატებელი ტესტი დროის ამოწურვით (timeout) დასრულდა, რადგან ყოველი ხელახლა გაშვება ისევ დაელოდება ყველა დროის ამოწურვას. ხელახლა გაშვებები ასევე გამოიტოვება `--warnings-as-errors`-ით, რასაც `mix test` ვეღარ აკონტროლებს, და umbrella პროექტის ფესვიდან; ტესტების ხელახლა გასაშვებად გაუშვით ისინი umbrella-ს ერთ-ერთი აპლიკაციის შიგნით.

![არასტაბილური ExUnit ტესტი და მისი ისტორია](/images/guides/features/elixir/flaky-test-case.png)

### ჯვარედინი გაშვებების აღმოჩენა {#cross-run-detection}

ტესტების ხელახლა გაშვების გარეშეც, Tuist-ს შეუძლია აღმოაჩინოს არასტაბილური ტესტები სხვადასხვა CI გაშვების შედეგების შედარებით ერთსა და იმავე კომიტზე. თუ ტესტი ერთ CI გაშვებაში წარმატებულია, მაგრამ მეორე გაშვებაში იმავე კომიტისა და სქემის ლეიბლისთვის (`--scheme`) მწყავარეა, წარუმატებელი შესრულება მონიშნულია როგორც არასტაბილური.

ეს განსაკუთრებით სასარგებლოა იმ არასტაბილური ტესტების აღმოსაჩენად, რომლებიც არ მწყავარე იმდენად თანმიმდევრულად, რომ ხელახლა გაშვებებმა დაიჭიროს, მაგრამ მაინც იწვევენ დროდადრო CI წარუმატებლობებს.

## არასტაბილური ტესტების მართვა {#managing-flaky-tests}

### ავტომატური გასუფთავება {#automatic-clearing}

აღმოჩენა და გასუფთავება ხორციელდება პროექტზე არსებული **ავტომატიზაციის შეტყობინების** მეშვეობით. ყოველ პროექტს აქვს ნაგულისხმევი „არასტაბილური ტესტების აღმოჩენის“ ავტომატიზაცია, რომლის *ტრიგერი* ტესტს არასტაბილურად ნიშნავს, ხოლო *აღდგენა* ხსნის ამ ნიშანს, როცა ტესტი კონფიგურირებულ აღდგენის ფანჯარაში (ნაგულისხმევი **14 დღე**) ხელახლა არ გააქტიურებს ტრიგერს. შეცვალეთ ის **პარამეტრები → ავტომატიზაციები** განყოფილებაში, რათა შეცვალოთ აღდგენის ფანჯარა, აღდგენის ქმედებები (მაგალითად, ასევე მოხსნათ ტესტი კარანტინიდან) ან სრულიად გამორთოთ აღდგენა, რათა ტესტები დარჩეს არასტაბილურად მონიშნული, სანამ ხელით არ გაასუფთავებთ.

### ხელით მართვა {#manual-management}

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


## არასტაბილური ტესტების კარანტინში მოქცევა {#quarantining}

კარანტინი ხელს უშლის არასტაბილურ ტესტს CI-ის ბლოკირებაში, სანამ მას შეასწორებთ. დაფზე ტესტის გვერდზე შეცვალეთ მისი მდგომარეობა **ჩუმად**-ად ან **გამოტოვებულ**-ად, ან დააკონფიგურირეთ ავტომატიზაცია **პარამეტრები → ავტომატიზაციები** ქვეშ, რომელიც ტესტს ჩუმად ან გამოტოვებულად ნიშნავს, როცა ის არასტაბილური ხდება და ისევ ჩართავს, როცა აღდგება. ტესტების გაშვებამდე `mix test` კითხულობს პროექტის ყველა კარანტინში მყოფ ტესტს და ავრცელებს მათ:

- **ჩუმი**: ტესტი გადის და მისი წარუმატებლობა მაინც ფიქსირდება, მაგრამ გაშვება წარმატებულად ითვლება, თუ მისი ერთადერთი წარუმატებლობები ჩუმი ტესტებია. ხელახლა გაშვებები მაინც ახდენენ ჩუმი, მაგრამ წარუმატებელი ტესტის განმეორებას, ამიტომ არასტაბილურმა ტესტმა შეიძლება წარმატებით გაიაროს და მონიშნულ იქნას როგორც არასტაბილური.
- **გამოტოვებული**: ტესტი არ გადის. `mix test` აჩვენებს გამოტოვებულ ტესტებს გაშვების დაწყებამდე.

```text
Tuist: skipping 1 quarantined test:
  MyApp.CheckoutTest: create_order/2 times out
Tuist: 1 muted test run, and their failures do not fail the run.
```

გაშვება ჩვეულებრივად მწყავარეა, როცა ნებისმიერი ტესტი, რომელიც ჩუმი არ არის, მწყავარეა, ან როცა ExUnit ადრე ჩერდება `--max-failures`-ის გამო.

> [!WARNING]
> **შეზღუდვები**
>
> - კარანტინს მხოლოდ Hex პაკეტის ბოლო ვერსიები იყენებენ. ადრეული ვერსიები ჩუმ და გამოტოვებულ ტესტებს სხვების მსგავსად უშვებენ, ამიტომ ჩუმი ტესტის წარუმატებლობა მაინც აფუჭებს გაშვებას. სანამ მას დაეყრდნობით, განაახლეთ `tuist_ex`.
> - ჩუმი ტესტები არ მოქმედებს `--warnings-as-errors`-ით ან umbrella პროექტის ფესვიდან გაშვებისას. მათი წარუმატებლობები მაშინ აფუჭებენ გაშვებას. ნაცვლად ამისა, გაუშვით ტესტები umbrella-ს თითოეული აპლიკაციის შიგნით.
> - გამოტოვება ემთხვევა ტესტს მისი describe ბლოკისა და სახელის მიხედვით, არა მოდულის. სხვა მოდულში იმავე describe ბლოკისა და სახელის მქონე ტესტიც გამოტოვებულია. იხილეთ [როგორ ირჩევს გამოტოვება ტესტებს](#how-skipping-selects-tests).
> - გამოტოვებული ტესტი მაინც გადის, როცა მას ირჩევთ `--only`, `--include` ან `path:line`-ით, ან როცა ის არ არის განცხადებული `test`-ით, მაგალითად StreamData `property`.
> - თუ `mix test` ვერ კითხულობს კარანტინში მყოფ ტესტებს, ის ყველა ტესტს უშვებს და ყველა წარუმატებლობას ითვლის.
> - კარანტინში მყოფი ტესტების წაკითხვა სერთიფიკატებს მოითხოვს, მაშინაც კი, თუ პროექტი საჯაროა. გაშვება `TUIST_TOKEN`-ის, `mix tuist.login` სესიის ან უწყვეტი ინტეგრაციის იდენტობის ტოკენის გარეშე არ ავრცელებს კარანტინს. ეს მოიცავს fork-ებიდან შემოსულ pull request-ებს, რომლებიც ჩვეულებრივ საიდუმლოების გარეშე გადის.
> - `--cover`-ის შემთხვევაში, გამოტოვებული ტესტი ითვლება ამოღებულად: ხაზები, რომლებსაც მხოლოდ ის ფარავდა, მოხსენებულია როგორც დაუფარავი.
>
> `mix test` თავის შეჯამების შემდეგ ასახელებს ტესტებს, რომლებიც გამოტოვებამ შეცდომით გამოტოვა, და გამოტოვებულ ტესტებს, რომლებიც მაინც გადნენ.

### როგორ ირჩევს გამოტოვება ტესტებს {#how-skipping-selects-tests}

გამოტოვებული ტესტი გამოიტოვება ExUnit ფილტრით მისი სრული სახელის მიხედვით, მაგალითად `--exclude "test:test create_order/2 times out"`. ExUnit ფილტრებს არ შეუძლიათ მოდულის დამთხვევაც, ამიტომ:

- სხვა მოდულში იმავე describe ბლოკისა და სახელის მქონე ტესტიც გამოტოვებულია. `mix test` ასახელებს ამ ტესტებს გაშვების შემდეგ.
- ტესტი, რომელსაც ირჩევთ `--only`, `--include` ან `path:line`-ით, მაინც გადის, მაშინაც კი, თუ ის გამოტოვებულია, რადგან ExUnit include ფილტრებს exclude ფილტრების შემდეგ ავრცელებს. ასევე ხდება ტესტის შემთხვევაში, რომელიც არ არის განცხადებული `test`-ით, მაგალითად StreamData `property`. `mix test` ასახელებს ამ ტესტებს გაშვების შემდეგ.

### კარანტინში მყოფი ტესტების ხელახლა გაშვება {#running-quarantined-tests-again}

გადაეცით `--no-quarantine`, რათა ყველა ტესტი გაუშვათ და ყველა წარუმატებლობა დაითვალოთ, მაგალითად შესწორების შესამოწმებლად:

```bash
mix test --no-quarantine
```

დააბრუნეთ ტესტი **ჩართულ** მდგომარეობაში მის გვერდზე, რათა ის მომავალ გაშვებებში ჩაერთოს. გამოტოვებული ტესტი ახალ შედეგებს არ ქმნის, სანამ ის ხელახლა არ გადის.

თუ `mix test` ვერ კითხულობს კარანტინში მყოფ ტესტებს, ის აჩვენებს გაფრთხილებას და ყველა ტესტს მათ გარეშე უშვებს. სერთიფიკატების ან კონფიგურირებული პროექტის გარეშე ის ყველა ტესტს გაფრთხილების გარეშე უშვებს.

Hex პაკეტი ახალ ტესტებს ჯერ სტრეს-ტესტირებას არ უკეთებს.

## Slack-ის შეტყობინებები {#slack-notifications}

მიიღეთ შეტყობინება, როდესაც ტესტი არამდგრადი ხდება, თქვენს Slack ინტეგრაციაში <.localized_link href="/guides/integrations/slack#flaky-test-alerts">არამდგრადი ტესტების გაფრთხილებების</.localized_link> დაყენებით.


## არასტაბილური მდგომარეობის მოთხოვნა {#querying}

მონაცემები ხელმისაწვდომია HTTP-ით. სრული სიისთვის, რომელიც მოიცავს მარშრუტებს, ფილტრებს და პასუხის ველებს, იხილეთ [სატესტო შემთხვევების ბოლოწერტილები](https://tuist.dev/api/docs#tag/test-cases) API-ის ცნობარში. სატესტო შემთხვევის არასტაბილურად აღსანიშნავად ან ამ ნიშნის მოსახსნელად, გაგზავნეთ `PATCH /api/projects/{account_handle}/{project_handle}/tests/test-cases/{test_case_id}` პარამეტრით `is_flaky`, ან გამოიყენეთ `update_test_case` Model Context Protocol ინსტრუმენტი.

Elixir-ის არასტაბილური ტესტები

მოთხოვნები

შეასრულეთ Elixir-ის საერთო კონფიგურაცია, რათა დააფიქსიროთ თქვენი ტესტების გაშვებები

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

Phoenix აპლიკაციის არასტაბილური ტესტები

როგორ მუშაობს არასტაბილურობის აღმოჩენა#

Tuist ორი გზით აღმოაჩენს არასტაბილურ ტესტებს:

ტესტების ხელახლა გაშვება#

ExUnit თითოეულ ტესტს ერთხელ უშვებს, ამიტომ დროდადრო მწყავარე ტესტი იგივენაირად გამოიყურება, როგორც გაუმართავი. ხელახლა გაშვებების ჩართვისას Hex პაკეტი ისევ უშვებს წარუმატებელ ტესტებს იმ რაოდენობამდე, რაც თქვენ მიუთითეთ. ტესტი, რომელიც ხელახლა გაშვებისას წარმატებით სრულდება, მონიშნულია როგორც არასტაბილური, ხოლო გაშვება წარმატებულად ითვლება, თუ ყველა წარუმატებელი ტესტი საბოლოოდ წარმატებით შესრულდება.

ხელახლა გაშვებები ნაგულისხმევად გამორთულია. მათ ჩასართავად დაამატეთ test_retries თქვენს არსებულ Tuist პარამეტრებში mix.exs ფაილში:

elixir

tuist: [project: "account/project", cache: true, test_retries: 2]

ან ერთი გაშვებისთვის, ფლაგის ან გარემოს ცვლადის გამოყენებით:

bash

mix test --retries 2
TUIST_TEST_RETRIES=2 mix test

ფლაგს აქვს უპირატესობა გარემოს ცვლადთან შედარებით, ხოლო გარემოს ცვლადს — mix.exs-თან შედარებით.

ხელახლა მხოლოდ წარუმატებელი ტესტები გადის, ისევე როგორც mix test --failed-ის შემთხვევაში, და დაფზე ნაჩვენებია თითოეული მცდელობა და მისი ხანგრძლივობა. გაშვება, რომელიც ExUnit-მა ადრე შეაჩერა --max-failures-ის გამო, არ განმეორდება. ასევე არ განმეორდება გაშვება, რომლის ყველა წარუმატებელი ტესტი დროის ამოწურვით (timeout) დასრულდა, რადგან ყოველი ხელახლა გაშვება ისევ დაელოდება ყველა დროის ამოწურვას. ხელახლა გაშვებები ასევე გამოიტოვება --warnings-as-errors-ით, რასაც mix test ვეღარ აკონტროლებს, და umbrella პროექტის ფესვიდან; ტესტების ხელახლა გასაშვებად გაუშვით ისინი umbrella-ს ერთ-ერთი აპლიკაციის შიგნით.

არასტაბილური ExUnit ტესტი და მისი ისტორია

ჯვარედინი გაშვებების აღმოჩენა#

ტესტების ხელახლა გაშვების გარეშეც, Tuist-ს შეუძლია აღმოაჩინოს არასტაბილური ტესტები სხვადასხვა CI გაშვების შედეგების შედარებით ერთსა და იმავე კომიტზე. თუ ტესტი ერთ CI გაშვებაში წარმატებულია, მაგრამ მეორე გაშვებაში იმავე კომიტისა და სქემის ლეიბლისთვის (--scheme) მწყავარეა, წარუმატებელი შესრულება მონიშნულია როგორც არასტაბილური.

ეს განსაკუთრებით სასარგებლოა იმ არასტაბილური ტესტების აღმოსაჩენად, რომლებიც არ მწყავარე იმდენად თანმიმდევრულად, რომ ხელახლა გაშვებებმა დაიჭიროს, მაგრამ მაინც იწვევენ დროდადრო CI წარუმატებლობებს.

არასტაბილური ტესტების მართვა#

ავტომატური გასუფთავება#

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

ხელით მართვა#

ტესტების არასტაბილურად მონიშვნა ან ნიშნის მოხსნა შესაძლებელია სატესტო შემთხვევის დეტალური გვერდიდან. ეს სასარგებლოა, როცა:

გსურთ აღიაროთ ცნობილი არასტაბილური ტესტი, სანამ მის გამოსწორებაზე მუშაობთ
ტესტი ინფრასტრუქტურული პრობლემების გამო შეცდომით იყო მონიშნული

არასტაბილური ტესტების კარანტინში მოქცევა#

კარანტინი ხელს უშლის არასტაბილურ ტესტს CI-ის ბლოკირებაში, სანამ მას შეასწორებთ. დაფზე ტესტის გვერდზე შეცვალეთ მისი მდგომარეობა ჩუმად-ად ან გამოტოვებულ-ად, ან დააკონფიგურირეთ ავტომატიზაცია პარამეტრები → ავტომატიზაციები ქვეშ, რომელიც ტესტს ჩუმად ან გამოტოვებულად ნიშნავს, როცა ის არასტაბილური ხდება და ისევ ჩართავს, როცა აღდგება. ტესტების გაშვებამდე mix test კითხულობს პროექტის ყველა კარანტინში მყოფ ტესტს და ავრცელებს მათ:

ჩუმი: ტესტი გადის და მისი წარუმატებლობა მაინც ფიქსირდება, მაგრამ გაშვება წარმატებულად ითვლება, თუ მისი ერთადერთი წარუმატებლობები ჩუმი ტესტებია. ხელახლა გაშვებები მაინც ახდენენ ჩუმი, მაგრამ წარუმატებელი ტესტის განმეორებას, ამიტომ არასტაბილურმა ტესტმა შეიძლება წარმატებით გაიაროს და მონიშნულ იქნას როგორც არასტაბილური.
გამოტოვებული: ტესტი არ გადის. mix test აჩვენებს გამოტოვებულ ტესტებს გაშვების დაწყებამდე.

plaintext

Tuist: skipping 1 quarantined test:
  MyApp.CheckoutTest: create_order/2 times out
Tuist: 1 muted test run, and their failures do not fail the run.

გაშვება ჩვეულებრივად მწყავარეა, როცა ნებისმიერი ტესტი, რომელიც ჩუმი არ არის, მწყავარეა, ან როცა ExUnit ადრე ჩერდება --max-failures-ის გამო.

შეზღუდვები

კარანტინს მხოლოდ Hex პაკეტის ბოლო ვერსიები იყენებენ. ადრეული ვერსიები ჩუმ და გამოტოვებულ ტესტებს სხვების მსგავსად უშვებენ, ამიტომ ჩუმი ტესტის წარუმატებლობა მაინც აფუჭებს გაშვებას. სანამ მას დაეყრდნობით, განაახლეთ tuist_ex.
ჩუმი ტესტები არ მოქმედებს --warnings-as-errors-ით ან umbrella პროექტის ფესვიდან გაშვებისას. მათი წარუმატებლობები მაშინ აფუჭებენ გაშვებას. ნაცვლად ამისა, გაუშვით ტესტები umbrella-ს თითოეული აპლიკაციის შიგნით.
გამოტოვება ემთხვევა ტესტს მისი describe ბლოკისა და სახელის მიხედვით, არა მოდულის. სხვა მოდულში იმავე describe ბლოკისა და სახელის მქონე ტესტიც გამოტოვებულია. იხილეთ როგორ ირჩევს გამოტოვება ტესტებს.
გამოტოვებული ტესტი მაინც გადის, როცა მას ირჩევთ --only, --include ან path:line-ით, ან როცა ის არ არის განცხადებული test-ით, მაგალითად StreamData property.
თუ mix test ვერ კითხულობს კარანტინში მყოფ ტესტებს, ის ყველა ტესტს უშვებს და ყველა წარუმატებლობას ითვლის.
კარანტინში მყოფი ტესტების წაკითხვა სერთიფიკატებს მოითხოვს, მაშინაც კი, თუ პროექტი საჯაროა. გაშვება TUIST_TOKEN-ის, mix tuist.login სესიის ან უწყვეტი ინტეგრაციის იდენტობის ტოკენის გარეშე არ ავრცელებს კარანტინს. ეს მოიცავს fork-ებიდან შემოსულ pull request-ებს, რომლებიც ჩვეულებრივ საიდუმლოების გარეშე გადის.
--cover-ის შემთხვევაში, გამოტოვებული ტესტი ითვლება ამოღებულად: ხაზები, რომლებსაც მხოლოდ ის ფარავდა, მოხსენებულია როგორც დაუფარავი.

mix test თავის შეჯამების შემდეგ ასახელებს ტესტებს, რომლებიც გამოტოვებამ შეცდომით გამოტოვა, და გამოტოვებულ ტესტებს, რომლებიც მაინც გადნენ.

როგორ ირჩევს გამოტოვება ტესტებს#

გამოტოვებული ტესტი გამოიტოვება ExUnit ფილტრით მისი სრული სახელის მიხედვით, მაგალითად --exclude "test:test create_order/2 times out". ExUnit ფილტრებს არ შეუძლიათ მოდულის დამთხვევაც, ამიტომ:

სხვა მოდულში იმავე describe ბლოკისა და სახელის მქონე ტესტიც გამოტოვებულია. mix test ასახელებს ამ ტესტებს გაშვების შემდეგ.
ტესტი, რომელსაც ირჩევთ --only, --include ან path:line-ით, მაინც გადის, მაშინაც კი, თუ ის გამოტოვებულია, რადგან ExUnit include ფილტრებს exclude ფილტრების შემდეგ ავრცელებს. ასევე ხდება ტესტის შემთხვევაში, რომელიც არ არის განცხადებული test-ით, მაგალითად StreamData property. mix test ასახელებს ამ ტესტებს გაშვების შემდეგ.

კარანტინში მყოფი ტესტების ხელახლა გაშვება#

გადაეცით --no-quarantine, რათა ყველა ტესტი გაუშვათ და ყველა წარუმატებლობა დაითვალოთ, მაგალითად შესწორების შესამოწმებლად:

bash

mix test --no-quarantine

დააბრუნეთ ტესტი ჩართულ მდგომარეობაში მის გვერდზე, რათა ის მომავალ გაშვებებში ჩაერთოს. გამოტოვებული ტესტი ახალ შედეგებს არ ქმნის, სანამ ის ხელახლა არ გადის.

თუ mix test ვერ კითხულობს კარანტინში მყოფ ტესტებს, ის აჩვენებს გაფრთხილებას და ყველა ტესტს მათ გარეშე უშვებს. სერთიფიკატების ან კონფიგურირებული პროექტის გარეშე ის ყველა ტესტს გაფრთხილების გარეშე უშვებს.

Hex პაკეტი ახალ ტესტებს ჯერ სტრეს-ტესტირებას არ უკეთებს.

Slack-ის შეტყობინებები#

მიიღეთ შეტყობინება, როდესაც ტესტი არამდგრადი ხდება, თქვენს Slack ინტეგრაციაში არამდგრადი ტესტების გაფრთხილებების დაყენებით.

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

მონაცემები ხელმისაწვდომია HTTP-ით. სრული სიისთვის, რომელიც მოიცავს მარშრუტებს, ფილტრებს და პასუხის ველებს, იხილეთ სატესტო შემთხვევების ბოლოწერტილები API-ის ცნობარში. სატესტო შემთხვევის არასტაბილურად აღსანიშნავად ან ამ ნიშნის მოსახსნელად, გაგზავნეთ PATCH /api/projects/{account_handle}/{project_handle}/tests/test-cases/{test_case_id} პარამეტრით is_flaky, ან გამოიყენეთ update_test_case Model Context Protocol ინსტრუმენტი.