نام‌هایی که برای انواع مختلف تست‌ها داده می‌شود، تم‌های مشترکی در بین پایگاه‌های کد دارند، اما تعاریف دقیقی ندارند. این دوره دستورالعمل هایی در مورد معنای هر نوع آزمون ارائه می دهد، اما منابع دیگر ممکن است تعاریف متفاوتی را ارائه دهند.
در صفحات قبل، نمونه هایی از تست های واحد و تست های کامپوننت (در مثال ما، اشاره به یک جزء React) وجود داشت. ما می‌توانیم هر دوی این موارد را در هرم آزمایشی خود (یا شکل دیگری!) قرار دهیم، زیرا پیچیدگی کمی دارند و سریع اجرا می‌شوند، اما ممکن است به اندازه یک تست یکپارچه‌سازی پیچیده‌تر کاربرد نداشته باشند.
انواع متداول تست ها
تست های واحد
آزمون های واحد کوچکترین دامنه هستند. آنها معمولاً برای آزمایش بخش‌های کوچک کد یا کدهای کاملاً بدون حالت تقریباً به روشی ریاضی استفاده می‌شوند: اگر کد شما را با ورودی‌های X، Y و Z ارائه کنم، خروجی آن باید A، B و C باشد.
کد با تست های واحد معمولاً وابستگی خارجی ندارد، مانند واکشی از یک شبکه یا استفاده ضمنی از هر توابع یا کتابخانه دیگری. این یک گره درختی از کد شما است که می توانید آن را "بریده" و به تنهایی آزمایش کنید.
در حالی که تست‌های واحد معمولاً سریع نوشته و اجرا می‌شوند، همیشه این امکان وجود دارد که آزمایش واحدهای کوچک کد اطلاعات مفیدی را ارائه نکند. اغلب، عدم تعامل یک واحد کد با کدهای دیگر به این معنی است که بهتر است در سطح بالاتری برای کاهش ریسک آزمایش کنید.
تست های مولفه
برای توسعه دهندگان وب، نام "کامپوننت" بیش از حد بارگذاری شده است، که اغلب به معنای یک مؤلفه قابل مشاهده توسط کاربر، مانند یک مؤلفه React یا یک مؤلفه وب است. تعریف کلی تر آن یک تکه کار قابل آزمایش است، به عنوان مثال، یک کلاس با وابستگی های خارجی. برای اینکه این مؤلفه به طور مؤثر آزمایش شود، باید وابستگی های آن حذف یا نادیده گرفته شود.
از آنجایی که شیوه‌های توسعه وب مدرن مبتنی بر مفهوم یک مؤلفه است، آزمایش‌های مؤلفه روشی عملی برای فکر کردن در مورد آزمایش هستند: برای مثال، ممکن است تصمیم بگیرید که هر مؤلفه به آزمایش نیاز دارد. در شرایطی که یک توسعه‌دهنده یا تیم کوچک ادعا می‌کند مالکیت واضحی بر یک مؤلفه دارد، آزمایش‌های مؤلفه نیز ساده است. با این حال، تمسخر وابستگی های پیچیده می تواند دشوار باشد.
تست های یکپارچه سازی
اینها معمولاً گروه کوچکی از مؤلفه‌ها، ماژول‌ها، زیرسیستم‌ها یا سایر بخش‌های معنی‌دار کد شما را با هم آزمایش می‌کنند تا مطمئن شوند که درست کار می‌کنند. این یک تعریف بسیار مبهم است. برای توسعه دهندگان وب، تصور کنید که کدی که آزمایش می کنید، ساخت واقعی سایت شما (یا حتی بسته) نیست، اما همچنان اجزای مختلف مرتبط سیستم شما را به هم متصل می کند.
این حتی ممکن است شامل وابستگی های "واقعی" باشد، مانند پایگاه داده خارجی در حالت تست، به جای ساختگی خالص. به عنوان مثال، به جای گفتن اینکه query() همیشه همان دو ورودی را برمی گرداند، آزمون ادغام شما می تواند تأیید کند که پایگاه داده آزمایشی چیزی در آن وجود دارد. داده ها به خودی خود اهمیت کمتری دارند، اما اکنون در حال آزمایش این هستید که یک پایگاه داده را می توان با موفقیت به آن متصل کرد و آن را جستجو کرد.
نوشتن تست‌های یکپارچه‌سازی نسبتاً ساده با مفاهیم گسترده امکان‌پذیر است که می‌توان با استفاده از اظهارات آن را بررسی کرد، زیرا یک عمل متصل به اجزای مختلف می‌تواند باعث ایجاد یک سری اثرات قابل اندازه‌گیری شود. به همین دلیل، تست های یکپارچه سازی می توانند به طور موثر نشان دهند که سیستم پیچیده شما همانطور که در نظر گرفته شده است اجرا می شود. با این حال، نوشتن و نگهداری آنها ممکن است سخت باشد، و می توانند پیچیدگی بی موردی را ایجاد کنند. به عنوان مثال، نوشتن یک FakeUserService برای یک تست یکپارچه سازی این الزام را اضافه می کند که هم آن و هم RealUserService باید یک UserService پیاده سازی کنند.
تست دود
اینها تست هایی هستند که باید خیلی سریع تکمیل شوند و مشخص کنند که آیا پایگاه کد شما در وضعیت معقولی قرار دارد یا خیر. در عمل، این تا حد زیادی به معنای انجام تست های ساده روی کد است که تأثیرات گسترده ای بر تجربه شما دارد.
به عنوان مثال، در یک برنامه وب بزرگ با ورود به سیستم، این می تواند اطمینان حاصل شود که سیستم ورود و احراز هویت کار می کند، زیرا بدون آن برنامه غیرقابل استفاده است و آزمایش بیشتر بی ربط است.
تست‌های دود می‌توانند کاندیدای خوبی برای اجرا تحت اسکریپت test package.json شما در یک پایگاه کد بزرگ باشند. تست دستی نیز می تواند به عنوان نوعی تست دود عمل کند.
تست های رگرسیون
تست رگرسیون نوعی تست دود است که تضمین می‌کند که ویژگی‌های موجود همچنان به کار خود ادامه می‌دهند یا باگ‌های قدیمی پس از انتشار جدید یا توسعه سایر ویژگی‌ها دوباره معرفی نمی‌شوند.
این با مفهوم توسعه آزمایش محور (TDD) مرتبط است. موارد آزمایشی که برای راه‌اندازی صریح یک باگ نوشته می‌شوند و بعداً برای اطمینان از رفع اشکال مورد استفاده قرار می‌گیرند، به عنوان موارد تست رگرسیون به حساب می‌آیند، زیرا وجود آنها باید از بازگشت همان باگ جلوگیری کند.
با این حال، آزمایش رگرسیون می‌تواند بدون راه‌حل عالی مشکل‌ساز باشد. این اصطلاحی است که اغلب توسط نیازهای تجاری ذکر می‌شود: با توسعه ویژگی‌ها، مهم است که موارد قدیمی خراب نشوند. یک پایگاه کد خوب آزمایش شده باید بتواند این را حفظ کند، اما پایگاه های کد واقعی همیشه مطابق با آن ایده آل نیستند. در بخش های آینده بیشتر به این موضوع پرداخته خواهد شد.
تست های بصری
تست بصری شامل گرفتن اسکرین شات یا فیلم از وضعیت یک وب سایت به منظور بررسی وضعیت خوب شناخته شده (مانند اسکرین شات قبلی) در برابر آزمایش فعلی است. طبیعتاً نیاز به اجرای یک مرورگر واقعی دارد تا بتواند HTML، CSS و سایر بخش‌های وب‌سایت را رندر کند.
به‌جای آزمایش بصری تست‌های سرتاسری که کل پایگاه کد شما را اجرا می‌کنند، ساختن «هیرنس‌های» HTML که فقط مؤلفه‌های خاصی را ارائه می‌کنند، به ویژه در اندازه‌های مختلف صفحه نمایش، می‌تواند مفید باشد. این پیچیده تر از استفاده صرف از JSDOM یا فریمورک های مشابه است.
شکست تست های بصری می تواند سیگنال خوبی از انواع دیگر شکستگی باشد. با این حال، رابط‌های کاربری پیچیده می‌توانند به دلایل غیرمرتبط با ویژگی‌هایی که می‌خواهید آزمایش کنید، در آزمایش‌های بصری شکست بخورند، مانند سایر ویژگی‌های جدید که ظاهر رابط کاربری را تغییر می‌دهند، یا حتی نسخه جدید سیستم‌عامل که ایموجی را متفاوت از نسخه‌های قبلی ارائه می‌کند.
تست های پایان به انتها
تست های انتها به انتها اغلب در راس هرم تست قرار دارند. آنها یک تعامل کامل با وب یا وب سایت شما را توصیف می کنند، که احتمالاً حول یک ویژگی خاص متمرکز شده است، و معمولاً در یک مرورگر که توسط عاملی مانند WebdriverIO، Selenium، یا Puppeteer کنترل می شود، اجرا می شود، که می تواند پایگاه کد شما را کمابیش اجرا کند. در تولید مستقر خواهند شد (اگرچه آنها اغلب در لوکال هاست ارائه می شوند).
بسته به سایت شما، این ممکن است شامل ورود به عنوان یک کاربر آزمایشی، انجام اقدامات اصلی و تأیید اینکه سایت یا سیستم شما در وضعیت صحیحی قرار دارد باشد. نمونه‌های بیشتری از این نوع آزمایش را در بخش‌های بعدی پوشش خواهیم داد، زیرا می‌توانند بسیار قدرتمند باشند، اما گاهی اوقات نگهداری آنها دشوار است.
برخی از تاکتیک‌ها برای ساده‌سازی آنها می‌تواند شامل کاهش دامنه آنها، یا تمسخر اجزای خاص در صورت لزوم باشد. به عنوان مثال، اگر کاربران نیاز به ورود به سایت شما دارند، اما ورود به سیستم ویژگی مورد آزمایش شما نیست، ممکن است بخواهید یک پرچم برای محیط های آزمایشی تنظیم کنید که به کنترل کننده تست اجازه می دهد بدون ورود به سیستم یا به عنوان یک کاربر عمل کند. ایجاد کوکی های مرتبط
اگرچه تست‌های انتها به انتها می‌توانند روش‌های بسیار قدرتمندی برای آزمایش هم‌زمان در بخش‌های عظیمی از پایگاه کد شما باشند، چنین تست‌هایی در مقیاس بزرگ به دلیل وابستگی به سیستم‌های خارجی، خطر پوسته‌پوستی یا غیرقابل اعتماد شدن را دارند. آنها همچنین اغلب می توانند داده های آزمایشی زیادی را در پایگاه داده شما باقی بگذارند، اگر، برای مثال، هر آزمون یک ورودی ایجاد یا تغییر دهد. جمع آوری داده های باقی مانده مانند این می تواند تعیین چگونگی شکست یک آزمایش را دشوار کند.
تست API
آزمایش‌های API می‌توانند به تأیید رفتار APIهایی که نرم‌افزار شما ارائه می‌دهد یا دسترسی به APIهای دنیای واقعی (احتمالاً زنده) برای تأیید رفتار آنها اشاره کنند. در هر صورت، این تمایل دارد انتزاعات بین سیستم ها را آزمایش کند - اینکه چگونه آنها در نهایت با یکدیگر ارتباط برقرار می کنند - بدون اینکه در واقع آنها را مانند یک تست یکپارچه سازی با هم ادغام کنند.
این تست‌ها می‌توانند یک پیش‌روی اساسی برای تست یکپارچه‌سازی بدون هزینه‌های سربار اجرای سیستم‌هایی که اتصالات بین آنها را آزمایش می‌کنید، ارائه دهند. با این حال، آزمایش‌های سیستم‌های دنیای واقعی می‌تواند ضعیف باشد.
انواع دیگر
روش های مختلف دیگری برای آزمایش وجود دارد که بسته به منبع شما ممکن است مفید باشد. از نمونه های جالب می توان به موارد زیر اشاره کرد:
- تست دستی
- تست پذیرش، نوعی تست دستی که توسط Agile رایج شده است، تأیید می کند که محصول "نیازهای کاربر را برآورده می کند".
- تست آشوب به وارد کردن داده‌های تصادفی برای دیدن اینکه چه اتفاقی می‌افتد، اشاره دارد تا مطمئن شوید در صورت وارد کردن داده‌های بد، سایت از کار نخواهد افتاد.
- تست شکست عمداً خرابی‌ها را در سیستم‌های پیچیده شبیه‌سازی می‌کند، مانند خرابی‌های شبکه، تا مطمئن شود کد تحت آزمایش به روشی کنترل‌شده پاسخ می‌دهد.
- آزمایش ساخت تأیید می کند که مصنوعات ساخت پایگاه کد می توانند با بررسی وجود یا محتوای آنها تولید شوند. این نوع تست می تواند برای بررسی خروجی یک CMS پیچیده مفید باشد.
پوشش کد
می توان اندازه گیری کرد که چند درصد از کد شما توسط تست های خودکار تست شده است و این را به عنوان یک آمار در طول زمان گزارش کنید. ما توصیه نمی‌کنیم که پوشش کد 100% را هدف قرار دهید، زیرا این امر می‌تواند منجر به سربار غیرضروری و همچنین آزمایش‌های ساده یا طراحی ضعیفی شود که موارد استفاده عمده را به طور عمیق پوشش نمی‌دهند.
پوشش خود نیز می تواند ابزار مفیدی در هنگام نوشتن یا کار بر روی تست های شما، به خصوص تست های یکپارچه سازی باشد. با نمایش درصد یا تجزیه خط به خط کدهایی که با یک تست آزمایش می‌شوند، می‌توانید بینشی در مورد موارد گمشده یا مواردی که می‌توان بعداً آزمایش کرد به دست آورید.
منابع
درک خود را بررسی کنید
کدام یک از موارد زیر از انواع تست های شناخته شده هستند؟