در این مقاله یاد خواهید گرفت که چگونه از API تست waitUntil در Compose برای منتظر ماندن برای برآورده شدن شرایط خاص استفاده کنید. این جایگزین خوبی برای استفاده از Idling Resources در برخی شرایط است.

[به‌روزرسانی ۲۰۲۳] Tldr: از APIهای جدید waitUntil برای همگام‌سازی در تست‌های Compose (نسخه ۱.۴.۰+) استفاده کنید.

همگام‌سازی چیست؟

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

برای دیدن تصویر در اندازه کامل، اینتر را فشار دهید یا کلیک کنید

همگام‌سازی مکانیزمی است که به تست اجازه می‌دهد بداند چه زمانی عملیات بعدی را اجرا کند. هرچه قطعه کدی که برای تأیید انتخاب می‌کنید بزرگتر باشد، همگام‌سازی آن با تست سخت‌تر است. در تست‌های واحد، کنترل کامل اجرای کد برای تأیید آسان است. با این حال، هرچه دامنه را گسترش می‌دهیم تا کلاس‌ها، ماژول‌ها و لایه‌های بیشتری را شامل شود، برای چارچوب تست دشوار می‌شود که بداند آیا برنامه در حال انجام یک عملیات است یا خیر.

برای دیدن تصویر در اندازه کامل، اینتر را فشار دهید یا کلیک کنید

androidx.test و به تبع آن، Compose Test ، از برخی ترفندها در پس زمینه استفاده می‌کنند تا نیازی به نگرانی زیاد در مورد این موضوع نباشد. برای مثال، اگر نخ اصلی مشغول باشد، تست تا زمانی که بتواند خط بعدی را اجرا کند، متوقف می‌شود.

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

گزینه ۱: منابع بلااستفاده

منابع بیکار (idling resources) یک ویژگی Espresso هستند که به شما، به عنوان توسعه‌دهنده، اجازه می‌دهند تصمیم بگیرید چه زمانی برنامه مشغول است. شما دو راه برای استفاده از آنها دارید:

۱. نصب آنها در چارچوب یا کتابخانه‌ای که کاری را انجام می‌دهد که تست نمی‌تواند آن را ببیند.

یک مثال خوب از این مورد RxIdler است که یک زمانبند RxJava را در خود جای می‌دهد. این روش ترجیحی برای ثبت منابع Idling است زیرا به شما امکان می‌دهد تنظیمات تست خود را به طور تمیز از کد تست جدا نگه دارید.

۲. اصلاح کد تحت آزمایش برای نمایش صریح اطلاعات مربوط به مشغول بودن یا نبودن برنامه.

برای مثال، می‌توانید مخزن (یا یک نمونه آزمایشی ) خود را طوری تغییر دهید که نشان دهد هنگام بارگیری داده‌ها از یک منبع داده، مشغول است:

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

در عوض، می‌توانیم منتظر اتفاقات باشیم.

گزینه ۲: منتظر اتفاقات ماندن... به روش اشتباه

بارگذاری داده‌ها معمولاً سریع است، مخصوصاً هنگام استفاده از داده‌های جعلی، پس چرا وقتی می‌توانید تست را برای چند ثانیه به حالت خواب ببرید، وقت خود را با منابع بلااستفاده تلف کنید؟

این تست یا کندتر از حد نیاز اجرا می‌شود یا با شکست مواجه می‌شود . وقتی صدها یا هزاران تست رابط کاربری دارید، می‌خواهید تست‌ها تا حد امکان سریع باشند.

همچنین، گاهی اوقات شبیه‌سازها یا دستگاه‌ها بدرفتاری می‌کنند و دچار مشکل می‌شوند و باعث می‌شوند که آن عملیات کمی بیشتر از آن ۲۰۰۰ میلی‌ثانیه طول بکشد و ساخت شما را خراب کند. وقتی صدها تست دارید، این به یک مشکل بزرگ تبدیل می‌شود.

گزینه ۳: منتظر اتفاقات درست و حسابی ماندن!

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

در Compose، می‌توانید از تابع waitUntil استفاده کنید، که تابع دیگری را می‌گیرد که یک مقدار بولی تولید می‌کند.

به‌روزرسانی ۲۰۲۳/۰۳/۲۲: از Compose 1.4.0، مجموعه‌ای جدید از APIهای waitUntil اضافه کردیم:

[قبل از ۱.۴.۰: از این کمک‌کننده‌ها استفاده کنید: waitUntilExists ، waitUntilNodeCount ]

... و از آنها به این شکل استفاده کنید:

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

پس چه زمانی باید از آن استفاده کنید؟ یک مورد استفاده خوب برای آن، بارگذاری داده‌ها از یک observable (با LiveData، Kotlin Flow یا RxJava) است. وقتی رابط کاربری شما نیاز دارد قبل از اینکه آن را غیرفعال در نظر بگیرید، چندین به‌روزرسانی دریافت کند، ممکن است بخواهید همگام‌سازی را با استفاده از waitUntil ساده کنید.

برای مثال، وقتی یک Flow را از یک View جمع‌آوری می‌کنید:

و شما چندین مورد را به آن ارسال می‌کنید:

اگر repository مدت زمان نامشخصی طول بکشد تا اولین نتیجه را برگرداند، چارچوب تست فکر می‌کند که «در حال بارگیری» حالت بیکار (مقدار اولیه اختصاص داده شده در collectAsState ) است و با عبارت بعدی ادامه می‌دهد.

بنابراین، اگر مطمئن شوید که رابط کاربری نشانگر بارگیری را نشان نمی‌دهد، می‌توانید تست را بسیار قابل اعتمادتر کنید:

مبارک... منتظرش باشید... در حال آزمایش!

مجوز قطعه کد:

  Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0