نوشتن کد تست قابل نگهداری: فراتر از POM با اصول SOLID

در دنیای پویای توسعه نرم‌افزار، تست نویسی نقشی حیاتی در تضمین کیفیت و پایداری محصولات ایفا می‌کند. با این حال، همانند کد اصلی برنامه، کدهای تست نیز می‌توانند به مرور زمان پیچیده، شکننده و دشوار برای نگهداری شوند. الگوی طراحی Page Object Model (POM) گامی بزرگ در جهت سازماندهی و افزایش قابلیت نگهداری تست‌های UI بوده است، اما برای دستیابی به کدهای تست واقعاً پایدار و مقیاس‌پذیر، نیازمند به‌کارگیری اصول مهندسی نرم‌افزار عمیق‌تری هستیم. این مقاله به بررسی اصول و روش‌هایی فراتر از POM، با تمرکز ویژه بر کاربرد اصول SOLID در تست‌نویسی، می‌پردازد تا به شما در نوشتن کدهای تست قابل نگهداری، خوانا و کارآمد کمک کند.

چرا قابلیت نگهداری کد تست اهمیت دارد؟

قبل از پرداختن به اصول، بیایید لحظه‌ای به اهمیت قابلیت نگهداری کدهای تست بیندیشیم:

• کاهش هزینه‌ها: تست‌های قابل نگهداری به معنای زمان کمتر برای رفع اشکال تست‌های شکسته (flaky tests) و تطبیق آن‌ها با تغییرات کد اصلی است.
• افزایش اعتماد: تست‌هایی که به طور مداوم و قابل اطمینان اجرا می‌شوند، اعتماد تیم را به فرآیند توسعه و کیفیت محصول افزایش می‌دهند.
• توسعه سریع‌تر: با داشتن مجموعه‌ای از تست‌های قابل اعتماد، توسعه‌دهندگان با اطمینان بیشتری می‌توانند تغییرات و ویژگی‌های جدید را اضافه کنند، زیرا می‌دانند که تست‌ها مشکلات احتمالی را به سرعت شناسایی خواهند کرد.
• مستندات زنده: تست‌های خوب نوشته شده می‌توانند به عنوان مستنداتی زنده از نحوه عملکرد سیستم عمل کنند.

متاسفانه، بسیاری از تیم‌ها با “بدهی فنی در تست” (Test Debt) مواجه می‌شوند، جایی که نگهداری و به‌روزرسانی تست‌ها به قدری زمان‌بر و پرهزینه می‌شود که ارزش آن‌ها زیر سوال می‌رود.

مروری کوتاه بر Page Object Model (POM)

الگوی Page Object Model (POM) یک الگوی طراحی محبوب در اتوماسیون تست UI است که به جداسازی منطق تست از جزئیات پیاده‌سازی صفحات وب کمک می‌کند. در این الگو، هر صفحه از اپلیکیشن توسط یک کلاس مجزا (Page Object) نمایش داده می‌شود که شامل локаторهای عناصر صفحه و متدهایی برای تعامل با آن عناصر است.

مزایای اصلی POM:

• خوانایی بهتر: تست‌ها منطق کاربری را دنبال می‌کنند و از جزئیات فنی پیاده‌سازی جدا هستند.
• قابلیت استفاده مجدد: کدهای مربوط به تعامل با یک صفحه در یک مکان متمرکز شده و می‌توانند توسط تست‌های مختلف استفاده شوند.
• نگهداری آسان‌تر: اگر UI تغییر کند، تنها نیاز به به‌روزرسانی کلاس Page Object مربوطه است، نه تمام تست‌هایی که از آن صفحه استفاده می‌کنند.

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

اصول SOLID برای کدهای تست

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

۱. اصل تک مسئولیتی (Single Responsibility Principle – SRP)

