CARGO-TEST(1) General Commands Manual CARGO-TEST(1)

cargo-test - اجرای آزمون‌های واحد و یکپارچه‌سازی بسته در پروژه‌های Rust

cargo test [گزینه‌ها] [نام_آزمون] [-- گزینه‌های_آزمون]

کامپایل و اجرای آزمون‌های واحد (Unit)، یکپارچه‌سازی (Integration) و مستندات (Doc tests).

آرگومان فیلتر کردن آزمون TESTNAME و تمامی آرگومان‌های پس از دو خط تیره (--) به باینری‌های آزمون و در نتیجه به libtest (چارچوب داخلی rustc برای آزمون‌های واحد و بنچمارک‌های خرد) ارسال می‌شوند. اگر آرگومان‌ها را هم به Cargo و هم به باینری ارسال می‌کنید، مواردی که پس از -- می‌آیند به باینری و موارد قبل از آن به Cargo ارسال می‌شوند. برای جزئیات درباره آرگومان‌های libtest خروجی cargo test -- --help را مشاهده کنید و فصل مربوط به نحوه کارکرد آزمون‌ها در کتاب rustc را در نشانی https://doc.rust-lang.org/rustc/tests/index.html بررسی کنید.

به عنوان مثال، این دستور آزمون‌هایی را که شامل foo در نام خود هستند فیلتر کرده و آن‌ها را به صورت موازی روی ۳ ریسه (Thread) اجرا می‌کند:

cargo test foo -- --test-threads 3

آزمون‌ها با گزینه --test برای rustc ساخته می‌شوند که با لینک کردن کد شما با libtest یک فایل اجرایی ویژه ایجاد می‌کند. این فایل اجرایی به صورت خودکار تمامی توابعی را که با صفت #[test] نشانه‌گذاری شده‌اند روی چندین ریسه اجرا می‌کند. توابع نشانه‌گذاری‌شده با #[bench] نیز با یک تکرار اجرا می‌شوند تا عملکرد صحیح آن‌ها تأیید شود.

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

بستر اجرایی libtest را می‌توان با تنظیم harness = false در تنظیمات مانیفست هدف غیرفعال کرد؛ در این صورت کد شما باید تابع main اختصاصی خود را برای مدیریت اجرای آزمون‌ها ارائه دهد.

آزمون‌های مستندات نیز به صورت پیش‌فرض اجرا می‌شوند که مدیریت آن بر عهده rustdoc است. این ابزار نمونه‌کدها را از کامنت‌های مستنداتی هدف کتابخانه استخراج کرده و سپس آن‌ها را اجرا می‌کند.

برخلاف اهداف آزمون معمولی، هر بلوک کد با rustc در لحظه به یک فایل اجرایی doctest کامپایل می‌شود. این فایل‌های اجرایی به صورت موازی در فرآیندهای جداگانه اجرا می‌شوند. کامپایل یک بلوک کد در واقع بخشی از تابع آزمون است که توسط libtest کنترل می‌شود، بنابراین برخی گزینه‌ها مانند --jobs ممکن است بی‌اثر باشند. توجه داشته باشید که این مدل اجرای doctest تضمین‌شده نیست و ممکن است در آینده تغییر کند؛ از وابستگی به آن خودداری کنید.

برای اطلاعات بیشتر درباره نوشتن آزمون‌های مستندات به کتاب rustdoc در نشانی https://doc.rust-lang.org/rustdoc مراجعه کنید.

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

برای آزمون‌های مستندات، دایرکتوری کاری هنگام فراخوانی rustdoc روی دایرکتوری ریشه فضای کاری (Workspace) تنظیم می‌شود و همچنین همان دایرکتوری است که rustdoc به عنوان دایرکتوری کامپایل هر آزمون مستندات استفاده می‌کند. دایرکتوری کاری هنگام اجرای هر آزمون مستندات روی دایرکتوری ریشه بسته‌ای که آزمون به آن تعلق دارد تنظیم می‌شود و از طریق گزینه --test-run-directory در rustdoc کنترل می‌شود.

--no-run

کامپایل کردن آزمون‌ها بدون اجرای آن‌ها.

--no-fail-fast

