آزمون 1. 22. 1

یک کتابخانه کامل برای نوشتن و اجرای تست های دارت در سکوها.

آزمون یک روش استاندارد برای نوشتن و اجرای تست ها در DART ارائه می دهد.

نوشتن تست #

آزمایشات با استفاده از عملکرد تست () سطح بالا مشخص شده و ادعاهای آزمایش با استفاده از انتظار () انجام می شود.

آزمایشات را می توان با استفاده از عملکرد گروه () در کنار هم قرار داد. توضیحات هر گروه به ابتدای توضیحات آزمون خود اضافه می شود.

از هرگونه بسته بندی از بسته Matcher می توان با انتظار () برای انجام اعتبار سنجی پیچیده استفاده کرد:

همچنین می توانید استثنائات را با عملکرد Thowsa () یا یک تطبیق مانند ThowsFormatexception آزمایش کنید:

برای به اشتراک گذاشتن کد بین تست ها می توانید از توابع Setup () و Teardown () استفاده کنید. تنظیمات تنظیم () قبل از هر آزمایش در یک گروه یا مجموعه تست اجرا می شود و Teardown () بعد از آن اجرا می شود. Teardown () حتی اگر یک آزمایش از بین برود ، اجرا خواهد شد تا اطمینان حاصل شود که فرصتی برای تمیز کردن پس از خودش دارد.

تست های در حال اجرا #

یک فایل آزمایشی واحد را می توان فقط با استفاده از مسیر تست DART/به/test. dart اجرا کرد (از DART 2. 10 - نسخه های قبلی SDK باید به جای تست DART از آزمون RUN PUB استفاده کنند).

بسیاری از تست ها را می توان در یک زمان با استفاده از مسیر تست دارت/به/dir انجام داد.

همچنین می توان با استفاده از آن با استفاده از DART PATH/TO/TEST. DART ، آزمایش را در DART VM انجام داد ، اما این دونده تست کامل را بارگیری نمی کند و برخی از ویژگی ها را از دست نمی دهد.

دونده آزمون هر پرونده ای را که با _test. dart به پایان می رسد ، یک فایل آزمایشی می داند. اگر هیچ مسیری را پشت سر نگذارید ، تمام پرونده های تست را در آزمون/ فهرست شما اجرا می کند ، و این باعث می شود که کل برنامه خود را یکباره آزمایش کنید.

می توانید موارد تست های خاص را برای اجرای با نام با استفاده از DART Tes t-n "نام آزمایش" انتخاب کنید. رشته به عنوان یک عبارت منظم تعبیر می شود ، و فقط آزمایشاتی که توضیحات آنها (از جمله هر توصیف گروهی) مطابقت دارد که بیان منظم اجرا می شود. همچنین می توانید از پرچ م-n برای اجرای تست هایی که نام آنها حاوی یک رشته متن ساده است استفاده کنید.

به طور پیش فرض ، آزمایشات در DART VM انجام می شود ، اما می توانید آنها را در مرورگر و همچنین با عبور از مسیر DAR T-P -P Chrome Path/to/test. dart اجرا کنید. تست از شروع مرورگر و بارگیری تست ها مراقبت خواهد کرد و تمام نتایج دقیقاً مانند تست های VM در خط فرمان گزارش می شود. در واقع ، شما حتی می توانید تست ها را در هر دو سیستم عامل با یک دستور واحد اجرا کنید: DART TES T-P "Chrome ، VM" مسیر/به/test. dart.

پرس و جوهای مسیر آزمون #

برخی از پارامترهای پرس و جو در مسیرهای تست پشتیبانی می شوند ، که به شما امکان می دهد تست هایی را که فقط در آن مسیرها اجرا می شوند ، فیلتر کنید. این فیلترها با هر گزینه جهانی که تصویب می شود ادغام می شوند و تمام فیلترها باید برای اجرای یک آزمایش مطابقت داشته باشند.

