چه چیزی را آزمایش کنیم، بر خلاف آزمایش چیست ، یک سوال مهم برای همه تیم ها است. تست وسیله ای برای رسیدن به هدف است و انتخاب نحوه اولویت بندی تست بخش های مختلف پایگاه کد شما می تواند دشوار باشد.
بهترین راه برای اولویت بندی بر اساس پایگاه کد شما و اهداف تیم شما است. با این حال، مهم است که به یاد داشته باشید، اگرچه نوشتن تعداد زیادی تست کوچک (در انتهای هرم آزمایشی، مانند تست‌های واحد) که پوشش کد زیادی دارند، زمان و پهنای باند کمی نیاز دارد، اما لزوماً باعث کاهش کلی نمی‌شوند. ریسک برای پروژه شما
شما می توانید با فکر کردن در مورد موارد استفاده اولیه برنامه، وب سایت یا کتابخانه خود، ابتدا چه چیزی را آزمایش کنید. این می‌تواند با نوشتن تست‌های مؤلفه بر روی بخش‌های حیاتی سایت شما، مؤلفه‌های اصلی که تجربه کاربر شما را تشکیل می‌دهند، باشد. برای مثال، توسعه‌دهندگان سایتی که به کاربران اجازه می‌دهد داده‌های سری زمانی را آپلود و مدیریت کنند، باید روش‌های مختلفی را که کاربر ممکن است آن وظایف را انجام دهد، تصور و آزمایش کنند.
یکی دیگر از رویکردهای اولویت بندی شامل به دست آوردن بیشترین اطلاعات است. اگر بخش باربری «خطرناک»، میراثی یا بد نوشته شده ای از پایگاه کد خود دارید که هیچ کس در تیم شما از کار کردن روی آن لذت نمی برد، می تواند مفید باشد که آزمایش هایی پیرامون آن ایجاد کنید تا رفتار آن را منسجم تر کنید قبل از اینکه نادیده بگیرید. آن را بیشتر کنید، یا آن را اصلاح کنید تا آن را اصلاح کنید. این را مانند داربست برای ساختمانی در نظر بگیرید که قبلاً محکوم شده است، اما هنوز مرکز داده شما را در خود جای داده است.
ابعاد
ما مفهوم یک هرم آزمایشی یا یک شکل آزمایشی دیگر را معرفی کرده‌ایم، اما اینها فقط یک بعد واحد از آزمایش را ارائه می‌کنند: خطی که از دامنه کوچک، آزمون‌های واحد ساده به آزمون‌های پیچیده و گسترده می‌رود - آزمون‌های واحد در مقابل تست های یکپارچه سازی در مقابل تست های پایان به انتها.
با این حال، برخی از لیست طولانی انواع آزمایش ممکن سطحی از پیچیدگی را نشان نمی‌دهند، بلکه اهداف یا تکنیک‌های آزمایش را نشان می‌دهند. به عنوان مثال، تست‌های دود دسته‌بندی متفاوتی از تست هستند که خود می‌توانند تست‌های واحد، سرتاسر یا تست‌های دیگر باشند، اما هدفشان این است که به آزمایش‌کنندگان اطمینان کلی بدهند که پروژه در حال آزمایش در وضعیت معتبری است. تست بصری همچنین می تواند برای یک جزء کوچک یا در کل سایت شما مفید باشد.
پایگاه کد شما الزامات منحصر به فردی خواهد داشت. برای مثال، تراز کردن بر روی یک ویژگی ، نوشتن انواع مختلف تست برای اطمینان از درستی کار کردن، می‌تواند در پایگاه کد شما بسیار مهم‌تر باشد. یک ویژگی جدید که نیاز به آزمایش دارد به ندرت یک جزء، عملکرد یا رویکرد واحد است و تأثیر آن بر پروژه شما ممکن است به طور گسترده و در مقیاس های مختلف توزیع شود.
اولویت های آزمایشی شما ممکن است به نیازهای تجاری شما نیز بستگی داشته باشد. سیستم‌های بسیار فنی ممکن است به آزمایش واحد پیچیده نیاز داشته باشند تا تأیید شود که یک الگوریتم منحصربه‌فرد به درستی عمل می‌کند، در حالی که ابزارهای بسیار تعاملی احتمالاً بر روی آزمایش بصری یا آزمایش انتها به انتها تمرکز می‌کنند تا تأیید کنند که ورودی‌های لمسی پیچیده پاسخ صحیح را ایجاد می‌کنند.
رویکرد شما به آزمایش
سعی کنید بدون توجه به مقیاس آنها، روی آزمایش موارد استفاده پایگاه کد خود تمرکز کنید. تصور کنید که کاربر چگونه ممکن است از هر بخشی از پروژه شما استفاده کند - این ممکن است یک جزء واحد، یا یک تابع سطح پایین تر یا یک مورد استفاده از پایان به پایان سطح بالا را نشان دهد. (اگر متوجه شدید که آزمون شما نمی تواند به خوبی با کد مورد آزمایش تعامل داشته باشد، این می تواند نقص در انتزاعات شما را در هر مقیاسی نشان دهد.)
مهم است که هر مورد آزمایشی یک هدف مشخص و مشخص داشته باشد. تست‌های بزرگ «گیر همه چیز» می‌توانند سخت باشند، درست مانند کدهای غیرآزمایشی شما.
کنار توسعه آزمایش محور
توسعه تست محور (TDD) یک رویکرد منحصر به فرد برای آزمایش است - متعامد به مقیاس یا انواع - به این دلیل که شامل نوشتن تست هایی است که حداقل در ابتدا شکست می خورند. این می تواند هم برای آزمایش دستی و هم برای آزمایش خودکار اعمال شود: شما اهدافی را که می خواهید به آن دست یابید، توضیح می دهید، در می یابید که چه چیزی در راه حل یا کد فعلی شما وجود ندارد، و از آزمون شکست به عنوان راهنمایی برای رسیدن به یک راه حل استفاده می کنید.
البته، آزمایش هر سناریوی ممکن در یک برنامه یا مؤلفه فرضی حتی قبل از شروع ساخت آن مفید نیست. TDD جای خود را دارد و با پیچیده تر شدن پایگاه کد شما می تواند مفید باشد.
TDD همچنین تمرین خوبی برای رفع اشکال است. اگر بتوانید مورد بازتولید یک باگ را کدنویسی کنید، می توان آن را در یک آزمایش خودکار قرار داد که در ابتدا با شکست مواجه می شود. هنگامی که اشکال را برطرف کردید، آزمایش با موفقیت انجام می شود و به شما امکان می دهد بدون تأیید دستی تعیین کنید که آیا رفع موفقیت آمیز بوده است یا خیر.
مات در مقابل جعبه شفاف
این به روشی که هر بخشی از سیستم خود را تست می کنید اشاره دارد. اگر غیرشفاف باشد، به‌عنوان مثال، هنگام استفاده از رابط عمومی کلاس، به جای بررسی داخلی آن، نمی‌توانید داخل آن را ببینید.
مگر اینکه دلیل خاصی برای این کار نداشته باشید، بهتر است با تست جعبه مات شروع کنید تا بتوانید تست ها را بر اساس نحوه استفاده از اجزای خود طراحی کنید و حواس شما را از نحوه عملکرد داخلی آنها پرت نکنید. اگر فقط به واسط «عمومی» مسیر کد تکیه می‌کنید (الزاماً برای کاربرانتان عمومی نیست، بلکه ممکن است برای سایر بخش‌های کدتان باشد)، می‌توانید با دانستن اینکه آزمایش شما هر گونه تغییری را تشخیص می‌دهد، آن کد را اصلاح و بهبود دهید.
یکی از راه‌های تبدیل کد «جعبه پاک» به غیرشفاف‌تر شدن، معرفی عناصر قابل تنظیم مانند انتزاع‌ها برای وابستگی‌های کد، یا تماس‌های برگشتی برای مشاهده وضعیت است، نه اینکه آن حالت به طور محکم با سیستم‌های دیگر مرتبط شود. این باعث می‌شود کد شما بیشتر جدا شود و به شما امکان می‌دهد نسخه‌های آزمایشی را ارائه دهید. از طرف دیگر، می‌توانید مکان‌هایی را که کد شما با سیستم‌های دیگر تعامل دارد، مورد تمسخر قرار دهید.