• تعریف: یک کلاس (یا در اینجا، یک کلاس تست یا متد تست) باید تنها یک دلیل برای تغییر داشته باشد.
• کاربرد در تست:
  • متدهای تست: هر متد تست باید یک جنبه یا رفتار خاص از واحد تحت تست (System Under Test – SUT) را بررسی کند. از نوشتن تست‌های بزرگی که چندین عملکرد را همزمان می‌آزمایند، خودداری کنید. این کار باعث می‌شود در صورت شکست تست، به سرعت دلیل آن مشخص شود.
  • کلاس‌های تست: یک کلاس تست باید مجموعه‌ای از تست‌های مرتبط با یک ویژگی خاص، ماژول یا کلاس Page Object را در بر گیرد.
  • Page Objects: هر کلاس Page Object باید تنها مسئول نمایش و تعاملات یک صفحه یا یک کامپوننت بزرگ و مستقل در UI باشد. اگر یک Page Object بیش از حد بزرگ و پیچیده می‌شود، به فکر شکستن آن به چندین کلاس کوچک‌تر و متمرکزتر باشید.

۲. اصل باز/بسته (Open/Closed Principle – OCP)

• تعریف: موجودیت‌های نرم‌افزاری (کلاس‌ها، ماژول‌ها، توابع) باید برای توسعه باز و برای تغییر بسته باشند.
• کاربرد در تست:
  • کلاس‌های کمکی (Helper Classes) و ابزارها: به جای تغییر مداوم کلاس‌های کمکی موجود، آن‌ها را طوری طراحی کنید که بتوان رفتارشان را از طریق ارث‌بری یا تزریق وابستگی گسترش داد. برای مثال، اگر یک کلاس کمکی برای ایجاد داده‌های تست دارید، باید بتوانید انواع جدیدی از داده‌ها را بدون تغییر کد اصلی کلاس کمکی اضافه کنید.
  • پیکربندی تست: امکان تغییر پیکربندی تست (مانند مرورگر مورد استفاده، URL پایه) بدون تغییر در منطق اصلی تست‌ها فراهم باشد.

۳. اصل جایگزینی لیسکوف (Liskov Substitution Principle – LSP)

• تعریف: اگر S یک زیرنوع T باشد، آنگاه اشیاء از نوع T در یک برنامه باید قابل جایگزینی با اشیاء از نوع S باشند بدون اینکه صحت برنامه تغییر کند.
• کاربرد در تست:
  • ارث‌بری در Page Objects یا کلاس‌های پایه تست: اگر از ارث‌بری در ساختار تست‌های خود استفاده می‌کنید (مثلاً یک کلاس BasePage یا BaseTest)، کلاس‌های مشتق شده باید بتوانند جایگزین کلاس پایه شوند بدون اینکه رفتار غیرمنتظره‌ای ایجاد کنند. متدهای override شده باید قراردادهای متد پایه را رعایت کنند.
  • مثال: اگر یک AuthenticatedPage از BasePage ارث می‌برد، تمام متدهای BasePage باید در AuthenticatedPage به همان شکل مورد انتظار عمل کنند یا به طور منطقی گسترش یابند.

۴. اصل تفکیک رابط (Interface Segregation Principle – ISP)

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

۵. اصل وارونگی وابستگی (Dependency Inversion Principle – DIP)

• تعریف: ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند. هر دو باید به انتزاعات (abstractions) وابسته باشند. انتزاعات نباید به جزئیات وابسته باشند؛ بلکه جزئیات باید به انتزاعات وابسته باشند.
• کاربرد در تست:
  • سرویس‌ها و وابستگی‌های خارجی: تست‌های شما (ماژول سطح بالا) نباید مستقیماً به پیاده‌سازی‌های کانکریت سرویس‌های خارجی (مانند پایگاه داده، APIهای خارجی) وابسته باشند. به جای آن، به رابط‌ها (abstractions) وابسته شوید و از اشیاء ساختگی (mocks یا stubs) برای این رابط‌ها در تست‌های واحد یا集成 استفاده کنید. این کار باعث جداسازی تست‌ها از محیط و افزایش سرعت و پایداری آن‌ها می‌شود.
  • تزریق وابستگی در Page Objects: به جای اینکه یک Page Object مستقیماً درایور وب (مانند WebDriver) را ایجاد کند، درایور را از طریق سازنده یا یک متد setter به آن تزریق کنید. این کار امکان تست کردن Page Objectها را به صورت مجزاتر و همچنین استفاده از درایورهای مختلف یا ساختگی را فراهم می‌کند.

