გადადით შინაარსზე

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

მოთხოვნები

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

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

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

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

ხელახალი გაშვებები არის არასავალდებულო და დამოუკიდებელია კარანტინისგან. --flaky_test_attempts=3 საშუალებას იძლევა თითოეული ტესტისთვის გამოიყენოთ სულ სამი Bazel-ის მცდელობა, და არა სამი დამატებითი ხელახალი გაშვება. შეინარჩუნეთ თქვენი არსებული ხელახალი გაშვების კონფიგურაცია .bazelrc-ში ან გადაეცით ის პირდაპირ:

bash
tuist bazel test -- --flaky_test_attempts=3 //app:tests

იმისათვის, რომ Tuist-მა დააკვირდეს შედეგებს, ხელახალი გაშვებები რეალურად უნდა შესრულდეს. Bazel-ის სამიზნის არასტაბილურობის შეჯამება მარტო ვერ განსაზღვრავს, რომელი კონკრეტული ქეისი იყო არასტაბილური.

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

გაშვებების შედარებას სჭირდება კომიტისა და ბრენჩის მეტამონაცემები. მიუთითეთ ისინი, თუ თქვენი აგების გარემო მათ ავტომატურად არ აქვეყნებს:

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

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

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

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

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

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

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

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

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

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

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

tuist bazel test იღებს კარანტინის პოლიტიკას ყოველი გამოძახების წინ და ავრცელებს მას ძირითად bazel test გაშვებაზე. ჩვეულებრივი bazel test კვლავ აჩვენებს ტესტების შედეგებს, მაგრამ არ ავრცელებს კარანტინს:

bash
tuist bazel test -- //app:tests

არგუმენტები ---ის შემდეგ გადაეცემა bazel test-ს. გამოიყენეთ --path პროექტისა და სამუშაო დირექტორიის არჩევასთვის, ხოლო --bazel — სხვა შესრულებადი ფაილის, მაგალითად bazelisk-ის, არჩევასთვის. სახელიანი Bazel-ის კონფიგურაცია, როგორიცაა --config=ci, არის არასავალდებულო და მუშაობს იგივე პრინციპით.

ჩუმი რეჟიმი#

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

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

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

რატომ შეიძლება კარანტინში მყოფი ტესტები წარმატებულად გამოისახოს#

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

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

გასწორების შესასწავლად ან დასადასტურებლად, აუარეთ გვერდი კარანტინის პოლიტიკას:

bash
tuist bazel test --no-quarantine -- --nocache_test_results //app:tests

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

შეზღუდვები#

  • ცალსახა --build_event_json_file ან --target_pattern_file ვერ კომბინირდება აქტიურ კარანტინთან. გადაეცით სამიზნის შაბლონები პირდაპირ.
  • თუ Tuist ვერ იღებს კარანტინის პოლიტიკას, ბრძანება ჩერდება ტესტების გაშვებამდე. ის არასდროს ავრცელებს ნაწილობრივ პოლიტიკას. გამოიყენეთ --no-quarantine, როცა განზრახვით გსურთ გაშვება მის გარეშე.
  • შეცდომა, რომელიც ემთხვევა ჩუმ რეჟიმს, ჩაწერილს ძველი სუიტაზე დაფუძნებული იდენტიფიკატორით, რჩება ბლოკირებად და ბრძანება ასახელებს პოლიტიკას ხელახლა გამოყენებისთვის.

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

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

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

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

CLI#

tuist test case ბრძანებების ხე საშუალებას გაძლევთ ნახოთ ყველა ინფორმაცია, რასაც Tuist აკვირდება სატესტო შემთხვევის შესახებ:

bash
tuist test case list --flaky # only flaky test cases
tuist test case list --quarantined # only muted or skipped test cases
tuist test case show <test_case_id> # detail: flakiness rate, last status, run counts
tuist test case events <test_case_id> # audit log: marked_flaky, muted, skipped, ...
tuist test case run list <test_case_id> # run history with status and duration
tuist test case run show <test_case_run_id> # single run, including failure breakdown

ყველა ეს ბრძანება იღებს --json პარამეტრს სკრიპტებისთვის.

REST API#

იგივე მონაცემები ხელმისაწვდომია HTTP-ით. სრული სიისთვის (მარშრუტები, ფილტრები და პასუხის ველები) იხილეთ Test Cases endpoints API-ის ცნობარში. სატესტო შემთხვევის მდგომარეობის შესაცვლელად (არასტაბილურად მონიშვნა/მოხსნა, ჩუმად დატოვება, გამოტოვება), გააგზავნეთ PATCH /api/projects/{account_handle}/{project_handle}/tests/test-cases/{test_case_id} პარამეტრებით is_flaky ან state. იგივე ცვლილების განხორციელება შესაძლებელია ასევე tuist test case update ბრძანებით და update_test_case MCP ინსტრუმენტით.