مشخص کنید چه چیزی را باید آزمایش کنید و چه چیزی را می توانید رد کنید.
مقاله قبلی به اصول اولیه موارد آزمایشی و آنچه باید در آنها باشد پرداخت. این مقاله عمیق‌تر به ایجاد موارد آزمایشی از منظر فنی می‌پردازد، و جزئیات آنچه را که باید در هر آزمون گنجانده شود و از چه چیزهایی باید اجتناب کرد، توضیح می‌دهد. در اصل، شما پاسخ سوالات قدیمی "چه چیزی را تست کنید" یا "چه چیزی را نباید تست کنید" را خواهید آموخت.
دستورالعمل ها و الگوهای عمومی
شایان ذکر است که الگوها و نکات خاص مهم هستند، صرف نظر از اینکه آیا شما در حال انجام تست های واحد، ادغام یا پایان به انتها هستید. این اصول را می توان و باید برای هر دو نوع آزمایش اعمال کرد، بنابراین مکان خوبی برای شروع هستند.
آن را ساده نگه دارید
وقتی نوبت به نوشتن تست ها می رسد، یکی از مهم ترین نکاتی که باید به خاطر بسپارید، ساده نگه داشتن آن است. مهم است که ظرفیت مغز را در نظر بگیرید. کد اصلی تولید فضای قابل توجهی را اشغال می کند و فضای کمی برای پیچیدگی اضافی باقی می گذارد. این به ویژه برای آزمایش صادق است.
اگر فضای اصلی کمتری در دسترس باشد، ممکن است در تلاش‌های آزمایشی خود آرام‌تر شوید. به همین دلیل است که اولویت دادن به سادگی در تست بسیار مهم است. در واقع، بهترین روش‌های تست جاوا اسکریپت یونی گلدبرگ بر اهمیت قانون طلایی تأکید می‌کند - آزمون شما باید مانند یک دستیار باشد و نه مانند یک فرمول پیچیده ریاضی. به عبارت دیگر، شما باید بتوانید هدف آزمون خود را در نگاه اول درک کنید.
شما باید در همه انواع تست ها صرف نظر از پیچیدگی آنها سادگی را هدف بگیرید. در واقع، هرچه یک آزمون پیچیده تر باشد، ساده کردن آن مهم تر است. یکی از راه‌های رسیدن به این هدف از طریق طراحی تست تخت است، که در آن تست‌ها تا حد امکان ساده نگه داشته می‌شوند و فقط موارد ضروری را آزمایش می‌کنند. این بدان معنی است که هر آزمون باید فقط یک مورد آزمایشی داشته باشد و مورد آزمایشی باید روی آزمایش یک عملکرد یا ویژگی خاص متمرکز شود.
از این منظر در مورد آن فکر کنید: تشخیص اینکه هنگام خواندن یک آزمون مردودی چه چیزی اشتباه بوده است، باید آسان باشد. به همین دلیل ساده نگه داشتن تست ها و درک آسان آن مهم است. انجام این کار به شما امکان می دهد مشکلات را در صورت بروز سریع شناسایی و رفع کنید.
تست کنید چه چیزی ارزشش را دارد
طراحی تست مسطح همچنین تمرکز را تشویق می کند و کمک می کند تا مطمئن شوید که تست های شما معنی دار هستند. به یاد داشته باشید، شما نمی خواهید تست هایی را فقط به خاطر پوشش ایجاد کنید - آنها همیشه باید هدف داشته باشند.
جزئیات پیاده سازی را آزمایش نکنید
یکی از مشکلات رایج در تست این است که آزمایش‌ها اغلب برای آزمایش جزئیات پیاده‌سازی طراحی می‌شوند، مانند استفاده از انتخابگرها در کامپوننت‌ها یا تست‌های انتها به انتها. جزئیات پیاده‌سازی به چیزهایی اشاره دارد که کاربران کد شما معمولاً از آنها استفاده نمی‌کنند، نمی‌بینند یا حتی درباره آنها نمی‌دانند. این می تواند منجر به دو مشکل عمده در آزمایش شود: منفی کاذب و مثبت کاذب.
منفی کاذب زمانی رخ می دهد که یک تست با شکست مواجه شود، حتی اگر کد تست شده صحیح باشد. این می تواند زمانی اتفاق بیفتد که جزئیات پیاده سازی به دلیل تغییر مجدد کد برنامه تغییر کند. از سوی دیگر، با موفقیت یک تست، حتی اگر کد آزمایش شده نادرست باشد، مثبت کاذب رخ می دهد.
یکی از راه حل های این مشکل این است که انواع مختلف کاربران را در نظر بگیرید. کاربران نهایی و توسعه دهندگان می توانند در رویکرد خود متفاوت باشند و ممکن است به طور متفاوتی با کد تعامل داشته باشند. هنگام برنامه‌ریزی تست‌ها، در نظر گرفتن اینکه کاربران چه چیزی را خواهند دید یا با آن تعامل خواهند داشت، ضروری است و به جای جزئیات پیاده‌سازی، تست‌ها را به آن چیزها وابسته کنیم.
به عنوان مثال، انتخاب انتخابگرهایی که کمتر مستعد تغییر هستند، می تواند تست ها را قابل اعتمادتر کند: ویژگی های داده به جای انتخابگرهای CSS. برای جزئیات بیشتر، به مقاله کنت سی دادز در مورد این موضوع مراجعه کنید، یا با ما همراه باشید—مقاله ای در این زمینه بعدا ارائه می شود.
تمسخر: کنترل خود را از دست ندهید
تمسخر یک مفهوم گسترده است که در تست واحد و گاهی اوقات در تست ادغام استفاده می شود. این شامل ایجاد داده ها یا اجزای جعلی برای شبیه سازی وابستگی هایی است که کنترل کاملی بر برنامه دارند. این امکان آزمایش جداگانه را فراهم می کند.
استفاده از ماک ها در آزمون های خود می تواند پیش بینی پذیری، تفکیک نگرانی ها و عملکرد را بهبود بخشد. و اگر نیاز به انجام آزمایشی دارید که نیاز به مشارکت انسانی دارد (مانند تأیید گذرنامه)، باید آن را با استفاده از یک الگو مخفی کنید. به همه این دلایل، مسخره کردن ابزار ارزشمندی برای بررسی است.
در عین حال، تمسخر ممکن است بر دقت آزمون تأثیر بگذارد زیرا آنها مسخره هستند، نه تجربیات واقعی کاربر. بنابراین باید هنگام استفاده از مسخره و خرد مراقب باشید.
آیا باید در آزمون های انتها به انتها مسخره کرد؟
به طور کلی، خیر. با این حال، تمسخر می‌تواند گاهی نجات‌دهنده باشد—بنابراین اجازه دهید آن را کاملاً رد نکنیم.
این سناریو را تصور کنید: شما در حال نوشتن آزمایشی برای ویژگی ای هستید که شامل یک سرویس ارائه دهنده پرداخت شخص ثالث است. شما در محیط سندباکسی هستید که آنها ارائه کرده اند، یعنی هیچ تراکنش واقعی انجام نمی شود. متأسفانه، جعبه شنی خراب است و در نتیجه باعث می‌شود که تست‌های شما با شکست مواجه شود. تعمیر باید توسط ارائه دهنده پرداخت انجام شود. تنها کاری که می توانید انجام دهید این است که منتظر بمانید تا مشکل توسط ارائه دهنده حل شود.
در این مورد، کاهش وابستگی به خدماتی که نمی‌توانید کنترل کنید، ممکن است سودمندتر باشد. همچنان توصیه می شود از تمسخر با دقت در آزمون های ادغام یا پایان به انتها استفاده کنید زیرا سطح اطمینان آزمون های شما را کاهش می دهد.
مشخصات تست: بایدها و نبایدها
بنابراین، در کل، یک آزمون شامل چه چیزی است؟ و آیا تفاوت هایی بین انواع تست وجود دارد؟ بیایید نگاهی دقیق‌تر به برخی از جنبه‌های خاص متناسب با انواع اصلی آزمایش بیندازیم.
چه چیزی به یک آزمون واحد خوب تعلق دارد؟
یک آزمون واحد ایده آل و موثر باید:
- روی جنبه های خاص تمرکز کنید.
- مستقل عمل کند.
- سناریوهای در مقیاس کوچک را در بر بگیرد.
- از نام های توصیفی استفاده کنید.
- در صورت وجود الگوی AAA را دنبال کنید.
- پوشش آزمون جامع را تضمین می کند.
| انجام دهید✅ | نکن ❌ |
|---|---|
| تست ها را تا حد امکان کوچک نگه دارید. یک چیز را در هر مورد تست کنید. | تست ها را روی واحدهای بزرگ بنویسید. |
| همیشه تست ها را جدا نگه دارید و چیزهایی را که نیاز دارید و خارج از واحد شما هستند مسخره کنید. | شامل سایر اجزا یا خدمات |
| تست ها را مستقل نگه دارید. | به تست های قبلی تکیه کنید یا داده های تست را به اشتراک بگذارید. |
| سناریوها و مسیرهای مختلف را پوشش دهید. | حداکثر خود را به مسیر شاد یا تست های منفی محدود کنید. |
| از عناوین تست تشریحی استفاده کنید، تا بتوانید فوراً متوجه شوید که آزمون شما در مورد چیست. | فقط با نام تابع تست کنید، در نتیجه به اندازه کافی توصیفی نیست: testBuildFoo() یا testGetId() . |
| به خصوص در این مرحله، پوشش کد خوب یا طیف وسیع تری از موارد آزمایشی را هدف قرار دهید. | از هر کلاس تا سطح پایگاه داده (I/O) تست کنید. |
چه چیزی به یک آزمون یکپارچه سازی خوب تعلق دارد؟
یک آزمون ادغام ایده آل برخی از معیارها را با آزمون های واحد نیز به اشتراک می گذارد. با این حال، چند نکته اضافی وجود دارد که باید در نظر بگیرید. یک آزمون ادغام عالی باید:
- تعامل بین اجزا را شبیه سازی کنید.
- سناریوهای دنیای واقعی را بپوشانید و از مسخره یا خرد استفاده کنید.
- عملکرد را در نظر بگیرید.
| انجام دهید✅ | نکن ❌ |
|---|---|
| نقاط ادغام را آزمایش کنید: بررسی کنید که هر واحد زمانی که با یکدیگر ادغام می شوند، به خوبی با هم کار می کنند. | هر واحد را به صورت مجزا آزمایش کنید - این همان چیزی است که تست های واحد برای آن انجام می شود. |
| تست سناریوهای دنیای واقعی: از داده های آزمایشی که از داده های دنیای واقعی مشتق شده اند استفاده کنید. | از داده‌های آزمایشی تولید شده خودکار تکراری یا سایر داده‌هایی که موارد استفاده در دنیای واقعی را منعکس نمی‌کنند، استفاده کنید. |
| برای حفظ کنترل تست کامل خود از مسخره‌ها و خرد برای وابستگی‌های خارجی استفاده کنید. | وابستگی هایی به خدمات شخص ثالث ایجاد کنید، به عنوان مثال، درخواست های شبکه به خدمات خارجی. |
| قبل و بعد از هر آزمایش از یک روال تمیز کردن استفاده کنید. | استفاده از اقدامات پاکسازی را در داخل آزمایشات خود فراموش کنید، در غیر این صورت به دلیل عدم ایزوله سازی مناسب، این امر می تواند منجر به شکست تست یا مثبت کاذب شود. |
چه چیزی متعلق به یک تست سرتاسر خوب است؟
یک آزمون جامع پایان به انتها باید:
- تعاملات کاربر را تکرار کنید.
- سناریوهای حیاتی را در بر بگیرد.
- چندین لایه را بپوشانید.
- مدیریت عملیات ناهمزمان
- نتایج را تأیید کنید.
- برای عملکرد حساب کنید.
| انجام دهید✅ | نکن ❌ |
|---|---|
| از میانبرهای مبتنی بر API استفاده کنید. بیشتر بدانید . | از تعاملات رابط کاربری برای هر مرحله، از جمله hook beforeEach استفاده کنید. |
| قبل از هر آزمایش از یک روال تمیز کردن استفاده کنید. حتی بیشتر از تست های واحد و ادغام مراقب جداسازی تست باشید زیرا خطر عوارض جانبی در اینجا بیشتر است. | بعد از هر آزمایش تمیز کردن را فراموش کنید. اگر وضعیت، داده‌ها یا عوارض جانبی باقیمانده را پاک نکنید، آنها روی آزمایش‌های دیگری که بعداً اجرا می‌شوند تأثیر خواهند گذاشت. |
| تست های سرتاسری را به عنوان تست های سیستم در نظر بگیرید. این بدان معنی است که شما باید کل پشته برنامه را آزمایش کنید. | هر واحد را به صورت مجزا آزمایش کنید - این همان چیزی است که تست های واحد برای آن انجام می شود. |
| در داخل آزمون از حداقل یا بدون تمسخر استفاده کنید. اگر می خواهید وابستگی های خارجی را مسخره کنید، با دقت در نظر بگیرید. | به شدت به تمسخرها تکیه کنید. |
| برای مثال، با آزمایش نکردن بیش از حد سناریوهای بزرگ در همان آزمون، عملکرد و حجم کاری را در نظر بگیرید. | بدون استفاده از میانبر، گردش های کاری بزرگ را پوشش دهید. |