اجرای تمامی آزمون‌ها صرف‌نظر از شکست هر کدام. بدون این فلگ، Cargo پس از شکست اولین فایل اجرایی متوقف می‌شود. بستر آزمون Rust تمامی آزمون‌های درون فایل اجرایی را تا انتها اجرا خواهد کرد؛ این فلگ تنها برای فایل اجرایی به عنوان یک کل اعمال می‌شود.

به صورت پیش‌فرض، هنگامی که هیچ گزینه انتخابی برای بسته مشخص نشده باشد، بسته‌های انتخاب‌شده به فایل مانیفست انتخاب‌شده بستگی دارند (بر اساس دایرکتوری کاری جاری اگر --manifest-path داده نشده باشد). اگر مانیفست ریشه یک فضای کاری باشد، اعضای پیش‌فرض فضای کاری انتخاب می‌شوند، در غیر این صورت تنها بسته تعریف‌شده توسط مانیفست انتخاب خواهد شد.

اعضای پیش‌فرض یک فضای کاری را می‌توان با کلید workspace.default-members در مانیفست ریشه به صراحت تنظیم کرد. اگر این کلید تنظیم نشده باشد، یک فضای کاری مجازی شامل همه اعضای فضای کاری خواهد بود (معادل ارسال --workspace)، و یک فضای کاری غیرمجازی فقط شامل خود کریت (Crate) ریشه خواهد بود.

-p spec…, --package spec…

آزمون تنها بسته‌های مشخص‌شده. برای قالب SPEC به cargo-pkgid(1) مراجعه کنید. این فلگ ممکن است چندین بار مشخص شود و از الگوهای عمومی glob یونیکس مانند *، ? و [] پشتیبانی می‌کند. با این حال، برای جلوگیری از بسط تصادفی الگوهای glob توسط شل پیش از پردازش توسط Cargo، باید در اطراف هر الگو از نقل‌قول تکی یا دوتایی استفاده کنید.

--workspace

آزمون تمام اعضای موجود در فضای کاری.

--all

نام مستعار منسوخ‌شده برای --workspace.

--exclude SPEC…

مستثنی کردن بسته‌های مشخص‌شده. باید همراه با فلگ --workspace استفاده شود. این فلگ ممکن است چندین بار مشخص شود و از الگوهای عمومی glob یونیکس مانند *، ? و [] پشتیبانی می‌کند. با این حال، برای جلوگیری از بسط تصادفی الگوهای glob توسط شل پیش از پردازش توسط Cargo، باید در اطراف هر الگو از نقل‌قول تکی یا دوتایی استفاده کنید.

هنگامی که هیچ گزینه‌ای برای انتخاب هدف مشخص نشده باشد، cargo test اهداف زیر از بسته‌های انتخاب‌شده را می‌سازد:

•lib — برای لینک با باینری‌ها، مثال‌ها، آزمون‌های یکپارچه‌سازی و آزمون‌های مستندات استفاده می‌شود
•bins (تنها در صورتی که آزمون‌های یکپارچه‌سازی ساخته شوند و ویژگی‌های مورد نیاز در دسترس باشند)
•examples — برای اطمینان از کامپایل شدن آن‌ها
•lib به عنوان یک آزمون واحد
•bins به عنوان آزمون‌های واحد
•آزمون‌های یکپارچه‌سازی (integration tests)
•آزمون‌های مستندات برای هدف lib

رفتار پیش‌فرض را می‌توان با تنظیم فلگ test برای هدف در تنظیمات مانیفست تغییر داد. تنظیم مثال‌ها روی test = true مثال را به عنوان یک آزمون ساخته و اجرا می‌کند و تابع main مثال را با بستر libtest جایگزین می‌کند. اگر نمی‌خواهید تابع main جایگزین شود، مقدار harness = false را نیز اضافه کنید؛ در این صورت مثال همان‌طور که هست ساخته و اجرا می‌شود.

تنظیم اهداف روی test = false از آزموده شدن آن‌ها به صورت پیش‌فرض جلوگیری می‌کند. گزینه‌های انتخاب هدف که یک هدف را با نام دریافت می‌کنند (مانند --example foo) فلگ test را نادیده گرفته و همیشه هدف داده‌شده را آزمایش می‌کنند.

آزمون‌های مستندات کتابخانه‌ها را می‌توان با تنظیم doctest = false برای کتابخانه در مانیفست غیرفعال کرد.

