نوشتن Test و اهمیت آن در توسعه نرم‌افزار امروزه بر کسی پوشیده نیست. اما موضوع مهم این است که کدنویسی تمیز نه تنها در نوشتن Production Code بلکه در نوشتن Test Code نیز باید لحاظ بشود. به عبارت دیگر، مباحثی که تا به اینجای کار مطرح کرده‌ایم برای Test Code ها نیز صدق می کند.
برای تست های خوب ویژگی های متعددی تعریف شده است که منجر به تمیز شدن آنها می گردد.
زمانی که بحث از اجرای یونیت تست ها می شود سرعت بسیار مهم است. ماهیت Unit Test و یا تست واحد در واقع تستی است که فقط بخش کوچکی از Codebase برای مثال یک کلاس تک را تست می کند بنابراین باید با سرعت بسیار بالایی اجرا بشود. البته هیچ قانون مطلقی برای سرعت و یا حداکثر زمان مورد نیاز برای اجرا شدن یک یونیت تست وجود ندارد. اما به طور کلی، اگر برنامه نویسان برای اجرا کردن تمامی یونیت تست ها مجبور باشند ۳۰ دقیقه صبر کنند بدون شک مشکلی در سیستم وجود دارد.
یکی از دلایل استفاده کردن از Unit Test ها دریافت بازخورد سریع پس از اعمال تغییرات و ریفکتور کردن کد می باشد. زمانی که یک برنامه نویس تعدادی از تست ها را اجرا می کند به طور کلی، باید بتواند در مدت زمان کمی بازخورد مربوط به تغییرات ایجاد شده را دریافت کند. بطور کلی تمامی تست‌های موجود در برنامه باید در چند ثانیه و نه چند دقیقه اجرا بشود. البته حداکثر زمان مورد نیاز برای اجرا شدن تست ها بستگی به تعداد، اندازه و حتی پیچیدگی آنها دارد. علاوه بر این، خود Production Code که توسط Test Code مورد تست شدن قرار می‌گیرد نیز می‌تواند بر روی سرعت تأثیر بگذارد.
از طرفی Integration Test ها و یا تست های یکپارچگی که بر اساس ارتباط برنامه با دیگر منابع از قبیل دیتابیس ها و یا فایل سیستم کار می‌کنند نیز باید مورد توجه قرار بگیرند. سرعت اجرا شدن Integration Test ها به مراتب کمتر از Unit Test ها خواهد بود.
یکی دیگر از ویژگی های Unit Test ها و اجرا شدن آنها این است که باید به صورت مستقل و ایزوله شده اجرا بشوند. به عبارت دیگر، باید بتوان تست های موجود را به هر ترتیب خاص و بدون تأثیر گذاردن بر روی نتایج دیگر Test ها اجرا کرد. یک Test نباید به یک Test دیگر وابسته باشد و باید بتوان قبل از اجرا شدن هر کدام از تست ها، برنامه را در یک حالت اولیه قرار داد. این موضوع در بسیاری از فریم ورک های نوشتن Test انجام پذیر است.
ویژگی دیگر تست ها این است که باید قابل تکرار و قابل اعتماد باشند. به عبارت دیگر، اگر تستی مورد قبول قرار می گیرد و یا اصطلاحاً Pass می شود باید همواره چنین رفتاری را از خود نشان بدهد. در صورت شکست خوردن و یا اصطلاحاً Fail شدن Test نیز نباید این رفتار تغییر کند. به عبارت دیگر، Test ها باید در Pass شدن و یا Fail شدن خود Consistent و یا یک شکل ظاهر بشوند. اگر تستی در بعضی از اوقات Pass می‌شود و در بعضی اوقات Fail می‌شود نمی‌توان گفت که این تست قابل تکرار و قابل اعتماد است. نتایج تست ها باید قابل اعتماد باشند و نیازی نباشد که حدس بزنیم که آیا این تست Pass خواهد شد و یا Fail خواهد شد.
یکی دیگر از قابلیت تستها ارزشمند بودن آنهاست. در واقع نوشتن یک Test و نگهداری کردن از آن هزینه هایی را شامل می شود. به همین دلیل باید تستها را طوری نوشت که ارزشی به برنامه اضافه کند. این یک موضوع بسیار مهم است و صد درصد نوشتن تست هایی که قسمت های غیر ضروری برنامه را تست می‌کنند عملاٌ ارزشی به برنامه اضافه نمی کند.
تغییراتی که بر روی Production Code بدون شک اتفاق می افتند اغلب نیازمند ایجاد تغییر بر روی Test Code ها نیز می باشد. ایجاد تغییر در Production Code به دلیل تغییر در نیازمندیها بدون شک رخ خواهد داد. این که Test Code ها بر اساس تغییرات Production Code تغییر کنند یک موضوع قابل انتظار و غیر قابل اجتناب است و هزینه هایی نیز دارند. البته باید بتوان با روش‌های مختلفی حجم تغییرات مورد نیاز بر روی Test Code ها پس از تغییر کردن Production Code را به حداقل رساند. این کار با استفاده از ابزارهایی شبیه به AutoFixture قابل انجام خواهد بود.
منبع: وبسایت پرووید