اصولی فراتر از SOLID برای نگهداری تست‌ها

علاوه بر SOLID، اصول و الگوهای دیگری نیز وجود دارند که به نگهداری بهتر کدهای تست کمک شایانی می‌کنند:

۱. خودت را تکرار نکن (Don’t Repeat Yourself – DRY)

• مفهوم: از تکرار کدهای مشابه در تست‌های مختلف بپرهیزید.
• راهکارها:
  • متدهای کمکی (Helper Methods): برای عملیات رایج مانند ورود به سیستم، ایجاد داده‌های تست خاص، یا ناوبری‌های پیچیده، متدهای کمکی ایجاد کنید.
  • کلاس‌های پایه تست (Base Test Classes): تنظیمات و تخریب‌های (setup/teardown) مشترک بین چندین کلاس تست را در یک کلاس پایه قرار دهید.
  • Data Builders یا Object Mothers: برای ایجاد اشیاء داده پیچیده با تنظیمات پیش‌فرض و امکان سفارشی‌سازی، از این الگوها استفاده کنید.

۲. آن را ساده نگه دار، احمق! (Keep It Simple, Stupid – KISS)

• مفهوم: از پیچیدگی بی‌مورد در کدهای تست خودداری کنید. تست‌ها باید تا حد امکان ساده و قابل فهم باشند.
• راهکارها:
  • هر تست باید یک هدف مشخص داشته باشد.
  • از منطق شرطی و حلقه‌های پیچیده در تست‌ها اجتناب کنید، مگر اینکه کاملاً ضروری باشد. اگر تست شما بیش از حد منطق برنامه را تقلید می‌کند، احتمالاً مشکلی در طراحی تست یا SUT وجود دارد.

۳. تو به آن نیاز نخواهی داشت (You Ain’t Gonna Need It – YAGNI)

• مفهوم: تنها کدی را بنویسید که در حال حاضر به آن نیاز دارید. از اضافه کردن ویژگی‌ها یا انتزاعاتی که فکر می‌کنید “شاید در آینده لازم شوند” به کدهای تست خودداری کنید.
• راهکارها:
  • روی پوشش دادن نیازمندی‌های فعلی تمرکز کنید.
  • اگر نیاز به یک ویژگی جدید در تست‌ها پیش آمد، آنگاه آن را اضافه کنید (اصل OCP را هم در نظر بگیرید).

۴. خوانایی و نام‌گذاری واضح (Readability and Clear Naming)

• مفهوم: کدهای تست باید به راحتی خوانده و فهمیده شوند، حتی توسط افرادی که آن‌ها را ننوشته‌اند.
• راهکارها:
  • نام‌گذاری متدهای تست: از نام‌های توصیفی برای متدهای تست استفاده کنید که سناریوی تست را بیان کنند (مثلاً الگوی Given_When_Then یا Should_ExpectedBehavior_When_StateUnderTest).
    • مثال: testLogin_WithValidCredentials_ShouldNavigateToDashboard
  • نام‌گذاری متغیرها: نام‌های معنی‌دار برای متغیرها انتخاب کنید.
  • Page Objects: نام کلاس‌ها و متدها در Page Objects باید منعکس‌کننده عناصر و اقدامات کاربر در صفحه باشند.

۵. اتمی بودن و استقلال تست‌ها (Test Atomicity and Independence)