• نام: همان کار را انجام می دهد (ساده شامل چک).
  • این تنها گزینه ای است که بیش از یک ورودی را پشتیبانی می کند.

  استفاده مثال: تست دارت "مسیر/به/تست. dart؟ line = 10 & col = 2"

  معناشناسی تطبیق خط/سره

  فیلترهای خط و COL در برابر ردیابی پشته فعلی که از دعوت به عملکرد تست گرفته شده مطابقت دارد و در صورتی که هر قاب موجود در ردیابی همه معیارهای زیر را برآورده می کند ، یک مسابقه در نظر گرفته می شود:

  • URI فریم با مجموعه تست ریشه URI مطابقت دارد.
    • این بدان معنی است که با خطوط کتابخانه های وارداتی مطابقت نخواهد داشت.

    تست های Sharding #

    همچنین می توان آزمایشات را با آرگومان های-total-stotal و-شاارد-شاخص انجام داد و به شما امکان می دهد مجموعه های تست خود را تقسیم کرده و آنها را جداگانه اجرا کنید. به عنوان مثال ، اگر می خواستید 3 قسمت از مجموعه تست خود را اجرا کنید ، می توانید آنها را به شرح زیر اجرا کنید:

    تست های تغییر شکل #

    ترتیب آزمون را می توان با استدلال بذر-آزمون تنظیم شده ، تغییر داد. این به شما امکان می دهد آزمایشات خود را با یک بذر خاص (قطعی) یا یک دانه تصادفی برای هر اجرا تغییر دهید. به عنوان مثال ، آزمون زیر را در نظر بگیرید:

    تنظیم-تست-تصادفی-ترتیب-بذر = 0 همان تأثیر را نشان می دهد که به هیچ وجه آن را مشخص نمی کند ، به این معنی که ترتیب آزمون به عنوان مثال باقی می ماند.

    انتخاب گزارشگر تست #

    می توانید با استفاده از پرچم خط فرما ن-reporter = خط فرمان ، فرمت خروجی نتایج آزمون را تنظیم کنید. قالب پیش فرض فرمت خروجی فشرده است - یک خط واحد ، که به طور مداوم با اجرای تست ها به روز می شود. با این حال ، هنگام اجرای اقدامات GitHub CI (از طریق بررسی متغیر محیط GitHub_Actions برای True) ، تغییر پیش فرض در قالب خروجی GitHub - یک گزارشگر سفارشی برای آن سیستم CI/CD.

    گزینه های موجود برای پرچ م-reporter عبارتند از:

    • جمع و جور: یک خط واحد و به طور مداوم به روز شده
    • گسترش یافته: یک خط جداگانه برای هر بروزرسانی
    • GitHub: یک خبرنگار سفارشی برای اقدامات GitHub
    • JSON: یک قالب قابل خواندن با دستگاه ؛به https://dart. dev/go/test-docs/json_reporter. md مراجعه کنید

    جمع آوری پوشش کد #

    برای جمع آوری پوشش کد ، می توانید تست ها را با استدلال پوشش اجرا کنید. فهرست مشخص شده می تواند یک مسیر مطلق یا نسبی باشد. اگر دایرکتوری در مسیر مشخص شده وجود نداشته باشد ، یک فهرست ایجاد می شود. اگر دایرکتوری وجود داشته باشد ، در صورت تعارض ، پرونده ها با آخرین داده های پوشش رونویسی می شوند.

    این گزینه مجموعه پوشش کد را به صورت مجموعه ای به صورت مجموعه فعال می کند و پرونده های پوشش حاصل در فهرست مشخص شده ، خروجی می شوند. سپس پرونده ها می توانند با استفاده از بسته فرمت شوند: Coverage Format_COVERAGE اجرایی.

    جمع آوری پوشش در حال حاضر فقط برای تست های اجرا شده در DART VM یا Chrome اجرا می شود.

    در اینجا نمونه ای از نحوه اجرای تست ها و قالب بندی پوشش جمع آوری شده به LCOV آورده شده است:

    • LCOV ابزاری GNU است که اطلاعاتی را در مورد اینکه بخش هایی از یک برنامه در واقع اجرا می شوند (یعنی "تحت پوشش") هنگام اجرای یک مورد آزمایش خاص ارائه می دهد.
    • GenHTML باینری یکی از ابزارهای LCOV است.
    • برای اطلاعات بیشتر به پروژه LCOV مراجعه کنید: https://github.com/linux-test-project/lcov
    • فرمول LCOV Homebrew را ببینید: https://formulae. brew. sh/formula/lcov

    محدود کردن تست ها به سیستم عامل های خاص #

    برخی از پرونده های تست فقط برای اجرای روی سیستم عامل های خاص معنی دارند. آنها ممکن است از DART: HTML یا DART استفاده کنند: IO ، آنها ممکن است رفتار سیستم فایل ویژه ویندوز را آزمایش کنند ، یا ممکن است از ویژگی هایی استفاده کنند که فقط در Chrome موجود باشد. حاشیه نویسی teston باعث می شود دقیقاً اعلام کنید که یک پرونده آزمایشی باید روی کدام سیستم عامل ها اجرا شود. فقط قبل از هرگونه اعلامیه کتابخانه یا واردات ، آن را در بالای پرونده خود قرار دهید:

    رشته ای که به Teston منتقل می کنید همان چیزی است که "انتخاب کننده پلت فرم" نامیده می شود و دقیقاً مشخص می کند که کدام سیستم عامل ها می توانند روی آن اجرا شوند. این می تواند به سادگی نام یک پلتفرم یا یک عبارت پیچیده تر بولی مانند دارت که شامل این نام های پلت فرم است ، ساده باشد.

    همچنین می توانید اعلام کنید که کل بسته شما فقط با اضافه کردن یک قسمت test_on به پرونده پیکربندی بسته خود ، فقط روی سیستم عامل های خاص کار می کند.

    انتخاب کنندگان سیستم عامل #

    انتخاب کنندگان پلت فرم از نحو انتخاب Boolean Selector تعریف شده در بسته boolean_selector استفاده می کنند ، که زیر مجموعه ای از نحو بیان DART است که فقط از عملیات بولی پشتیبانی می کند. شناسه های زیر تعریف شده است:

    VM: آیا این آزمون در خط فرمان DART VM اجرا می شود.

    Chrome: آیا این تست در Google Chrome در حال اجرا است.

    Firefox: آیا این آزمایش روی Mozilla Firefox انجام شده است.

    سافاری: این که آیا این تست روی Apple Safari اجرا شده است.

    اینترنت اکسپلورر: آیا این تست در Microsoft Inteet Explorer در حال اجرا است.

    گره: آیا این آزمون روی node. js. اجرا می شود.

    DART-VM: آیا این آزمایش در هر زمینه ای روی DART VM اجرا می شود. یکسان با! js.

    مرورگر: آیا این تست در هر مرورگر اجرا می شود.

    JS: آیا این آزمایش به JS گردآوری شده است. این یکسان با Dart-VM است.

    Blink: آیا این آزمایش در یک مرورگر که از موتور رندر Blink استفاده می کند ، در حال اجرا است.

    ویندوز: آیا این تست روی ویندوز اجرا می شود. این تنها در صورت صحت VM یا گره می تواند صادق باشد.

    MAC-OS: آیا این تست روی MACOS اجرا می شود. این تنها در صورت صحت VM یا گره می تواند صادق باشد.

    لینوکس: آیا این تست روی لینوکس اجرا می شود. این تنها در صورت صحت VM یا گره می تواند صادق باشد.

    Android: آیا این تست روی Android اجرا می شود. اگر VM نادرست باشد ، این نیز نادرست خواهد بود ، به این معنی که اگر این تست روی یک مرورگر Android اجرا شود ، این امر صحیح نخواهد بود.

    iOS: آیا این آزمون در iOS اجرا می شود. اگر VM نادرست باشد ، این نیز نادرست خواهد بود ، به این معنی که اگر تست روی مرورگر IOS کار کند ، این واقعیت نخواهد بود.

    POSIX: این که آیا این تست روی سیستم عامل POSIX در حال اجرا است یا خیر. این معادل ویندوز است.

    به عنوان مثال ، اگر می خواستید در هر مرورگر اما Chrome تست کنید ، Teston ("مرورگر و! کروم" را می نویسید).

    تست های در حال اجرا روی node. js #

    دونده تست همچنین از تست های کامپایل شده به JavaScript و اجرای آنها بر روی Node. js با عبور از گره پلاتف فرم پشتیبانی می کند. توجه داشته باشید که گره به نه DART دسترسی ندارد: HTML و DART: IO ، بنابراین هر API های خاص پلت فرم باید با استفاده از بسته JS فراخوانی شوند. با این حال ، ممکن است هنگام آزمایش API هایی که توسط کد JavaScript استفاده می شود ، مفید باشد.

    Runner Test به دنبال یک گره به نام اجرایی (در سیستم عامل Mac یا Linux) یا Node. exe (در ویندوز) در مسیر سیستم شما است. هنگام تدوین تست های Node. js ، ا ز-dnode = true عبور می کند ، بنابراین آزمایشات می توانند تعیین کنند که آیا آنها با استفاده از const bool. fromenvironment ("گره") روی گره کار می کنند. همچنین تنظیم شده است--Server-Mode ، که به کامپایلر می گوید DART: HTML در دسترس نیست.

    اگر یک دایرکتوری Node_Modules سطح بالا وجود داشته باشد ، آزمایش هایی که روی Node. js انجام می شود می توانند ماژول ها را از آن وارد کنند.

    تست های ناهمزمان #

    تست های نوشته شده با ASYNC / AWAIT به طور خودکار کار می کنند. دونده آزمون تا زمانی که آینده بازگشت به پایان نرسد ، آزمون را به پایان نمی رساند.

    خطاهای async Uncaught #

    هر خطای ناهمزمان نامشخص در منطقه ای که یک آزمایش در آن انجام می شود ، باعث می شود که آزمایش یک شکست محسوب شود. این می تواند باعث آزمایشی شود که قبلاً کامل در نظر گرفته شده بود و در صورت افزایش خطای Async Uncuamed Async ، در صورت عدم موفقیت در یک شکست ، تغییر می کند. اگر تمام موارد تست موجود در مجموعه به اتمام رسیده باشد ، ممکن است باعث از دست رفتن برخی از خطاها شود ، یا فقط در برخی از اجراها به سطح خود برسد.

    با اطمینان از اینکه همه آینده ها قبل از اتمام به عنوان یک خطا ، از خطاهای Async Uncaught استفاده می کنند ، خودداری کنید.

    ماترهای آینده #

    تعدادی از کارکردهای مفید و تطبیق برای ناهموار پیشرفته تر وجود دارد. از Matcher تکمیل () برای آزمایش آینده استفاده می شود. این تضمین می کند که این آزمون تا پایان آینده به پایان نرسد و یک مسابقه را در برابر ارزش آن آینده اجرا کند.

    Matcher Throwsa () و مسابقات مختلف ThrowsexceptionType با هر دو تماس تلفنی همزمان و آینده ناهمزمان کار می کنند. آنها اطمینان حاصل می کنند که یک نوع خاص از استثناء پرتاب می شود:

    تابع PesportAsync () عملکرد دیگری را بسته و دو شغل دارد. اول ، ادعا می کند که عملکرد بسته بندی شده تعداد مشخصی از بارها خوانده می شود و باعث می شود که در صورت فراخوانی بیش از حد ، آزمایش شکست بخورد. دوم ، این آزمون را از اتمام نگه می دارد تا زمانی که عملکرد به عنوان تعداد لازم از زمان نامیده شود.

    ماترهای جریان #

    بسته آزمایشی مجموعه ای از مسابقات قدرتمند را برای مقابله با جریانهای ناهمزمان فراهم می کند. آنها بیانگر و کامپوزیت هستند و نوشتن انتظارات پیچیده در مورد مقادیر منتشر شده توسط یک جریان را آسان می کنند. مثلا:

    یک جریان دهنده جریان همچنین می تواند با کلاس streamqueue بسته Async مطابقت داشته باشد ، که به شما امکان می دهد تا به جای اینکه به سمت مصرف کننده فشار بیایند ، از یک جریان درخواست شود. این مسابقه رویدادهای همسان را مصرف می کند ، اما بقیه صف ها را به تنهایی می گذارد تا بر خلاف یک جریان عادی که فقط می تواند یک مشترک داشته باشد ، می توان از آن استفاده کرد. مثلا:

    ماترهای جریان داخلی زیر در دسترس هستند:

    • با یک رویداد داده واحد مطابقت دارد. با یک رویداد خطای واحد مطابقت دارد. با یک رویداد واحد مطابقت دارد. در صورت مطابقت با یک تطبیق داخلی ، بدون اینکه نیاز به مطابقت با آنها داشته باشد ، رویدادهایی را مصرف می کند. مانند Mayemit () کار می کند ، اما تا آنجا که ممکن است با وقایع در برابر مسابقه مطابقت داشته باشد. رویدادهایی را با یک (یا بیشتر) از چندین مسابقه ممکن مصرف می کند. رویدادهایی را با چند تطبیق در یک ردیف مصرف می کند. مانند emitsinorder () کار می کند ، اما این امکان را به شما می دهد تا مطابق با هر ترتیب مطابقت داشته باشد. با جریانی مطابقت دارد که بدون مطابقت با یک مسابقه داخلی به پایان می رسد.

    همچنین می توانید ماترهای جریان سفارشی خود را با StreamMatcher () تعریف کنید.

    تست های در حال اجرا با html # سفارشی

    به طور پیش فرض ، Runner Test File HTML خالی خود را برای تست های مرورگر تولید می کند. با این حال ، تست هایی که به HTML سفارشی نیاز دارند می توانند پرونده های خاص خود را ایجاد کنند. این پرونده ها سه مورد نیاز دارند:

    آنها باید به همان نام تست داشته باشند ، با . DART جایگزین .html. همچنین می توانید در صورت تمایل به استفاده مجدد در تمام آزمایشات ، یک مسیر پیکربندی را به یک فایل HTML ارائه دهید. ارائه یک الگوی HTML سفارشی در زیر.

    آنها باید حاوی یک برچسب پیوند با rel = "x-dart-test" و یک ویژگی HREF باشند که به اسکریپت تست اشاره می کند.

    به عنوان مثال ، اگر تست به نام custom_html_test. dart داشتید ، ممکن است پرونده html زیر را بنویسید:

    ارائه یک الگوی HTML سفارشی #

    If you want to share the same HTML file across all tests, you can provide a custom_html_template_path configuration option to your configuration file. This file should follow the rules above, except that instead of the link tag add exactly one>در مکانی که می خواهید پردازنده الگوی آن را وارد کند.

    You can also optionally use any number of>صاحبخانه هایی که با نام پرونده آزمون جایگزین می شوند.

    این الگوی را نمی توان مانند هر پرونده آزمایشی نامگذاری کرد ، زیرا این امر با استفاده از مکانیک HTML سفارشی برخورد می کند. در چنین حالتی خطایی پرتاب می شود.

    پیکربندی تست ها #

    پرش از تست #

    اگر هنوز یک تست ، گروه یا کل مجموعه کار نمی کند ، و شما فقط می خواهید که شکایت خود را متوقف کند ، می توانید آن را به عنوان "پرش" علامت گذاری کنید. آزمون یا تست ها اجرا نمی شوند ، و اگر دلیلی را ارائه دهید ، این دلیل چاپ می شود. به طور کلی ، آزمایش های پرش نشان می دهد که آنها باید اجرا شوند اما به طور موقت کار نمی کنند. اگر آنها اساساً با یک پلتفرم ناسازگار باشند ، به جای آن باید از Teston / Teston استفاده شود.

    برای پرش از یک مجموعه تست ، حاشیه نویسی SKIP را در بالای پرونده قرار دهید:

    رشته ای که می گذرانید باید توصیف کند که چرا تست از آن رد شده است. شما لازم نیست که آن را درج کنید ، اما ایده خوبی است که چرا این آزمایش در حال اجرا نیست.

    گروه ها و تست های فردی را می توان با عبور از پارامتر SKIP رد کرد. این می تواند درست باشد یا رشته ای که توضیح می دهد چرا آزمایش از بین رفته است. مثلا:

    Timeouts #

    به طور پیش فرض ، آزمایش ها پس از 30 ثانیه عدم تحرک ، از بین می روند. مدت زمان بندی مربوط به بن بست یا مواردی است که آزمایش از پیشرفت متوقف می شود ، اطمینان نمی دهد که یک مورد تست کلی یا مجموعه تست در هر زمان مشخص تکمیل می شود.

    Timeouts را می توان به صورت هر آزمون ، گروه ی ا-گروه تنظیم کرد. برای تغییر زمان یک مجموعه تست ، یک حاشیه نویسی Timeout را در بالای پرونده قرار دهید:

    علاوه بر تنظیم یک زمان بندی مطلق ، می توانید زمان بندی را نسبت به پیش فرض با استفاده از @timeout. factor تنظیم کنید. به عنوان مثال ، @timeout. factor (1. 5) زمان بندی را به یک و نیم برابر بیشتر از پیش فرض 45 ثانیه تنظیم می کند.

    Timeouts را می توان برای آزمایش ها و گروه ها با استفاده از پارامتر Timeout تنظیم کرد. این پارامتر دقیقاً مانند حاشیه نویسی ، یک شیء تایم را می گیرد. مثلا:

    زمان های تو در تو به ترتیب از بیرونی تا درونی استفاده می شود. این بدان معناست که "حتی تست کندتر" دو دقیقه طول خواهد کشید ، زیرا این گروه را با 2 ضرب می کند.

    پیکربندی خاص سیستم عامل #

    گاهی اوقات ممکن است یک آزمایش برای سیستم عامل های مختلف به گونه ای متفاوت پیکربندی شود. ویندوز ممکن است کد شما را نسبت به سایر سیستم عامل ها کندتر کند ، یا ممکن است دستکاری DOM شما هنوز روی سافاری کار نکند. برای این موارد ، می توانید از حاشیه نویسی onplatform و پارامتر نامگذاری شده onplatform برای تست () و گروه () استفاده کنید. مثلا:

    هم حاشیه نویسی و هم پارامتر نقشه می گیرند. کلیدهای نقشه انتخاب کننده های پلتفرم هستند که سیستم عامل هایی را که پیکربندی تخصصی برای آن اعمال می شود ، توصیف می کنند. مقادیر آن نمونه هایی از برخی از کلاسهای حاشیه نویسی است که می تواند برای یک مجموعه استفاده شود: پرش و زمان. یک مقدار همچنین می تواند لیستی از این مقادیر باشد.

    اگر چندین سیستم عامل مطابقت داشته باشند ، پیکربندی به ترتیب از اول تا آخر اعمال می شود ، دقیقاً همانطور که در گروه های تو در تو قرار دارد. این بدان معنی است که برای پیکربندی مانند زمان های مبتنی بر مدت زمان ، آخرین مقدار تطبیق برنده می شود.

    همچنین می توانید با استفاده از فایل پیکربندی بسته ، پیکربندی اختصاصی پلت فرم جهانی را تنظیم کنید.

    تست های برچسب زدن #

    برچسب ها رشته های کوتاهی هستند که می توانید با تست ها ، گروه ها و سوئیت ها در ارتباط باشید. آنها هیچ معنای داخلی ندارند ، اما با این وجود بسیار مفید هستند: شما می توانید پیکربندی سفارشی خود را با آنها مرتبط کنید ، یا می توانید از آنها برای فیلتر کردن تست های به راحتی استفاده کنید ، بنابراین فقط موارد مورد نیاز خود را اجرا می کنید.

    برچسب ها با استفاده از حاشیه نویسی tags برای سوئیت ها و برچسب های نامگذاری شده پارامتر برای تست () و گروه () تعریف می شوند. مثلا:

    اگر Runner Test با برچسب ای روبرو شود که در پرونده پیکربندی بسته اعلام نشده است ، یک هشدار را چاپ می کند ، بنابراین حتماً تمام برچسب های خود را در آنجا قرار دهید. همچنین می توانید از پرونده برای تهیه پیکربندی پیش فرض برای برچسب ها استفاده کنید ، مانند ارائه تمام تست های مرورگر دو برابر بیشتر از زمان خود.

    با عبور از پرچم های خط فرمان ، می توان تست ها را بر اساس برچسب های آنها فیلتر کرد. پرچ م-برچسب ها ی ا-t باعث می شود که دونده آزمون فقط با برچسب های داده شده تست ها را اجرا کند ، و پرچم ها ی-برچسب های ی ا-x باعث می شود که فقط بدون برچسب های داده شده تست ها را اجرا کند. این پرچم ها همچنین از نحو انتخاب بولی پشتیبانی می کنند. به عنوان مثال ، می توانید برای انتخاب تست های سریع کروم یا فایرفاکس ، از برچسب های "(Chrome || Firefox) و & & lead" عبور کنید.

    توجه داشته باشید که برچسب ها باید شناسه دارت معتبر باشند ، اگرچه ممکن است حاوی Hyphens نیز باشد.

    پیکربندی تمام بسته #

    برای پیکربندی که در چندین پرونده یا حتی کل بسته اعمال می شود ، تست از یک فایل پیکربندی به نام DART_TEST. YAML پشتیبانی می کند. در ساده ترین آن ، این پرونده می تواند شامل همان نوع پیکربندی باشد که می تواند به عنوان آرگومان های خط فرمان منتقل شود:

    پرونده پیکربندی پیش فرض های جدید را تنظیم می کند. این پیش فرض ها هنوز هم می توانند با آرگومان های خط فرمان ، دقیقاً مانند پیش فرض های داخلی ، نادیده بگیرند. در مثال بالا ، می توانید از Firefox عبور کنید تا روی Firefox اجرا شود.

    یک فایل پیکربندی می تواند خیلی بیشتر از تنظیم پیش فرض های جهانی انجام دهد. برای اطلاعات بیشتر به مستندات کامل مراجعه کنید.

    پرچم های کامپایلر #

    دونده آزمون از پرچم های هدف کلی برای کنترل تدوین مانن د-D تعریف می کند یا پرچم هایی مانند-ایمنی بدون صدا. در بیشتر موارد ، از نوشتن تست هایی که به پیکربندی کامپایلر ریز دانه بستگی دارد ، ترجیح داده می شود. به عنوان مثال برای انتخاب بین امنیت و ایمنی تهی نامناسب ، ترجیح می دهید برای هر آزمون یک نسخه زبانی را انتخاب کنید که به طور پیش فرض رفتار مورد نظر را داشته باشد - یک نسخه زبانی زیر 2. 12 را انتخاب کنید تا امنیت تهی صدا را غیرفعال کنید و یک نسخه زبان بالاتر از 2. 12 برای فعال کردن صدا NULLایمنیهنگامی که پیکربندی ریز و درشت اجتناب ناپذیر است ، رویکرد بر اساس پلتفرم متفاوت است.

    تدوین برای تست های مرورگر و گره را می توان با انتقال آرگومان به DART کامپایل JS با گزینه های-dart2js-args تنظیم کرد.

    پیکربندی تلفیقی ریز دانه برای VM پشتیبانی نمی شود. هر پیکربندی که بر رفتار زمان اجرا برای کل VM تأثیر می گذارد ، مانن د-D تعریف می کند (در صورت استفاده برای مقادیر غیر کنست) و آزمایش رفتار زمان اجرا ، هم بر دونده آزمون و هم ایزوله های تخم ریزی شده برای اجرای مجموعه های آزمایشی تأثیر می گذارد. آزمایشاتی که در حال شکستن هستند ممکن است باعث ناسازگاری با دونده آزمون شود. این موارد ممکن است با یک متغیر محیط DART_VM_OPTIONS هنگام اجرای با تست Pub Run یا با انتقال آنها به دستور DART قبل از زیر مجموعه تست هنگام استفاده از تست DART مشخص شود.

    اشکال زدایی #

    آزمایشات را می توان با استفاده از ابزارهای توسعه داخلی سیستم عامل ها به صورت تعاملی اشکال زدایی کرد. آزمایشاتی که در مرورگرها انجام می شود می توانند از کنسول های توسعه آن مرورگرها برای بازرسی از سند ، تنظیم نقاط شکست و قدم زدن در کد استفاده کنند. کسانی که در DART VM کار می کنند از رصدخانه DART استفاده می کنند.

    اولین قدم هنگام اشکال زدایی ، انتقال پرچم-پس از بار پس از بار به دونده آزمون است. این مرورگر را بعد از بارگیری هر مجموعه تست متوقف می کند ، به طوری که شما وقت دارید تا ابزارهای توسعه را باز کرده و نقاط شکست را تنظیم کنید. برای DART VM ، URL Depote Debugger را چاپ می کند.

    پس از تنظیم نقاط شکست ، یا روی Arrow Big در وسط صفحه وب کلیک کنید یا Enter را در ترمینال خود فشار دهید تا تست ها در حال اجرا باشند. هنگامی که شما به یک نقطه شکست ضربه می زنید ، دونده کنسول اشکال زدایی خود را در ترمینال باز می کند که نحوه اجرای تست ها را کنترل می کند. شما می توانید "راه اندازی مجدد" را در آنجا تایپ کنید تا آزمایش خود را هر چند بار دوباره انجام دهید تا بفهمید چه خبر است.

    به طور معمول ، تست های مرورگر در iframes پنهان اجرا می شوند. با این حال ، هنگام اشکال زدایی ، iframe برای مجموعه تست فعلی برای پر کردن پنجره مرورگر گسترش می یابد تا بتوانید با هر HTML که در آن ارائه می شود ، مشاهده و تعامل داشته باشید. توجه داشته باشید که انیمیشن DART هنوز هم ممکن است در پشت Iframe قابل مشاهده باشد. برای پنهان کردن آن ، فقط یک رنگ پس زمینه را به HTML صفحه اضافه کنید.

    تست های ترکیبی مرورگر/VM #

    کدی که برای مرورگر نوشته شده است ، اغلب باید با نوعی سرور صحبت کند. شاید شما در حال آزمایش HTML توسط برنامه خود باشید ، یا شاید در حال نوشتن کتابخانه ای هستید که از طریق وب سایت ها ارتباط برقرار می کند. ما با تست هایی تماس می گیریم که کد را در هر دو مرورگر و تست های ترکیبی VM اجرا می کنند.

    تست های ترکیبی از یکی از دو عملکرد استفاده می کنند: Spawnhybridcode () و Spawnhybriduri (). هر دوی این ایزوله های DART VM Spawn که می توانند DART را وارد کنند: IO و سایر کتابخانه های VM. تنها تفاوت در جایی است که کد موجود از ایزوله از آن ناشی می شود: spawnhybridcode () یک تکه از کد دارت واقعی را می گیرد ، در حالی که Spawnhybriduri () یک URL می گیرد. هر دوی آنها یک کانال جریان را که با ایزوله هیبریدی ارتباط برقرار می کند ، برمی گردانند. مثلا:

    

    توجه: اگر تست های ترکیبی را می نویسید ، حتماً به بسته stream_channel وابستگی اضافه کنید ، زیرا از API آن استفاده می کنید!

    پشتیبانی از سایر بسته های #

    build_runner #

    اگر از Package استفاده می کنید: Build_Runner برای ساخت بسته خود ، در این صورت به Build_Test در Dev_Dependencies خود به وابستگی نیاز خواهید داشت ، و سپس می توانید برای اجرای تست ها از دستور تست Pub Run Build_Runner استفاده کنید.

    برای تهیه آرگومان برای بسته بندی: آزمایش ، باید آنها را از استدلال های ساخت خود با یک استدلال - جدا کنید. به عنوان مثال ، اجرای تمام تست های وب در حالت انتشار به نظر می رسد مانند این میخانه Run Build_Runner - -Release --P VM.

    term_glyph #

    بسته term_glyph گیرنده های یونیکد گلیف با گزینه های ASCII را فراهم می کند. تست تضمین می کند که در هنگام کار کاربر در ویندوز ، جایی که Unicode پشتیبانی نمی شود ، برای تولید ASCII پیکربندی شده است. این تضمین می کند که آزمایش کتابخانه ها می توانند از Unicode در سیستم عامل های POSIX بدون شکستن کاربران ویندوز استفاده کنند.

    بیشتر خواندن #

    برای کسب اطلاعات دقیق در مورد کلیه کارکردهای موجود در آزمون ، اسناد API را بررسی کنید.

    دونده تست همچنین از یک گزارشگر مبتنی بر JSON قابل خواندن از دستگاه پشتیبانی می کند. این گزارشگر اجازه می دهد تا دونده آزمون پیچیده شود و پیشرفت آن به روش های سفارشی (به عنوان مثال ، در IDE) ارائه شود. برای اطلاعات بیشتر به مستندات پروتکل مراجعه کنید.