برای اطلاعات بیشتر در مورد تنظیمات هر هدف، به بخش پیکربندی یک هدف در نشانی https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target مراجعه کنید.

اگر یک آزمون یکپارچه‌سازی یا بنچمارک برای آزمایش انتخاب شده باشد، اهداف باینری به صورت خودکار ساخته می‌شوند. این به آزمون یکپارچه‌سازی اجازه می‌دهد باینری را اجرا کرده تا رفتار آن را بررسی و آزمایش کند. متغیر محیطی CARGO_BIN_EXE_<name> (مشاهده در https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) هنگام ساخت و اجرای آزمون یکپارچه‌سازی تنظیم می‌شود تا بتواند با استفاده از ماکروی env در https://doc.rust-lang.org/std/macro.env.html یا تابع var در https://doc.rust-lang.org/std/env/fn.var.html مکان فایل اجرایی را پیدا کند.

ارسال فلگ‌های انتخاب هدف، تنها اهداف مشخص‌شده را آزمایش می‌کند.

توجه داشته باشید که فلگ‌های --bin، --example، --test و --bench نیز از الگوهای عمومی glob یونیکس مانند *، ? و [] پشتیبانی می‌کنند. با این حال، برای جلوگیری از بسط تصادفی الگوهای glob توسط شل پیش از پردازش توسط Cargo، باید در اطراف هر الگوی glob از نقل‌قول تکی یا دوتایی استفاده کنید.

--lib

آزمون کتابخانه بسته.

--bin name…

آزمون باینری مشخص‌شده. این فلگ ممکن است چندین بار مشخص شود و از الگوهای عمومی glob یونیکس پشتیبانی می‌کند.

--bins

آزمون تمام اهداف باینری.

--example name…

آزمون مثال مشخص‌شده. این فلگ ممکن است چندین بار مشخص شود و از الگوهای عمومی glob یونیکس پشتیبانی می‌کند.

--examples

آزمون تمام اهداف مثال.

--test name…

آزمون آزمون یکپارچه‌سازی مشخص‌شده. این فلگ ممکن است چندین بار مشخص شود و از الگوهای عمومی glob یونیکس پشتیبانی می‌کند.

--tests

آزمون تمام اهدافی که فلگ مانیفست test = true برای آن‌ها تنظیم شده است. به طور پیش‌فرض این شامل کتابخانه و باینری‌های ساخته‌شده به عنوان آزمون‌های واحد، و آزمون‌های یکپارچه‌سازی است. توجه داشته باشید که این کار هرگونه وابستگی مورد نیاز را نیز می‌سازد، بنابراین هدف lib ممکن است دو بار ساخته شود (یک بار به عنوان آزمون واحد، و یک بار به عنوان وابستگی برای باینری‌ها، آزمون‌های یکپارچه‌سازی و غیره). اهداف را می‌توان با تنظیم فلگ test در تنظیمات مانیفست هدف فعال یا غیرفعال کرد.

--bench name…

آزمون بنچمارک مشخص‌شده. این فلگ ممکن است چندین بار مشخص شود و از الگوهای عمومی glob یونیکس پشتیبانی می‌کند.

--benches

آزمون تمام اهدافی که فلگ مانیفست bench = true برای آن‌ها تنظیم شده است. به طور پیش‌فرض این شامل کتابخانه و باینری‌های ساخته‌شده به عنوان بنچمارک، و اهداف bench است. توجه داشته باشید که این کار هرگونه وابستگی مورد نیاز را نیز می‌سازد، بنابراین هدف lib ممکن است دو بار ساخته شود (یک بار به عنوان بنچمارک، و یک بار به عنوان وابستگی برای باینری‌ها، بنچمارک‌ها و غیره). اهداف را می‌توان با تنظیم فلگ bench در تنظیمات مانیفست هدف فعال یا غیرفعال کرد.

--all-targets

آزمون تمام اهداف. این معادل مشخص کردن --lib --bins --tests --benches --examples است.

--doc

آزمون تنها مستندات کتابخانه. این گزینه نمی‌تواند با سایر گزینه‌های هدف ترکیب شود.

فلگ‌های ویژگی به شما اجازه می‌دهند کنترل کنید کدام ویژگی‌ها فعال باشند. هنگامی که هیچ گزینه ویژگی مشخص نشده باشد، ویژگی default برای هر بسته انتخاب‌شده فعال می‌شود.