• مفهوم: هر تست باید مستقل از سایر تست‌ها قابل اجرا باشد و ترتیب اجرای تست‌ها نباید بر نتیجه آن‌ها تأثیر بگذارد.
• راهکارها:
  • هر تست باید داده‌های مورد نیاز خود را ایجاد کند و پس از اجرا، محیط را به حالت اولیه بازگرداند (cleanup).
  • از وابستگی بین تست‌ها (مثلاً یک تست داده‌ای را ایجاد کند که تست بعدی از آن استفاده کند) جداً خودداری کنید.

۶. استفاده موثر از Assertionها

• مفهوم: Assertionها قلب تست‌های شما هستند. آن‌ها تأیید می‌کنند که رفتار واقعی سیستم با رفتار مورد انتظار مطابقت دارد.
• راهکارها:
  • در هر متد تست، تنها یک جنبه منطقی را assert کنید (این به SRP هم مرتبط است). اگر نیاز به چندین assertion برای یک رفتار دارید، آن‌ها باید مرتبط باشند.
  • پیام‌های واضح و آموزنده برای assertionها ارائه دهید تا در صورت شکست، به سرعت مشکل قابل شناسایی باشد.
  • از “magic strings” یا مقادیر سخت‌کد شده در assertionها بپرهیزید؛ از ثابت‌ها یا متغیرهای توصیفی استفاده کنید.

۷. مدیریت داده‌های تست (Test Data Management)

• مفهوم: مدیریت صحیح داده‌های تست برای پایداری و قابلیت اطمینان تست‌ها حیاتی است.
• راهکارها:
  • جدا کردن داده‌ها از منطق تست: داده‌های تست را در فایل‌های خارجی (مانند JSON، CSV، Excel) یا از طریق Data Builders مدیریت کنید.
  • ایجاد داده‌های تازه برای هر تست: تا حد امکان، برای هر اجرای تست، داده‌های مورد نیاز را به صورت پویا ایجاد کنید و پس از تست پاکسازی نمایید.
  • استفاده از پایگاه داده تستی مجزا: برای جلوگیری از تداخل با داده‌های واقعی یا محیط توسعه.

۸. بازآرایی منظم کد تست (Regular Refactoring of Test Code)

همانند کد اصلی برنامه، کد تست نیز نیاز به بازآرایی (Refactoring) دوره‌ای دارد. با تکامل سیستم، برخی تست‌ها ممکن است منسوخ شوند، یا روش‌های بهتری برای نوشتن آن‌ها پیدا شود. اختصاص زمان برای بهبود و تمیز نگه داشتن کد تست، یک سرمایه‌گذاری بلندمدت است.

مزایای پیاده‌سازی این اصول

• کاهش شکنندگی تست‌ها (Flakiness): تست‌ها پایدارتر شده و نتایج قابل اعتمادتری ارائه می‌دهند.
• درک سریع‌تر شکست‌ها: تشخیص دلیل شکست تست‌ها آسان‌تر و سریع‌تر می‌شود.
• افزایش سرعت اجرای تست‌ها: با طراحی بهتر و استفاده از mockها و stubها در جای مناسب.
• تسهیل همکاری تیمی: کدهای تست خواناتر و قابل فهم‌تر برای همه اعضای تیم.
• کاهش هزینه نگهداری: زمان کمتری صرف رفع باگ‌های تست و تطبیق آن‌ها با تغییرات می‌شود.

نتیجه‌گیری

نوشتن کد تست قابل نگهداری یک مهارت ضروری برای تیم‌های توسعه نرم‌افزار مدرن است. در حالی که الگوهایی مانند Page Object Model یک نقطه شروع عالی هستند، به‌کارگیری اصول بنیادی مهندسی نرم‌افزار مانند SOLID، DRY، KISS و تمرکز بر خوانایی و استقلال تست‌ها، می‌تواند کیفیت و پایداری مجموعه تست‌های شما را به سطح بالاتری ارتقا دهد. با سرمایه‌گذاری در نوشتن تست‌های تمیز و قابل نگهداری، نه تنها کیفیت محصول خود را تضمین می‌کنید، بلکه فرآیند توسعه را نیز کارآمدتر و لذت‌بخش‌تر خواهید ساخت.

---

سوالات متداول