خلاصه‌ی The Clean Coder - قسمت ۰۸ - استراتژی‌های تست کردن
این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.
تست کردن فقط این نیست که چند تا تست واحد (unit test) و چندتا تست پذیریش (acceptance test) داشته باشیم. هر تیم توسعه‌ی حرفه‌ای لازمه که یه استراتژی داشته باشه واسه تست کردن.
این یه پاراگراف شاید مهم نباشه ولی جالب بود واسه من، واسه همین توی پرانتز بخونیدش. همون اوایل فصل اشاره می‌کنه به اینکه تو شرکتی که سال ۱۹۸۹ کار می‌کرده، تقریبا هر یه ماه یکبار یه مراسم پر فیض و ملکوتی داشتن که بهش می‌گفتن Bug Hunt یا «شکار باگ». که تو اون روز از توسعه‌دهنده گرفته تا مدیرها و منشی‌ها، محصولات رو تست می‌کردن و سعی می‌کردن باگ پیدا کنن. بسته به باگی که پیدا می‌کردن، جایزه‌هایی از شرکت می‌گرفتن. این رو الزاما به‌عنوان توصیه نمی‌گه. تیم تست نباید هیچ باگی پیدا کنه
هدف تیم توسعه باید این باشه که تیم تست، هیچ باگی توش پیدا نکنه.
احتمال همیشه رسیدن به این هدف خیلی کمه ولی با این وجود، هر بار تیم تست یه ایرادی تو محصول پیدا می‌کنه، تیم توسعه باید وحشت کنه. باید از خودشون بپرسن «چی‌شده که این باگ از دستمون در رفته؟» و کاری کنن که دفعه‌ی بعد این اتفاق نیفته.
تیم بیزنس و تیم تست باید باهم تست‌های پذیرش رو بنویسن. تیم بیزنس تمرکزش رو نوشتن تست‌های happy-path هست (حالت سر راست استفاده از محصول) و تیم تست تمرکزش رو نوشتن تست‌ها unhappy-path (حالت‌های حدی و خاص و استثناها و ...).
هرم اتوماسیون تست‌ها
توسعه دهنده‌های حرفه‌ای، از روش TDD (توسعه‌ی تست محور) استفاده می‌کنن واسه نوشتن تست‌های واحد.
این هرم نشون می‌ده که یه تیم توسعه‌ی حرفه‌ای، به چه نوع تست‌هایی نیاز داره و هر کدومشون چند درصد از سیستم رو باید پوشش بدن.
هرم اتوماسیون تست‌ها
تست واحد: تست‌هایی هستن که توسط توسعه‌دهنده‌ها و برای توسعه‌دهنده‌ها نوشته می‌شن. هدف این تست‌ها، مشخص کردن [رفتار] سیستم تو پایین‌ترین سطحه. این تست‌ها به عنوان بخشی از continuous integration (یکپارچه‌سازی مداوم) اجرا می‌شن. این تست‌ها باید نزدیک به ۱۰۰٪ کد رو پوشش بدن.
تست اجزا (component test): این‌ها بخشی از تست‌های پذیریشی هستن که قبلا راجبش صحبت کردیم که واسه اجزای سیستم به طور جداگانه نوشته شدن. اجزای سیستم، business rules (قوانین بیزنس) رو مشخص می‌کنن، بخاطر همین این تست‌ها، تست‌های پذیرش مربوط به اون بخش از قوانین بیزنس می‌شن.
تست‌های اجزا رو تیم‌های بیزنس و تست با کمک تیم توسعه می‌نویسن. اجزایی که رابط کاربری گرافیکی (GUI) دارن، با ابزارهایی مثل Selenium یا Watir تست می‌شن.
این تست‌ها تقریبا نصف سیستم رو پوشش می‌دن. بیش‌تر برای حالت‌های happy-path و حالت‌های حدی و خاصِ نسبتا واضح نوشته می‌شن.
تست یکپارچگی (integration test): واسه سیستم‌های بزرگی که اجزا (component)ی متعددی دارن معنی داره همیچین تستی. تست‌هایی هستن که برای مجموعه‌ای از اجزا که با هم در ارتباط هستن نوشته می‌شن. این‌ها قوانین بیزنس رو تست نمی‌کنن، بجاش تمرکزشون رو اینه که این اجزا تو همکاری با هم چطور کار می‌کنن.
تست‌های یکپارچگی معمولا توسط معمارهای سیستم (system architects) یا طراح‌های اصلی (lead designers) نوشته می‌شن. [اگه فرقشون رو می‌دونید لطفا تو کامنت‌ها بنویسید]
ممکنه بین این تست‌ها، تست‌های مربوط به عملکرد و توان عملیاتی (throughput) رو هم ببینیم.
این تست‌ها معمولا بعنوان بخشی از CI اجرا نمی‌شن چون معمولا زمان اجرای طولانی‌تری دارن. بجاش، تو فاصله‌های زمانی طولانی‌تر (هر روز یا هفته یا ... یه بار) اجرا می‌شن.
تست‌های سیستمی (system tests): این‌ها تست‌هایی هستن که واسه تمامیت یکپارچه‌ی سیستم نوشته می‌شن. مستقیما قوانین بیزنس رو تست نمی‌کنن. کارشون اینه که تست کنن که قسمت‌های مختلف سیستم درست به هم وصل شدن و قسمت‌های مختلف طبق نقشه با هم به درستی کار می‌کنن. اینجا هم تست‌های عملکردی و توان عملیاتی رو می‌بینیم.
این تست‌ها رو هم معمارهای سیستم یا طراح‌های اصلی می‌نویسن.
بسته به زمانی که طول می‌کشه اجرا شن، تا جای ممکن تو فواصل زمانی کم اجرا می‌شن.
حدود ۱۰٪ از سیستم رو پوشش می‌دن چون کارشون تایید رفتار سیستم نیست، تایید ساخت (construction) درستشه.
تست‌های اکتشافی (manual exploratory tests): این یه جورایی همون مراسم bug hunt هست که ذکر خیرش اول متن بود.
این تست‌ها اتوماتیک نیستن و اسکریپتی واسشون نوشته نمی‌شه و آدم‌ها به‌طور دستی انجامشون می‌دن.
بعضی تیم‌ها ممکنه متخصص‌هایی رو دعوت کنن که محصولشون رو اینجور تست کنن و دیگران ممکنه از مدیر و منشی و تیم بیزنس و هر کی که خلاصه دم دست هست استفاده کنن!
اینجا هدف پوشش کُد نیست. اینه که ببینیم محصولمون وقتی کاربرامون تو دنیای واقعی ازش استفاده می‌کنن چه رفتاری از خودش نشون می‌ده و تا جای ممکنه چیز میزای عجیبی که تو محصول وجود دارن رو هم پیدا کنیم!