برای جزئیات بیشتر به مستندات ویژگی‌ها در نشانی https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options مراجعه کنید.

-F features, --features features

فهرست جداشده با فاصله یا کاما از ویژگی‌ها برای فعال‌سازی. ویژگی‌های اعضای فضای کاری را می‌توان با نحو package-name/feature-name فعال کرد. این فلگ ممکن است چندین بار مشخص شود که تمام ویژگی‌های مشخص‌شده را فعال می‌کند.

--all-features

فعال‌سازی تمام ویژگی‌های موجود در تمام بسته‌های انتخاب‌شده.

--no-default-features

عدم فعال‌سازی ویژگی default در بسته‌های انتخاب‌شده.

--target triple

آزمون برای معماری هدف مشخص‌شده. این فلگ ممکن است چندین بار مشخص شود. پیش‌فرض معماری میزبان است. ساختار کلی سه‌گانه (Triple) به صورت <arch><sub>-<vendor>-<sys>-<abi> است.

مقادیر ممکن:

•هر هدف پشتیبانی‌شده در rustc --print target-list.
•"host-tuple"، که در داخل با هدف میزبان جایگزین خواهد شد. این گزینه به‌ویژه زمانی مفید است که برخی کریت‌ها را به صورت چندسکویی (Cross-compile) کامپایل می‌کنید و نمی‌خواهید ماشین میزبان خود را به عنوان هدف مشخص کنید (به عنوان مثال، یک xtask در یک پروژه مشترک که ممکن است روی چندین میزبان مختلف توسعه داده شود).
•یک مسیر به فایل مشخصات هدف سفارشی. برای اطلاعات بیشتر به بخش Masir Jostojuye Hadafe Sefareshi در https://doc.rust-lang.org/rustc/targets/custom.html#custom-target-lookup-path مراجعه کنید.

این مقدار همچنین می‌تواند با مقدار پیکربندی build.target در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود.

توجه داشته باشید که مشخص کردن این فلگ باعث می‌شود Cargo در حالت متفاوتی اجرا شود که در آن مصنوعات هدف در یک دایرکتوری جداگانه قرار می‌گیرند. برای جزئیات بیشتر به مستندات حافظه موقت ساخت (build cache) در نشانی https://doc.rust-lang.org/cargo/reference/build-cache.html مراجعه کنید.

-r, --release

آزمون مصنوعات بهینه‌سازی‌شده با پروفایل release. همچنین گزینه --profile را برای انتخاب یک پروفایل خاص بر اساس نام ببینید.

--profile name

آزمون با پروفایل داده‌شده. برای جزئیات بیشتر درباره پروفایل‌ها به مرجع پروفایل‌ها در نشانی https://doc.rust-lang.org/cargo/reference/profiles.html مراجعه کنید.

--timings

خروجی دادن اطلاعات مربوط به مدت زمان هر کامپایل و ردیابی اطلاعات همزمانی در طول زمان.

یک فایل cargo-timing.html در پایان ساخت در دایرکتوری target/cargo-timings نوشته خواهد شد. اگر مایل به بررسی اجرای قبلی باشید، یک گزارش اضافی همراه با برچسب زمان در نام فایل آن نیز نوشته می‌شود. این گزارش‌ها صرفاً برای مطالعه انسانی مناسب هستند و داده‌های زمان‌بندی خواندنی توسط ماشین ارائه نمی‌دهند.

--target-dir directory

دایرکتوری برای تمامی مصنوعات تولیدشده و فایل‌های میانی. همچنین می‌تواند با متغیر محیطی CARGO_TARGET_DIR یا مقدار پیکربندی build.target-dir در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود. پیش‌فرض target در ریشه فضای کاری است.

به صورت پیش‌فرض، بستر آزمون Rust خروجی حاصل از اجرای آزمون را پنهان می‌کند تا نتایج خوانا باقی بمانند. خروجی آزمون را می‌توان با ارسال --no-capture به باینری‌های آزمون بازیابی کرد (مثلاً برای اشکال‌زدایی):

cargo test -- --no-capture

-v, --verbose

