تست در توسعه موبایل: چیست، چه انواعی دارد و چگونه سازماندهی کنیم

سطوح تست: Unit، Integration، E2E

تست واحد

تست‌های واحد اساس تست برنامه‌های موبایل هستند. آنها کوچکترین واحد کد — یک تابع، متد یا کلاس واحد — را به صورت ایزوله از بقیه سیستم تأیید می‌کنند. در توسعه موبایل، تست‌های واحد با JUnit (Android) و XCTest (iOS) نوشته می‌شوند. یک تست واحد خوب باید سریع، مستقل و تکرارپذیر باشد — نباید به شبکه، پایگاه داده یا اجزای UI وابسته باشد. برای ایزوله‌سازی از test doubles استفاده می‌شود: mock، stub و fake.

Mockito (Java/Kotlin) و MockK (Kotlin-first) کتابخانه‌های محبوب برای ایجاد اشیاء mock در Android هستند. در iOS از OCMock، Cuckoo یا پروتکل‌های دستی استفاده می‌شود. قانون: تست‌های واحد باید منطق تجاری و مدل‌های داده را پوشش دهند. تست‌های UI نباید تست‌های واحد را تکرار کنند — آنها تعامل کاربر با رابط را تأیید می‌کنند.

تست یکپارچگی

تست‌های یکپارچگی تعامل بین اجزا را تأیید می‌کنند: مخزن با پایگاه داده، ViewModel با سرویس API، ناوبری بین صفحات. برخلاف تست‌های واحد، تست‌های یکپارچگی از وابستگی‌های واقعی یا نزدیک به واقعیت استفاده می‌کنند (مثلاً پایگاه داده درون حافظه یا سرور mock). Robolectric فریم‌ورکی برای اجرای تست‌های Android روی JVM بدون شبیه‌ساز است که تست‌های یکپارچگی را 10 برابر سریع‌تر می‌کند.

تست‌های عکس فوری (Golden Tests) نوع خاصی از تست یکپارچگی هستند که یک جزء UI رندر شده را با یک تصویر مرجع (عکس فوری) مقایسه می‌کنند. اگر ظاهر تغییر کند، تست شکست می‌خورد — توسعه‌دهنده می‌بیند چه چیزی تغییر کرده است. Facebook SnapshotTestCase (iOS) و Shot (Android) ابزارهای محبوب برای تست عکس فوری هستند.

تست E2E و UI

تست‌های E2E (سرتاسر) سناریوی کامل کاربر را از ابتدا تا انتها تأیید می‌کنند: راه‌اندازی برنامه، ورود، انجام عمل، بررسی نتیجه. تست‌های UI زیرمجموعه‌ای از E2E هستند که بر رابط متمرکزند. ابزارها: Espresso (Android)، XCUITest (iOS)، Detox (React Native). تست‌های E2E کندترین هستند، بنابراین به صورت جداگانه روی CI اجرا می‌شوند — معمولاً در ساخت‌های شبانه.

ابزارهای iOS: XCTest و XCUITest

XCTest

XCTest فریم‌ورک داخلی اپل برای تست واحد برنامه‌های موبایل است. XCTestRunner تست‌ها را روی شبیه‌ساز یا دستگاه واقعی اجرا می‌کند. تست‌ها از XCTestCase ارث می‌برند، شامل setUp و tearDown برای آماده‌سازی و پاکسازی هستند. XCTest شامل XCTAssert برای تأییدها (XCTAssertEqual، XCTAssertNil، XCTAssertTrue) و XCTWaiter برای انتظار عملیات ناهمگام است.

مثال یک تست XCTest ساده: ایجاد مدل User، بررسی صحت مقداردهی اولیه، قالب‌بندی نام و محاسبه سن. پوشش کد در Xcode نشان می‌دهد کدام خطوط کد توسط تست‌ها پوشش داده شده‌اند — هدف برای پروژه‌های تجاری: حداقل 70–80٪ پوشش منطق تجاری. XCTest از طریق xcodebuild test با Xcode Server و سیستم‌های CI یکپارچه شده است.

XCUITest

XCUITest فریم‌ورک اپل برای تست UI است. از طریق شناسه‌های دسترسی کار می‌کند: XCUIElementQuery دکمه‌ها، فیلدهای ورودی، جداول را بر اساس برچسب، شناسه یا نوع پیدا می‌کند. XCUITest دنباله‌ای از اقدامات را ضبط می‌کند (ضبط/پخش) و کد تست تولید می‌کند. مهم: همه عناصر UI باید برای عملکرد پایدار تست‌ها دارای accessibilityIdentifier باشند.

ابزارهای Android: JUnit، Espresso، Robolectric

JUnit و Mockito

JUnit فریم‌ورک پایه برای تست واحد برنامه‌های موبایل روی Java/Kotlin است. در Android از JUnit 4 (آخرین نسخه پایدار 4.13.2) و JUnit 5 برای پروژه‌های جدید استفاده می‌شود. Mockito کتابخانه‌ای برای ایجاد اشیاء mock است: when(mock.method()).thenReturn(value) — یک الگوی استاندارد برای ایزوله کردن کلاس تست شده از وابستگی‌ها.

