با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
آنچه باید آزمایش کنید به عواملی مانند نوع برنامه، تیم توسعه، میزان کدهای قدیمی و معماری استفاده شده بستگی دارد. بخش‌های زیر به تشریح مواردی می‌پردازند که یک مبتدی ممکن است بخواهد هنگام برنامه‌ریزی برای آزمایش در برنامه خود در نظر بگیرد.
سازماندهی دایرکتوری های آزمون
یک پروژه معمولی در اندروید استودیو شامل دو دایرکتوری است که بسته به محیط اجرای خود، تست ها را برگزار می کنند. تست های خود را در دایرکتوری های زیر سازماندهی کنید:
دایرکتوری androidTest باید شامل تست هایی باشد که روی دستگاه های واقعی یا مجازی اجرا می شوند. چنین تست‌هایی شامل تست‌های یکپارچه‌سازی، تست‌های سرتاسر و تست‌های دیگری است که JVM به تنهایی نمی‌تواند عملکرد برنامه شما را تایید کند.
دایرکتوری test باید شامل تست هایی باشد که روی ماشین محلی شما اجرا می شوند، مانند تست های واحد. برخلاف موارد فوق، اینها می توانند تست هایی باشند که روی یک JVM محلی اجرا می شوند.
تست های واحد ضروری
هنگام پیروی از بهترین روش، باید مطمئن شوید که از تست های واحد در موارد زیر استفاده می کنید:
تست های واحد برای ViewModels یا ارائه دهندگان.
تست های واحد برای لایه داده ، به ویژه مخازن. بیشتر لایه داده باید مستقل از پلتفرم باشد. انجام این کار باعث می شود که تست دوبل ها جایگزین ماژول های پایگاه داده و منابع داده از راه دور در تست ها شوند. راهنمای استفاده از تست دوبل در اندروید را ببینید
واحد برای سایر لایه‌های مستقل از پلتفرم مانند لایه Domain ، مانند موارد استفاده و تعامل‌ها، آزمایش می‌کند.
تست های واحد برای کلاس های کاربردی مانند دستکاری رشته و ریاضی.
موارد لبه تست
تست های واحد باید روی هر دو حالت عادی و لبه تمرکز کنند. موارد لبه سناریوهای غیرمعمولی هستند که آزمایش‌کنندگان انسانی و آزمایش‌های بزرگ‌تر بعید به دست می‌آورند. به عنوان مثال می توان به موارد زیر اشاره کرد:
عملیات ریاضی با استفاده از اعداد منفی، صفر و شرایط مرزی .
تمام خطاهای احتمالی اتصال شبکه
داده های خراب، مانند JSON نادرست.
شبیه سازی فضای ذخیره کامل هنگام ذخیره در یک فایل.
شیئی که در میانه یک فرآیند بازسازی می شود (مانند یک فعالیت در هنگام چرخش دستگاه).
تست های واحد برای اجتناب
برخی از تست های واحد به دلیل ارزش پایین آنها باید اجتناب شود:
تست‌هایی که عملکرد صحیح چارچوب یا کتابخانه را تأیید می‌کنند، نه کد شما.
نقاط ورودی چارچوب مانند فعالیت ها، قطعات یا خدمات نباید منطق تجاری داشته باشند، بنابراین تست واحد نباید در اولویت باشد. تست‌های واحد برای فعالیت‌ها ارزش کمی دارند، زیرا عمدتاً کد چارچوب را پوشش می‌دهند و نیاز به تنظیم بیشتر دارند. تست های ابزاری مانند تست های UI می توانند این کلاس ها را پوشش دهند.
تست های رابط کاربری
چندین نوع تست رابط کاربری وجود دارد که باید از آنها استفاده کنید:
تست‌های UI صفحه، تعاملات حیاتی کاربر را در یک صفحه بررسی می‌کنند. آنها اقداماتی مانند کلیک کردن روی دکمه ها، تایپ کردن در فرم ها و بررسی وضعیت های قابل مشاهده را انجام می دهند. یک کلاس تست در هر صفحه نقطه شروع خوبی است.
تست‌های جریان کاربر یا تست‌های ناوبری ، که اکثر مسیرها را پوشش می‌دهند. این تست ها حرکت کاربر را از طریق یک جریان ناوبری شبیه سازی می کنند. آنها تست های ساده ای هستند که برای بررسی خرابی های زمان اجرا در مقداردهی اولیه مفید هستند.
تست های دیگر
تست های تخصصی تری مانند تست اسکرین شات، تست عملکرد و تست میمون وجود دارد. همچنین می توانید تست ها را بر اساس هدف دسته بندی کنید، مانند رگرسیون، قابلیت دسترسی و سازگاری.
در ادامه مطلب
برای اینکه به صورت مجزا آزمایش کنید، اغلب نیاز دارید که وابستگی های موضوع مورد آزمایش را با وابستگی های ساختگی یا ساختگی جایگزین کنید، که به طور کلی «تست دو برابر» نامیده می شود. در مورد استفاده از دوبل های تست در اندروید به خواندن آنها ادامه دهید.
اگر می‌خواهید نحوه ایجاد تست‌های واحد و رابط کاربری را بیاموزید، تست‌های کدهای آزمایشی را بررسی کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