استفاده از خروجی با جزئیات. می‌تواند دو بار برای خروجی «بسیار باجزئیات» مشخص شود که شامل خروجی‌های اضافی مانند هشدارهای وابستگی و خروجی اسکریپت ساخت است. همچنین می‌تواند با مقدار پیکربندی term.verbose در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود.

-q, --quiet

عدم چاپ پیام‌های لاگ cargo. همچنین می‌تواند با مقدار پیکربندی term.quiet در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود.

--color when

کنترل زمان استفاده از خروجی رنگی. مقادیر معتبر:
•auto (پیش‌فرض): تشخیص خودکار در دسترس بودن پشتیبانی از رنگ در ترمینال.
•always: نمایش همیشگی رنگ‌ها.
•never: عدم نمایش رنگ‌ها در هیچ شرایطی.

همچنین می‌تواند با مقدار پیکربندی term.color در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود.

--message-format fmt

قالب خروجی برای پیام‌های تشخیصی. می‌تواند چندین بار مشخص شود و شامل مقادیر جداشده با کاما است. مقادیر معتبر:
•human (پیش‌فرض): نمایش در قالب متنی خوانا برای انسان. با short و json تداخل دارد.
•short: انتشار پیام‌های متنی کوتاه‌تر و خوانا برای انسان. با human و json تداخل دارد.
•json: انتشار پیام‌های JSON در خروجی استاندارد (stdout). برای جزئیات بیشتر به مرجع در نشانی https://doc.rust-lang.org/cargo/reference/external-tools.html#json-messages مراجعه کنید. با human و short تداخل دارد.
•json-diagnostic-short: تضمین می‌کند که فیلد rendered در پیام‌های JSON شامل رندر «کوتاه» از rustc باشد. با human یا short قابل استفاده نیست.
•json-diagnostic-rendered-ansi: تضمین می‌کند که فیلد rendered در پیام‌های JSON شامل کدهای رنگی توکار ANSI برای رعایت طرح رنگی پیش‌فرض rustc باشد. با human یا short قابل استفاده نیست.
•json-render-diagnostics: به Cargo دستور می‌دهد که پیام‌های تشخیصی rustc را در پیام‌های JSON چاپ نکند، بلکه خود Cargo پیام‌های تشخیصی JSON ارائه‌شده از rustc را رندر کند. پیام‌های تشخیصی JSON اختصاصی Cargo و سایر پیام‌های ناشی از rustc همچنان منتشر می‌شوند. با human یا short قابل استفاده نیست.

--manifest-path path

مسیر فایل Cargo.toml. به صورت پیش‌فرض، Cargo فایل Cargo.toml را در دایرکتوری جاری یا هر یک از دایرکتوری‌های والد جستجو می‌کند.

--ignore-rust-version

نادیده گرفتن مشخصات rust-version در بسته‌ها.

--locked

تأیید می‌کند که دقیقاً از همان وابستگی‌ها و نسخه‌هایی استفاده شود که هنگام ایجاد اولیه فایل Cargo.lock تولید شده بودند. در صورت بروز هر یک از سناریوهای زیر، Cargo با خطا خارج خواهد شد:
•فایل lock موجود نباشد.
•برنامه Cargo به دلیل تفکیک متفاوت وابستگی‌ها تلاش کند فایل lock را تغییر دهد.

این گزینه می‌تواند در محیط‌هایی که ساخت قطعی و تکرارپذیر مورد نظر است، مانند خطوط لوله CI، استفاده شود.

--offline

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

توجه داشته باشید که این ممکن است به حل وابستگی متفاوتی نسبت به حالت آنلاین منجر شود. Cargo خود را به کریت‌هایی محدود می‌کند که به صورت محلی بارگیری شده‌اند، حتی اگر نسخه جدیدتری همان‌طور که در نسخه محلی ایندکس مشخص شده است وجود داشته باشد. برای بارگیری وابستگی‌ها قبل از آفلاین شدن، به دستور cargo-fetch(1) مراجعه کنید.

همچنین می‌تواند با مقدار پیکربندی net.offline در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود.

--frozen

معادل مشخص کردن هر دو گزینه --locked و --offline به طور همزمان.

+toolchain

