تست عملکردی به عنوان یک ابزار طراحی برای پروژه های پشته کامل: یک مثال ساده

یک پروژه تمام پشته را با شروع تست های عملکردی آن طراحی کنید. آیا این به نظر دیوانه کننده است؟
در دنباله مقالات، نحوه طراحی آزمایش پروژه Full Stack را در کنار طراحی خود پروژه با استفاده از یک مثال ساده نشان خواهم داد. من همچنین مزایای این روش را برجسته خواهم کرد.
کد منبع پروژه نمونه اینجاست
شاید این مقاله برای توسعه دهندگان Front-End/Back-End و توسعه دهندگان تست اتوماسیون (یا هر کسی که به دنبال یک خواب خوب شبانه است) مفید باشد.

تعریف تست عملکردی

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

چرا به تست عملکردی نیاز دارید؟

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

• توانایی اجرای محصول به صورت محلی (به عنوان مثال، ساختن محصول/محیط از کد منبع برای هر اجرای آزمایشی)
• یک API کامل محصول برای آزمایش خودکار (به عنوان مثال، ایجاد/حذف خودکار کاربر/حساب یک محصول برای هر اجرای آزمایشی)
• توانایی اجرای تمسخر اجزا یا عملکردهای محصول (به عنوان مثال، جایگزینی پایگاه داده محصول با یک ماک یا شبیه ساز)

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

تعریف طرح کلی و اهداف

بیایید اهداف اصلی پروژه را تعریف کنیم: ثبت نام کاربر و ارائه اطلاعات شخصی پس از ورود به سیستم.
به طور خاص، پروژه باید پشتیبانی کند:

• ثبت نام کاربر
• برای کاربران ثبت نام شده وارد شوید
• نمایش اطلاعات شخصی کاربر

طراحی باید از دو بخش اصلی تشکیل شود:

• API – برای مدیریت کاربر و ذخیره اطلاعات شخصی
• وب – برای ثبت نام، ورود به سیستم و نمایش اطلاعات کاربر

اجزای پروژه:

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

مراحل طراحی اولیه

بیایید با بخش وب پروژه شروع کنیم. چرا از اینجا شروع کنیم؟
بخش وب رابط کاربر است که به ما کمک می کند تا اهداف دقیق پروژه را از دیدگاه کاربر تعریف کنیم (داستان های کاربر). همچنین به تعیین الزامات بخش API کمک می کند، زیرا بخش وب به طور مستقیم با API در تعامل است.

تعریف و پیاده سازی آزمون

بیایید مجموعه ای از تست ها را برای هر هدف پروژه تعریف کنیم.
آزمون های ثبت نام:

• کاربر با اطلاعات شخصی معتبر با موفقیت ثبت نام را تکمیل می کند
• کاربر هنگام استفاده از داده های شخصی نامعتبر (به عنوان مثال، نام خانوادگی گم شده) ثبت نام نمی کند.
• کاربر موجود نمی تواند دوباره ثبت نام کند
• ثبت نام به دلیل خطاهای سمت سرور انجام نمی شود

تست های ورود:

• کاربر موجود می تواند با موفقیت وارد سیستم شود
• اطلاعات شخصی کاربر پس از ورود به سیستم نمایش داده می شود
• کاربر نمی تواند با اعتبار نامعتبر وارد سیستم شود
• ورود به سیستم به دلیل خطاهای سمت سرور انجام نمی شود

این آزمایش ها شرح مفصلی از اهداف کلی پروژه ارائه می دهند. اجرای تست های عملکردی به ما کمک می کند تا صفحات وب مورد نیاز، قابلیت های آنها، تعاملات کاربر و ارتباط بین وب و بخش های API را درک کنیم.

هر آزمون از الگوی AAA (Arrange-Act-Assert) پیروی می کند:

• ترتیب – پیش شرط آزمون را تنظیم کنید
• Act – عمل مورد آزمایش را انجام دهید
• اظهار نظر – نتیجه عمل را تأیید کنید

تست‌های ما با مدل‌های صفحه وب (که با صفحات وب پروژه واقعی مطابقت دارند) و مدل‌های سرور API تعامل خواهند داشت.

چارچوب های مورد استفاده (سایر موارد مشابه را می توان جایگزین کرد):

اجزای درگیر در آزمایش بخش وب:

نمونه اجرای آزمایشی صفحه ثبت نام (نسخه ترتیبی):

حالا بیایید کد تست هایی که قبلا تعریف کردیم را بررسی کنیم:

• RegistrationPage – مدل عملکردی صفحه ثبت نام (همچنین به عنوان صفحه شیء مدل یا شیء صفحه آن نیز شناخته می شود)
• RegistrationSucceededPage – مدل عملکردی صفحه ثبت نام موفق

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

این روش‌ها و توابع خرد می‌شوند (در اینجا درباره خردها اطلاعات کسب کنید)، در ابتدا نتایج نامعتبر را برای شکست عمدی در تست‌ها برمی‌گردانند.

بنابراین، اکنون چه چیزی داریم و چگونه کمک می کند؟

• درک عملکرد واقعی صفحات وب (از طریق کد تست)
• مجموعه ای از تست های عملکردی برای صفحات وب پروژه

بیایید آن را کدگذاری کنیم!

موارد پروژه هنوز اجرا نشده است:

• وب سرور (با استفاده از ExpressJS)
• صفحات وب پروژه
• اتصالات سرور API (در صفحات وب)
• جایگزینی خرد با کد در صفحه اشیاء و در ماکت های سرور API

من زمان را برای توصیف ایجاد صفحات وب و پیکربندی وب سرور تلف نمی کنم. تمام کدهای مربوطه اینجاست. فقط چند نمونه

وب سرور (server.ts):

نمونه صفحه ثبت نام (register.html):

پیوند بین صفحه ثبت نام و سرور API (register.ts):

ظاهر صفحه ثبت نام در سناریوهای مختلف

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

در زیر نمونه ای از اجرای ماک ها با استفاده از Playwright آورده شده است (کد کامل اینجاست):

پس از گذراندن تمام تست ها، بخش وب پروژه را می توان کامل در نظر گرفت.

خلاصه ای از فرآیند توسعه بخش وب

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

درک عملکرد وب با ایجاد تست های کاربردی و به دنبال آن توسعه موازی اجزای وب در کنار تست ها به دست آمد. تست های عملکردی مستقل از سرور API اجرا می شوند (که در این مرحله هنوز پیاده سازی نشده است).

این رویکرد منعکس کننده یک پیشرفت تدریجی از مفاهیم کلی به جزئیات خاص است و امکان کنترل بهتر بر کل فرآیند طراحی و توسعه را در عین حفظ کیفیت و درک روشن فراهم می کند. این امکان تعریف عناصر ضروری پروژه را قبل از اجرای کد واقعی آنها فراهم می کند.

به طور کلی، این فرآیند شبیه روش TDD (Test-Driven Development) است که در اینجا در زمینه تست عملکردی اعمال می شود.

یکی از اشکالات زمان توسعه طولانی است که می تواند برای استارتاپ هایی که ارائه سریع ویژگی ها ممکن است بر کیفیت اولویت داشته باشد بسیار مهم باشد. در نتیجه، مدیران استارتاپ اغلب نسبت به این روش تردید دارند.

با این حال، تمرین منظم این رویکرد می تواند زمان توسعه را با رشد تجربه و شهود کاهش دهد.

کد بخش وب پروژه در اینجا موجود است.

مقاله بعدی اجرای API و استقرار کل پروژه Full Stack را پوشش می دهد.

متشکرم!