مثال تست JUnit برای Android:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso و UI Automator

Espresso فریم‌ورک گوگل برای تست‌های UI Android است. Espresso به طور خودکار با رشته UI همگام می‌شود: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso به دلیل انتظار داخلی حالت بیکار، نوشتن آسان و پایدار است. UI Automator فریم‌ورکی برای تست‌های بین برنامه‌ای است که می‌تواند با عناصر سیستم (دیالوگ‌های مجوز، سایه اعلان) تعامل داشته باشد.

ابزارهای کراس پلتفرم: Detox، Appium

Detox برای React Native

Detox یک فریم‌ورک E2E جعبه خاکستری برای تست برنامه‌های موبایل React Native از Wix است. Detox از یک پایگاه کد تست واحد روی هر دو پلتفرم کار می‌کند و در داخل از Espresso (Android) و XCUITest (iOS) استفاده می‌کند. Detox به طور خودکار منتظر می‌ماند تا برنامه بیکار شود (بدون انیمیشن، درخواست شبکه، تایمر) و تنها پس از آن اقدام بعدی را انجام می‌دهد.

Appium

Appium یک فریم‌ورک کراس پلتفرم جهانی است که از Android، iOS، Web و برنامه‌های ترکیبی پشتیبانی می‌کند. Appium از پروتکل WebDriver استفاده می‌کند و از هر زبان برنامه‌نویسی (Java، Python، JS، Ruby) پشتیبانی می‌کند. سرور Appium به عنوان یک سرور HTTP کار می‌کند که دستورات را به دستورات بومی UI Automator / XCUITest ترجمه می‌کند. اشکال اصلی Appium سرعت است: تست‌ها کندتر از Espresso یا XCUITest بومی اجرا می‌شوند.

TDD و BDD: روش‌شناسی تست

TDD: توسعه تست‌محور

TDD یک روش‌شناسی تست برنامه‌های موبایل است که در آن تست قبل از کد پیاده‌سازی نوشته می‌شود. چرخه Red-Green-Refactor: (1) تستی بنویسید که شکست می‌خورد (Red)، (2) حداقل کد را برای قبولی تست بنویسید (Green)، (3) کد را در حالی که تست قبول می‌شود، بازنویسی کنید. TDD 100٪ پوشش تست برای قابلیت جدید و معماری تمیز ارائه می‌دهد، زیرا تست اولین مشخصات نیازمندی است.

BDD: توسعه رفتارمحور

BDD توسعه‌ای از TDD است که در آن تست‌ها به زبان طبیعی در قالب Given-When-Then نوشته می‌شوند. Given (زمینه) — When (عمل) — Then (نتیجه مورد انتظار). تست‌های BDD برای همه اعضای تیم قابل درک است: توسعه‌دهندگان، تست‌کنندگان، تحلیلگران و مشتریان. Mock در مقابل Stub در مقابل Fake: Mock تعامل را تأیید می‌کند (آیا متد فراخوانی شده است)، Stub داده‌های ثابت را برمی‌گرداند، Fake یک پیاده‌سازی کاری ساده شده است (مثلاً DB درون حافظه). در IT Sectr، ما از TDD برای منطق تجاری حیاتی و از BDD برای سناریوهای پذیرش استفاده می‌کنیم.

دوگانه‌های تست نام عمومی اشیایی است که وابستگی‌های واقعی را در تست‌ها جایگزین می‌کنند. چهار نوع وجود دارد: Dummy (شیء برای پر کردن پارامترها، استفاده نمی‌شود)، Stub (مقادیر داده شده را برمی‌گرداند)، Spy (فراخوانی‌ها را برای تأیید ثبت می‌کند)، Mock (فراخوانی‌های مورد انتظار را از پیش تعریف می‌کند). درک تفاوت برای طراحی صحیح تست بسیار مهم است.

CI/CD و Device Farm

اتوماسیون تست در CI/CD

CI/CD — یکپارچگی مداوم و تحویل مداوم: عمل ساخت و تست خودکار برنامه‌های موبایل با هر تغییر کد. در توسعه موبایل، خط لوله CI/CD شامل: لینتینگ، تست‌های واحد، تست‌های یکپارچگی، ساخت APK/IPA و تست‌های UI است. GitHub Actions و Bitrise پلتفرم‌های محبوب برای CI/CD موبایل هستند. تست‌ها باید سریع اجرا شوند: تست‌های واحد در 1–2 دقیقه، یکپارچگی در 5–10، تست‌های UI در 15–30 دقیقه.

Device Farm

Device Farm مزرعه‌ای از دستگاه‌های واقعی برای تست است. Firebase Test Lab (Android) و Xcode Cloud (iOS) دسترسی ابری به صدها مدل دستگاه را فراهم می‌کنند. Device Farm مشکلاتی را آشکار می‌کند که در شبیه‌سازها قابل مشاهده نیستند: اندازه‌های مختلف صفحه، عملکرد روی دستگاه‌های قدیمی، مشکلات سازگاری. در IT Sectr، ما به طور منظم از Firebase Test Lab برای Android و Xcode Cloud برای iOS استفاده می‌کنیم.