اگر Cargo با rustup نصب شده باشد و اولین آرگومان به cargo با + آغاز شود، به عنوان نام زنجیره ابزار rustup (مانند +stable یا +nightly) تفسیر خواهد شد. برای اطلاعات بیشتر درباره نحوه کارکرد لغو زنجیره ابزار، به مستندات rustup در نشانی https://rust-lang.github.io/rustup/overrides.html مراجعه کنید.

--config KEY=VALUE یا PATH

بازنویسی یک مقدار پیکربندی Cargo. آرگومان باید در نحو TOML به صورت KEY=VALUE باشد، یا به عنوان مسیری به یک فایل پیکربندی اضافی ارائه شود. این فلگ ممکن است چندین بار مشخص شود. برای اطلاعات بیشتر به بخش لغوهای خط فرمان در نشانی https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides مراجعه کنید.

-C PATH

تغییر دایرکتوری کاری جاری قبل از اجرای هرگونه عملیات مشخص‌شده. این گزینه بر مواردی مانند جایی که cargo به طور پیش‌فرض به دنبال مانیفست پروژه (Cargo.toml) می‌گردد، و همچنین دایرکتوری‌های جستجوشده برای کشف .cargo/config.toml تأثیر می‌گذارد. این گزینه باید قبل از نام دستور ظاهر شود، به عنوان مثال cargo -C path/to/my-project build.

این گزینه تنها در کانال nightly در https://doc.rust-lang.org/book/appendix-07-nightly-rust.html در دسترس است و برای فعال‌سازی به فلگ -Z unstable-options نیاز دارد (مشاهده #10098 در https://github.com/rust-lang/cargo/issues/10098).

-h, --help

چاپ اطلاعات راهنما.

-Z flag

فلگ‌های ناپایدار (تنها در نسخه nightly) برای Cargo. برای جزئیات دستور cargo -Z help را اجرا کنید.

آرگومان --jobs بر ساخت فایل اجرایی آزمون تأثیر می‌گذارد اما بر تعداد ریسه‌های مورد استفاده هنگام اجرای آزمون‌ها تأثیری ندارد. بستر آزمون Rust شامل گزینه‌ای برای کنترل تعداد ریسه‌های استفاده‌شده است:

cargo test -j 2 -- --test-threads=2

-j N, --jobs N

تعداد کارهای موازی برای اجرا. همچنین می‌تواند با مقدار پیکربندی build.jobs در https://doc.rust-lang.org/cargo/reference/config.html مشخص شود. پیش‌فرض تعداد پردازنده‌های منطقی است. اگر منفی باشد، حداکثر تعداد کارهای موازی را روی تعداد پردازنده‌های منطقی به علاوه مقدار ارائه‌شده تنظیم می‌کند. اگر رشته default ارائه شود، مقدار را به پیش‌فرض بازمی‌گرداند. نباید 0 باشد.

--future-incompat-report

نمایش یک گزارش عدم سازگاری آینده (future-incompat report) برای هرگونه هشدارهای ناسازگاری آینده که در طول اجرای این دستور تولید شده است.

به cargo-report(1) مراجعه کنید.

اگرچه cargo test شامل کامپایل است، اما فلگ --keep-going ارائه نمی‌دهد. از --no-fail-fast برای اجرای تا حد امکان آزمون‌های بیشتر بدون توقف در اولین شکست استفاده کنید. برای «کامپایل» تا حد امکان آزمون‌های بیشتر، از --tests برای ساخت جداگانه باینری‌های آزمون استفاده کنید. به عنوان مثال:

cargo build --tests --keep-going
cargo test --tests --no-fail-fast

برای جزئیات درباره متغیرهای محیطی که Cargo می‌خواند، به مرجع در نشانی https://doc.rust-lang.org/cargo/reference/environment-variables.html مراجعه کنید.

•0: کارگو با موفقیت پایان یافت.
•101: اجرای کارگو با شکست مواجه شد.

1.اجرای تمام آزمون‌های واحد و یکپارچه‌سازی بسته جاری: 
cargo test
2.اجرای تنها آزمون‌هایی که نام آن‌ها با رشته فیلتر مطابقت دارد: 
cargo test name_filter
3.اجرای تنها یک آزمون خاص درون یک آزمون یکپارچه‌سازی خاص: 
cargo test --test int_test_name -- modname::test_name

cargo(1), cargo-bench(1), types of tests https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests, how to write tests https://doc.rust-lang.org/rustc/tests/index.html