გენერირებული Xcode პროექტი

მოთხოვნები

Xcode ტესტების ანალიზი კონფიგურირებული (ავტომატურად გენერირებული სქემები შეიცავს tuist inspect test post-action-ს; მორგებული სქემებისთვის ის ხელით უნდა დაამატოთ).

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

არასტაბილური ტესტების გვერდი

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

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

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

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

გადასცეთ -retry-tests-on-failure ან -test-iterationstuist test-ის მეშვეობით:

bash

tuist test --scheme MyScheme -- -retry-tests-on-failure -test-iterations 3

არასტაბილური ტესტის საქმის დეტალები

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

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

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

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

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

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

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

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

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

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

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

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

კარანტინში მყოფი ტესტი ერთ-ერთ ორ რეჟიმშია:

დადუმებული: ტესტი მაინც სრულდება, მაგრამ tuist test ფარავს წარუმატებლობას. წარუმატებლობები მაინც კვებავს არასტაბილური ტესტების დეტექტორს, რათა შეძლოთ ტესტის თვალყურის დევნა ბილდის გაწყვეტის გარეშე. აირჩიეთ ეს იმ ტესტისთვის, რომელსაც აქტიურად იკვლევთ.
გამოტოვებული: xcodebuild იღებს -skip-testing <identifier>, ამიტომ ტესტი არასდროს იწყება. ის არ წარმოქმნის ახალ შედეგებს და ქრება არასტაბილური ტესტების dashboard-დან, სანამ ხელახლა არ ჩართავთ. აირჩიეთ ეს, როდესაც ტესტი გატეხილია, ნელია, ან იმდენად მუდმივად არასტაბილურია, რომ მისი გაშვება უბრალოდ ფლანგავს CI წუთებს.

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

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

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

tuist test ავტომატურად ითვალისწინებს ორივე რეჟიმს:

bash

tuist test

გამოტოვებული ტესტები გადაეცემა xcodebuild-ს როგორც -skip-testing და არასდროს იწყება. დადუმებული ტესტები ჩვეულებრივად სრულდება; თუ ისინი ვერდება, წარუმატებლობა იფარება მიღებულ ბილდის სტატუსში.

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

bash

tuist test --skip-quarantine

ახალი ტესტების სტრეს-ტესტირება#

სტრესის გეიტი ხელახლა აშვებს თქვენი ბრენჩის მიერ დამატებულ ტესტის საქმეებს, თითოეულს რამდენჯერმე ახალ პროცესში, და აცნობებს იმას, რომელიც არასტაბილური აღმოჩნდება. თქვენ ხედავთ ახალ არასტაბილურ ტესტს pull request-ზე, რომელმაც ის შემოიტანა, და არა კვირების შემდეგ.

ტესტის საქმე ახლად ითვლება, თუ ის ბოლო 90 დღის განმავლობაში არ გაშვებულა CI-ზე პროექტის ნაგულისხმევ ბრენჩზე, ან კომიტზე, რომელიც მას შემდეგ მოხვდა იქ. merge queue-სთან, ტესტის საქმე, რომელიც queue-მ გაუშვა, ცნობილი ხდება, როდესაც queue-ს კომიტი მოხვდება, და რჩება ახალი, თუ queue მას ტოვებს. კომიტები ემთხვევა Git ისტორიის მეშვეობით, რომელსაც Tuist აგროვებს CI-ზე.

ჩართვა#

გეიტი ნაგულისხმევად გამორთულია. დააყენეთ რეჟიმი:

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

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

დაიწყეთ report-ით რამდენიმე კვირის განმავლობაში, რომ ნახოთ, რას დაბლოკავდა enforce.

გადაეცით ის პასსრაუნ არგუმენტებამდე, ან დააყენეთ TUIST_TEST_STRESS_NEW_TESTS, რომ შეცვალოთ რეჟიმი თითოეული CI არხისთვის:

bash

tuist test --stress-new-tests report

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

ეს დამოკიდებულია იმაზე, თუ რამდენი ხანი დასჭირდა ტესტის საქმეს პირველ გაშვებაზე:

პირველი გაშვება	ხელახალი გაშვებები
5 წმ-მდე	10
10 წმ-მდე	5
30 წმ-მდე	3
5 წთ-მდე	2
5 წთ-ზე მეტი	არ ხდება ხელახალი გაშვება

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

როდესაც გეიტი არ სრულდება#

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

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-ის მეშვეობით — იხილეთ ტესტის საქმეების ბოლოწერტილები API ცნობარში მარშრუტების, ფილტრების და პასუხის ველების სრული სიისთვის. ტესტის საქმის მდგომარეობის შესაცვლელად (არასტაბილურად მონიშვნა ან მონიშვნის მოხსნა, დადუმება, გამოტოვება), გაგზავნეთ PATCH /api/projects/{account_handle}/{project_handle}/tests/test-cases/{test_case_id}is_flaky-ით ან state-ით. იგივე ცვლილება ხელმისაწვდომია როგორც tuist test case update და როგორც update_test_case Model Context Protocol ინსტრუმენტი.