stringtranslate.com

تست واحد

تست واحد یا تست کامپوننت یا ماژول ، نوعی تست نرم افزاری است که توسط آن کد منبع مجزا برای تایید رفتار مورد انتظار آزمایش می شود. [1]

تست واحد آزمایش هایی را توصیف می کند که در سطح واحد اجرا می شوند تا تست کنتراست در سطح یکپارچه سازی یا سیستم انجام شوند .

تاریخچه

تست واحد، به عنوان یک اصل برای آزمایش قطعات کوچکتر سیستم های نرم افزاری بزرگ به طور جداگانه به روزهای اولیه مهندسی نرم افزار برمی گردد. در ژوئن 1956، اچ‌دی بنینگتون در سمپوزیوم نیروی دریایی ایالات متحده در مورد روش‌های برنامه‌نویسی پیشرفته برای رایانه‌های دیجیتال، پروژه SAGE و رویکرد مبتنی بر مشخصات آن را ارائه کرد که در آن مرحله کدگذاری با "تست پارامتر" برای اعتبارسنجی زیربرنامه‌های مؤلفه بر اساس مشخصات آنها دنبال شد و سپس یک " تست مونتاژ" برای قطعات در کنار هم. [2] [3]

در سال 1964، رویکرد مشابهی برای نرم‌افزار پروژه مرکوری توصیف شد ، که در آن واحدهای منفرد توسعه‌یافته توسط برنامه‌های مختلف، قبل از ادغام با یکدیگر، تحت «آزمایش واحد» قرار گرفتند. [4] در سال 1969، روش‌های تست ساختار یافته‌تر به نظر می‌رسند، با تست‌های واحد، تست‌های اجزا و تست‌های یکپارچه‌سازی با هدف اعتبارسنجی قطعات جداگانه نوشته شده و مونتاژ پیشرونده آنها در بلوک‌های بزرگ‌تر. [5] برخی استانداردهای عمومی که در اواخر دهه 60 به تصویب رسیدند، مانند MIL-STD-483 [6] و MIL-STD-490 به پذیرش گسترده آزمایش واحد در پروژه های بزرگ کمک کردند.

آزمایش واحد در آن زمان‌ها تعاملی [3] یا خودکار بود، [7] با استفاده از آزمون‌های کدگذاری‌شده یا ابزارهای تست ضبط و پخش مجدد . در سال 1989، کنت بک یک چارچوب آزمایشی برای Smalltalk (که بعداً SUnit نامیده شد ) در "تست ساده Smalltalk: با الگوها" توصیف کرد. در سال 1997، کنت بک و اریش گاما JUnit را توسعه و منتشر کردند ، یک چارچوب تست واحد که در بین توسعه دهندگان جاوا محبوب شد . [8] گوگل در حدود سال‌های 2005-2006 آزمایش خودکار را پذیرفت. [9]

واحد

واحد به عنوان یک رفتار واحد که توسط سیستم تحت آزمایش (SUT) نشان داده می شود، تعریف می شود که معمولاً مطابق با یک نیاز است. اگرچه ممکن است به این معنی باشد که یک تابع یا یک ماژول (در برنامه‌نویسی رویه‌ای ) یا یک متد یا یک کلاس (در برنامه‌نویسی شی گرا ) است ، اما به این معنی نیست که توابع/روش‌ها، ماژول‌ها یا کلاس‌ها همیشه با واحدها مطابقت دارند. از منظر نیازمندی های سیستم، تنها محیط سیستم مرتبط است، بنابراین تنها نقاط ورودی به رفتارهای سیستم قابل مشاهده خارجی واحدها را تعریف می کنند. [10]

اعدام

تست های واحد را می توان به صورت دستی یا از طریق اجرای تست خودکار انجام داد . تست‌های خودکار شامل مزایایی مانند: اجرای آزمایش‌ها اغلب، اجرای آزمایش‌ها بدون هزینه کارکنان و آزمایش مداوم و قابل تکرار است.

آزمایش اغلب توسط برنامه نویسی انجام می شود که کد مورد آزمایش را می نویسد و تغییر می دهد. تست واحد ممکن است به عنوان بخشی از فرآیند نوشتن کد در نظر گرفته شود.

معیارهای تست

در طول توسعه، یک برنامه نویس ممکن است معیارها یا نتایجی را که خوب شناخته شده اند، در آزمون کدگذاری کند تا صحت واحد را تأیید کند.

در طول اجرای آزمون، فریم‌ورک‌ها تست‌هایی را ثبت می‌کنند که هیچ معیاری را رد می‌کنند و آن‌ها را به صورت خلاصه گزارش می‌کنند.

برای این، متداول ترین رویکرد استفاده شده تست - تابع - مقدار مورد انتظار است.

مورد آزمایشی

در مهندسی نرم‌افزار ، یک تست موردی ، مشخصات ورودی‌ها، شرایط اجرا، روش‌های آزمایش و نتایج مورد انتظار است که یک آزمایش واحد را برای دستیابی به یک هدف تست نرم‌افزار خاص اجرا می‌کند ، مانند اجرای یک مسیر برنامه خاص یا تأیید. انطباق با یک الزام خاص [11] موارد آزمایش زیربنای آزمایشی است که روشی است و نه تصادفی. یک باتری از کیس های آزمایشی می تواند ساخته شود تا پوشش مورد نظر نرم افزار مورد آزمایش را ایجاد کند. موارد آزمایشی که به طور رسمی تعریف شده اند، امکان اجرای مکرر تست های مشابه را در برابر نسخه های متوالی نرم افزار فراهم می کنند و امکان تست رگرسیون موثر و سازگار را فراهم می کنند . [12]

دوبار تست کنید

تست دوبل نرم‌افزاری است که در اتوماسیون تست نرم‌افزار استفاده می‌شود که وابستگی را برآورده می‌کند تا نیازی به آزمایش به کد تولید نباشد. یک تست دوگانه عملکردی را از طریق رابطی ارائه می دهد که نرم افزار مورد آزمایش نمی تواند آن را از کد تولید تشخیص دهد.

تست پارامتری

آزمون پارامتری ، آزمایشی است که مجموعه ای از مقادیر را می پذیرد که می توان از آنها برای فعال کردن تست با مقادیر ورودی متعدد و متفاوت استفاده کرد. یک چارچوب آزمایشی که از تست‌های پارامتری شده پشتیبانی می‌کند، راهی برای رمزگذاری مجموعه‌های پارامتر و اجرای آزمون با هر مجموعه پشتیبانی می‌کند.

استفاده از تست های پارامتری شده می تواند تکرار کد تست را کاهش دهد.

تست های پارامتری شده توسط TestNG ، JUnit ، [13] XUnit و NUnit ، و همچنین در چارچوب های مختلف تست جاوا اسکریپت پشتیبانی می شوند. [ نیازمند منبع ]

پارامترهای تست واحد ممکن است به صورت دستی کدگذاری شوند یا در برخی موارد به طور خودکار توسط چارچوب تست تولید شوند. در سال‌های اخیر پشتیبانی برای نوشتن تست‌های قوی‌تر (واحد)، استفاده از مفهوم تئوری‌ها، موارد آزمایشی که مراحل مشابه را اجرا می‌کنند، اما با استفاده از داده‌های تست تولید شده در زمان اجرا، بر خلاف تست‌های پارامتری معمولی که از مراحل اجرای یکسان با مجموعه‌های ورودی استفاده می‌کنند، اضافه شده است. که از پیش تعریف شده اند. [ نیازمند منبع ]

چابک

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

توسعه آزمایش محور

در توسعه تست محور (TDD)، تست های واحد در حالی که کد تولید نوشته می شود، نوشته می شود. با شروع کد کار، توسعه‌دهنده کد آزمایشی را برای یک رفتار مورد نیاز اضافه می‌کند، سپس کد کافی را برای موفقیت در آزمون اضافه می‌کند، سپس کد (از جمله کد تست) را به‌عنوان منطقی تغییر می‌دهد و سپس با افزودن تست دیگری تکرار می‌کند.

ارزش

آزمایش واحد برای اطمینان از اینکه واحدها با طراحی خود مطابقت دارند و همانطور که در نظر گرفته شده است رفتار می کنند در نظر گرفته شده است. [14]

با نوشتن تست ابتدا برای کوچکترین واحدهای قابل آزمایش، سپس رفتارهای ترکیبی بین آن‌ها، می‌توان تست‌های جامعی برای کاربردهای پیچیده ساخت. [14]

یکی از اهداف تست واحد جداسازی هر قسمت از برنامه و نشان دادن صحیح بودن قسمت های جداگانه است. [1] آزمون واحد یک قرارداد کتبی و سختگیرانه ارائه می دهد که قطعه کد باید آن را برآورده کند.

تشخیص زودهنگام مشکلات در چرخه توسعه

تست واحد مشکلات را در اوایل چرخه توسعه پیدا می کند . این شامل اشکالات در پیاده سازی برنامه نویس و ایرادات یا کمبود بخش هایی از مشخصات واحد می شود. فرآیند نوشتن مجموعه کاملی از تست‌ها نویسنده را مجبور می‌کند تا از طریق ورودی‌ها، خروجی‌ها و شرایط خطا فکر کند و بنابراین رفتار مورد نظر واحد را واضح‌تر تعریف کند. [ نیازمند منبع ]

کاهش هزینه

هزینه یافتن یک باگ قبل از شروع کدنویسی یا زمانی که کد برای اولین بار نوشته می‌شود، به‌طور قابل‌توجهی کمتر از هزینه شناسایی، شناسایی و تصحیح باگ است. اشکالات موجود در کدهای منتشر شده نیز ممکن است مشکلات پرهزینه ای را برای کاربران نهایی نرم افزار ایجاد کند. [15] [16] [17] اگر کد ضعیف نوشته شود، آزمایش واحد غیرممکن یا دشوار است، بنابراین آزمایش واحد می‌تواند توسعه‌دهندگان را مجبور کند که توابع و اشیاء را به روش‌های بهتری ساختار دهند.

انتشارات بیشتر

تست واحد امکان انتشار بیشتر در توسعه نرم افزار را فراهم می کند. با آزمایش اجزای جداگانه به صورت مجزا، توسعه‌دهندگان می‌توانند به سرعت مشکلات را شناسایی و برطرف کنند، که منجر به چرخه‌های تکرار و انتشار سریع‌تر می‌شود. [18]

امکان بازآفرینی کد را فراهم می کند

تست واحد به برنامه نویس اجازه می دهد تا کد را اصلاح کند یا کتابخانه های سیستم را در تاریخ بعدی ارتقا دهد و مطمئن شود که ماژول همچنان به درستی کار می کند (مثلاً در آزمایش رگرسیون ). روش کار به این صورت است که برای همه عملکردها و روش ها موارد آزمایشی نوشته می شود تا هر زمان که تغییری باعث خطا شد، بتوان به سرعت آن را شناسایی کرد.

تغییراتی را که ممکن است قرارداد طراحی را به هم بزند را تشخیص می دهد

تست های واحد تغییراتی را که ممکن است یک قرارداد طراحی را به هم بزند را شناسایی می کند .

عدم قطعیت را کاهش دهید

آزمایش واحد ممکن است عدم قطعیت را در خود واحدها کاهش دهد و می تواند در رویکرد سبک تست از پایین به بالا استفاده شود . با آزمایش قطعات یک برنامه ابتدا و سپس آزمایش مجموع قطعات آن، تست یکپارچه سازی بسیار آسان تر می شود. [ نیازمند منبع ]

مستندسازی رفتار سیستم

برخی از برنامه نویسان معتقدند که تست های واحد شکلی از مستندات کد را ارائه می دهند. توسعه دهندگانی که می خواهند بدانند چه عملکردی توسط یک واحد ارائه می شود و چگونه از آن استفاده کنند، می توانند تست های واحد را بررسی کنند تا درک درستی از آن به دست آورند. [ نیازمند منبع ]

موارد تست می توانند ویژگی هایی را در بر گیرند که برای موفقیت واحد بسیار مهم هستند. این ویژگی ها می تواند نشان دهنده استفاده مناسب/نادرست از یک واحد و همچنین رفتارهای منفی باشد که قرار است توسط واحد به دام بیفتد. یک مورد آزمایشی این ویژگی‌های حیاتی را مستند می‌کند، اگرچه بسیاری از محیط‌های توسعه نرم‌افزار برای مستندسازی محصول در حال توسعه صرفاً به کد متکی نیستند. [ نیازمند منبع ]

در برخی از فرآیندها، عمل نوشتن تست ها و کد مورد آزمایش، به علاوه بازآفرینی مرتبط، ممکن است جای طراحی رسمی را بگیرد. هر آزمون واحد را می توان به عنوان یک عنصر طراحی که کلاس ها، روش ها و رفتار قابل مشاهده را مشخص می کند، دیده می شود. [ نیازمند منبع ]

محدودیت ها و معایب

آزمایش تمام خطاهای برنامه را نمی‌گیرد، زیرا نمی‌تواند هر مسیر اجرا را در هیچ برنامه‌ای به جز بی‌اهمیت‌ترین برنامه‌ها ارزیابی کند. این مشکل ابر مجموعه ای از مسئله توقف است که غیرقابل تصمیم گیری است . همین امر در مورد تست واحد نیز صادق است. علاوه بر این، تست واحد طبق تعریف فقط عملکرد خود واحدها را آزمایش می کند. بنابراین، خطاهای ادغام یا خطاهای گسترده‌تر در سطح سیستم (مانند عملکردهایی که در چندین واحد انجام می‌شوند، یا حوزه‌های آزمایشی غیرعملکردی مانند عملکرد ) را نمی‌گیرد. تست واحد باید همراه با سایر فعالیت های تست نرم افزار انجام شود ، زیرا آنها فقط می توانند وجود یا عدم وجود خطاهای خاص را نشان دهند. آنها نمی توانند عدم وجود کامل خطا را ثابت کنند. برای تضمین رفتار صحیح برای هر مسیر اجرا و هر ورودی ممکن، و اطمینان از عدم وجود خطا، تکنیک‌های دیگری مورد نیاز است، یعنی استفاده از روش‌های رسمی برای اثبات اینکه یک جزء نرم‌افزار رفتار غیرمنتظره‌ای ندارد. [ نیازمند منبع ]

یک سلسله مراتب دقیق از آزمون های واحد، با آزمایش ادغام برابری نمی کند. ادغام با واحدهای جانبی باید در تست های ادغام گنجانده شود، اما نه در تست های واحد. [ نیازمند منبع ] آزمایش ادغام معمولاً هنوز هم به شدت به آزمایش دستی انسان وابسته است . تست سطح بالا یا مقیاس جهانی می تواند به صورت خودکار دشوار باشد، به طوری که آزمایش دستی اغلب سریعتر و ارزان تر به نظر می رسد. [ نیازمند منبع ]

تست نرم افزار یک مشکل ترکیبی است. به عنوان مثال، هر عبارت تصمیم بولی حداقل به دو آزمون نیاز دارد: یکی با نتیجه "درست" و دیگری با یک نتیجه "نادرست". در نتیجه، برای هر خط کد نوشته شده، برنامه نویسان اغلب به 3 تا 5 خط کد تست نیاز دارند. [ نیاز به منبع ] بدیهی است که این کار زمان می برد و سرمایه گذاری آن ممکن است ارزش تلاش را نداشته باشد. مشکلاتی وجود دارد که به هیچ وجه نمی توان آنها را به راحتی آزمایش کرد - برای مثال مواردی که غیر قطعی هستند یا شامل چندین رشته هستند . علاوه بر این، کد برای یک تست واحد به همان اندازه احتمال دارد که کدی که در حال آزمایش است باگ باشد. فرد بروکس در ماه مرد اسطوره‌ای می‌گوید: «هرگز با دو کرونومتر به دریا نروید، یک یا سه زمان سنج بگیرید». [19] یعنی اگر دو زمان سنج با هم تضاد داشته باشند، چگونه می دانید کدام یک صحیح است؟

مشکل در تنظیم آزمون های واقعی و مفید

یکی دیگر از چالش های مربوط به نوشتن تست های واحد، دشواری تنظیم تست های واقعی و مفید است. لازم است شرایط اولیه مربوطه ایجاد شود تا بخشی از برنامه مورد آزمایش مانند بخشی از سیستم کامل رفتار کند. اگر این شرایط اولیه به درستی تنظیم نشود، آزمون کد را در یک زمینه واقعی اعمال نمی کند، که ارزش و دقت نتایج آزمون واحد را کاهش می دهد. [ نیازمند منبع ]

نیاز به نظم و انضباط در طول فرآیند توسعه دارد

برای به دست آوردن مزایای مورد نظر از تست واحد، نظم و انضباط دقیق در سراسر فرآیند توسعه نرم افزار مورد نیاز است.

به کنترل نسخه نیاز دارد

حفظ سوابق دقیق نه تنها از تست های انجام شده، بلکه همچنین از تمام تغییراتی که در کد منبع این یا هر واحد دیگری در نرم افزار ایجاد شده است، ضروری است. استفاده از سیستم کنترل نسخه ضروری است. اگر نسخه بعدی واحد در آزمون خاصی که قبلاً آن را گذرانده بود رد شود، نرم افزار کنترل نسخه می تواند فهرستی از تغییرات کد منبع (در صورت وجود) که از آن زمان بر روی واحد اعمال شده است ارائه دهد. [ نیازمند منبع ]

نیاز به بررسی منظم دارد

همچنین اجرای یک فرآیند پایدار برای حصول اطمینان از اینکه خرابی های مورد آزمایش به طور منظم بررسی شده و بلافاصله رسیدگی می شود ضروری است. [20] اگر چنین فرآیندی پیاده‌سازی نشود و در جریان کاری تیم گنجانده نشود، برنامه با مجموعه آزمایشی واحد خارج از همگامی تکامل می‌یابد، مثبت کاذب را افزایش می‌دهد و اثربخشی مجموعه آزمایشی را کاهش می‌دهد.

محدودیت های نرم افزار سیستم تعبیه شده

تست واحد نرم افزار سیستم تعبیه شده یک چالش منحصر به فرد را ارائه می دهد: از آنجایی که نرم افزار بر روی پلت فرمی متفاوت از پلتفرمی که در نهایت روی آن اجرا می شود توسعه می یابد، شما نمی توانید به راحتی یک برنامه آزمایشی را در محیط استقرار واقعی اجرا کنید، همانطور که با برنامه های دسکتاپ امکان پذیر است. [21]

محدودیت‌های آزمایش ادغام با سیستم‌های خارجی

زمانی که یک روش دارای پارامترهای ورودی و مقداری خروجی باشد، آزمایش‌های واحد ساده‌تر هستند. هنگامی که یکی از عملکردهای اصلی روش تعامل با چیزی خارج از برنامه کاربردی است، ایجاد تست های واحد به آسانی نیست. به عنوان مثال، روشی که با یک پایگاه داده کار می کند ممکن است نیاز به ساخت مدلی از تعاملات پایگاه داده داشته باشد که احتمالاً به اندازه تعاملات واقعی پایگاه داده جامع نخواهد بود. [22] [ منبع بهتر مورد نیاز است ]

نمونه ها

JUnit

در زیر نمونه ای از مجموعه تست JUnit آورده شده است. روی کلاس تمرکز دارد Adder.

class  Adder { public int add ( int a , int b ) { return a + b ; } }

مجموعه آزمایشی از دستورات ادعایی برای تأیید نتیجه مورد انتظار مقادیر ورودی مختلف به sumروش استفاده می کند.

import static org.junit.Assert.assertEquals ; واردات org.junit.Test ; کلاس عمومی AdderUnitTest { @Test public void sumReturnsZeroForZeroInput () { Adder adder = new Adder (); assertEquals ( 0 , adder . add ( 0 , 0 )); }                    @Test public void sumReturnsSumOfTwoPositiveNumbers () { Adder adder = new Adder (); assertEquals ( 3 , adder . add ( 1 , 2 )); }              @Test public void sumReturnsSumOfTwoNegativeNumbers () { Adder adder = new Adder (); assertEquals ( - 3 , adder . add ( - 1 , - 2 )); }              @Test public void sumReturnsSumOfLargeNumbers () { Adder adder = new Adder (); assertEquals ( 2222 , adder . add ( 1234 , 988 )); } }

به عنوان مشخصات اجرایی

استفاده از آزمون‌های واحد به‌عنوان مشخصات طراحی، یک مزیت مهم نسبت به سایر روش‌های طراحی دارد: سند طراحی (آزمایش‌های واحد) خود می‌تواند برای تأیید پیاده‌سازی استفاده شود. تست ها هرگز موفق نمی شوند مگر اینکه توسعه دهنده راه حلی را مطابق با طراحی اجرا کند.

تست واحد برخی از قابلیت دسترسی به مشخصات نموداری مانند نمودار UML را ندارد ، اما ممکن است آنها از آزمون واحد با استفاده از ابزارهای خودکار تولید شوند. اکثر زبان های مدرن دارای ابزارهای رایگان هستند (معمولاً به عنوان پسوند IDE ها در دسترس هستند ). ابزارهای رایگان، مانند ابزارهای مبتنی بر چارچوب xUnit ، ارائه گرافیکی یک view را برای مصرف انسانی به سیستم دیگری برون سپاری می کنند.

برنامه های کاربردی

برنامه نویسی افراطی

تست واحد سنگ بنای برنامه نویسی افراطی است که بر چارچوب تست واحد خودکار متکی است . این چارچوب تست واحد خودکار می تواند شخص ثالث باشد، به عنوان مثال، xUnit ، یا در گروه توسعه ایجاد شود.

برنامه نویسی شدید از ایجاد تست های واحد برای توسعه آزمایش محور استفاده می کند . توسعه‌دهنده یک تست واحد می‌نویسد که یک نیاز نرم‌افزاری یا یک نقص را نشان می‌دهد. این تست به این دلیل ناموفق خواهد بود که یا مورد نیاز هنوز اجرا نشده است یا به این دلیل که عمداً نقصی در کد موجود نشان می دهد. سپس، توسعه‌دهنده ساده‌ترین کد را می‌نویسد تا آزمون را به همراه سایر آزمون‌ها قبول کند.

اکثر کدهای یک سیستم واحد تست می شوند، اما نه لزوماً همه مسیرها از طریق کد. برنامه نویسی افراطی یک استراتژی "آزمایش هر چیزی که احتمالاً می تواند شکسته شود" را بر روی روش سنتی "تست هر مسیر اجرا" الزامی می کند. این امر باعث می‌شود که توسعه‌دهندگان نسبت به روش‌های کلاسیک، تست‌های کمتری را توسعه دهند، اما این واقعاً یک مشکل نیست، بیشتر یک بیان مجدد واقعیت است، زیرا روش‌های کلاسیک به ندرت به اندازه کافی روشمند دنبال شده‌اند که همه مسیرهای اجرا به طور کامل آزمایش شده باشند. [ نیاز به نقل از ] برنامه نویسی افراطی به سادگی تشخیص می دهد که آزمایش به ندرت جامع است (زیرا اغلب بسیار گران و زمان بر است تا از نظر اقتصادی مقرون به صرفه باشد) و راهنمایی هایی را در مورد چگونگی تمرکز موثر منابع محدود ارائه می دهد.

مهمتر از همه، کد آزمایشی یک مصنوع پروژه درجه یک در نظر گرفته می‌شود، زیرا با کیفیتی مشابه کد پیاده‌سازی حفظ می‌شود و تمامی موارد تکراری حذف می‌شود. توسعه دهندگان کد تست واحد را به همراه کدی که آزمایش می کند در مخزن کد منتشر می کنند. آزمایش واحد کامل برنامه نویسی Extreme مزایای ذکر شده در بالا را امکان پذیر می کند، مانند توسعه کد ساده تر و مطمئن تر ، یکپارچه سازی کد ساده، مستندسازی دقیق، و طراحی های مدولارتر. این آزمون های واحد نیز به طور مداوم به عنوان یک آزمون رگرسیون اجرا می شوند .

تست واحد نیز برای مفهوم Emergent Design حیاتی است . از آنجایی که طراحی اضطراری به شدت به بازسازی مجدد وابسته است، تست های واحد جزء جدایی ناپذیر هستند. [ نیازمند منبع ]

چارچوب های تست خودکار

یک چارچوب تست خودکار ویژگی‌هایی را برای خودکارسازی اجرای تست فراهم می‌کند و می‌تواند نوشتن و اجرای تست‌ها را تسریع کند. فریم‌ورک‌ها برای طیف گسترده‌ای از زبان‌های برنامه‌نویسی توسعه یافته‌اند .

به طور کلی، چارچوب ها شخص ثالث هستند . با یک کامپایلر یا محیط توسعه یکپارچه (IDE) توزیع نشده است.

تست‌ها را می‌توان بدون استفاده از چارچوبی برای اعمال کد تحت آزمایش با استفاده از اظهارات ، مدیریت استثنا و سایر مکانیسم‌های جریان کنترل برای تأیید رفتار و گزارش شکست نوشت. برخی توجه دارند که آزمایش بدون چارچوب ارزشمند است زیرا مانعی برای ورود برای پذیرش یک چارچوب وجود دارد. که داشتن برخی از تست‌ها بهتر از هیچ‌کدام است، اما زمانی که چارچوبی ایجاد شد، اضافه کردن تست‌ها می‌تواند آسان‌تر باشد. [23]

در برخی چارچوب‌ها، ویژگی‌های تست پیشرفته وجود ندارد و باید به صورت دستی کدگذاری شوند.

پشتیبانی از آزمون واحد سطح زبان

برخی از زبان های برنامه نویسی به طور مستقیم از تست واحد پشتیبانی می کنند. دستور زبان آنها امکان اعلام مستقیم تست های واحد را بدون وارد کردن کتابخانه (چه شخص ثالث یا استاندارد) می دهد. بعلاوه، شرایط بولی تست های واحد را می توان با همان نحوی که عبارات بولی که در کد تست غیر واحدی استفاده می شود، مانند آنچه برای ifو whileعبارات استفاده می شود، بیان کرد.

زبان های دارای پشتیبانی تست واحد داخلی عبارتند از:

زبان‌هایی که از چارچوب تست واحد استاندارد پشتیبانی می‌کنند عبارتند از:

برخی از زبان‌ها پشتیبانی داخلی تست واحد ندارند، اما کتابخانه‌ها یا چارچوب‌هایی برای تست واحد ایجاد کرده‌اند. این زبان ها عبارتند از:

همچنین ببینید

مراجع

  1. ^ اب کلاوا، آدم; هویزینگا، دوروتا (2007). پیشگیری خودکار از نقص: بهترین روش ها در مدیریت نرم افزار . Wiley-IEEE Computer Society Press. ص 75. شابک 978-0-470-04212-0.
  2. ↑ بنینگتون، هربرت دی (1956). "تولید برنامه های کامپیوتری بزرگ". مجموعه مقالات سمپوزیوم روشهای برنامه نویسی پیشرفته برای رایانه های دیجیتال، واشنگتن، دی سی، 28-29 ژوئن 1956 . دفتر تحقیقات نیروی دریایی، گروه نیروی دریایی: 15-28.
  3. ^ ab Benington، HD (1 مارس 1987). "تولید برنامه های کامپیوتری بزرگ (چاپ مجدد مقاله 1956 با پیشگفتار به روز شده)". مجموعه مقالات نهمین کنفرانس بین المللی مهندسی نرم افزار . ICSE '87. واشنگتن، دی سی، ایالات متحده: IEEE Computer Society Press: 299–310. شابک 978-0-89791-216-7.
  4. ↑ دونگان، جیمز جی. پاکارد، کالوین؛ پاشبی، پل (1 ژانویه 1964). "تجربیات با سیستم محاسباتی گدارد در طی ماموریت های پرواز فضایی سرنشین دار". مجموعه مقالات نوزدهمین کنفرانس ملی ACM 1964 . ACM '64. نیویورک، نیویورک، ایالات متحده آمریکا: انجمن ماشین‌های محاسباتی. صفحات 12.101-12.108. doi : 10.1145/800257.808889. شابک 978-1-4503-7918-2.
  5. ↑ Zimmerman, Norman A. (26 اوت 1969). "یکپارچه سازی سیستم به عنوان یک تابع برنامه نویسی". مجموعه مقالات بیست و چهارمین کنفرانس ملی 1969 . ACM '69. نیویورک، نیویورک، ایالات متحده آمریکا: انجمن ماشین‌های محاسباتی. صص 459-467. doi :10.1145/800195.805951. شابک 978-1-4503-7493-4.
  6. ^ استاندارد نظامی MIL-STD-483: شیوه های مدیریت پیکربندی برای سیستم ها، تجهیزات، مهمات و برنامه های کامپیوتری . ایالات متحده، وزارت دفاع. 31 دسامبر 1970. ص. بخش 3.4.7.2. سپس پیمانکار باید واحدهای نرم افزاری را کدنویسی و آزمایش کند و کد منبع و شیء و فهرست های مربوط به هر واحد آزمایش شده با موفقیت را در پیکربندی توسعه وارد کند.{{cite book}}: CS1 maint: date and year (link)
  7. ↑ Tighe، Michael F. (1 ژانویه 1978). "ارزش یک روش مناسب تضمین کیفیت نرم افزار". بررسی ارزیابی عملکرد ACM SIGMETRICS . 7 (3-4): 165-172. doi :10.1145/1007775.811118. ISSN  0163-5999.
  8. ↑ گولاتی، شکر (1396). تست واحد جاوا با JUnit 5 : توسعه تست محور با JUnit 5 . راهول شارما. برکلی، کالیفرنیا: Apress. ص 8. ISBN 978-1-4842-3015-2. OCLC  1012347252.
  9. ↑ Winters, Titus (2020). مهندسی نرم افزار در گوگل: درس های آموخته شده از برنامه نویسی در طول زمان . تام منشرک، هیروم رایت (ویرایش اول). سباستوپل، کالیفرنیا: اوریلی. شابک 978-1-4920-8274-3. OCLC  1144086840.
  10. ↑ بک، کنت (2002). توسعه آزمایش محور با مثال . ادیسون-وسلی. شابک 978-0321146533.
  11. ^ مهندسی سیستم ها و نرم افزار -- واژگان . ISO/Iec/IEEE 24765:2010(E). 1 دسامبر 2010. صفحات 1–418. doi :10.1109/IEEESTD.2010.5733835. شابک 978-0-7381-6205-8.
  12. ↑ کانر، جم (مه 2003). "یک مورد تست خوب چیست؟" (PDF) . STAR East : 2.
  13. ↑ Gulati & Sharma 2017، صفحات 133–137، فصل §7 JUnit 5 Extension Model - Test Parameterized.
  14. ^ آب هامیل، پل (2004). چارچوب های تست واحد: ابزارهایی برای توسعه نرم افزار با کیفیت بالا. O'Reilly Media, Inc. ISBN 9780596552817.
  15. ^ بوهم، بری دبلیو . Papaccio, Philip N. (اکتبر 1988). "درک و کنترل هزینه های نرم افزار" (PDF) . معاملات IEEE در مهندسی نرم افزار . 14 (10): 1462-1477. doi :10.1109/32.6191. بایگانی شده از نسخه اصلی (PDF) در 9 اکتبر 2016 . بازبینی شده در 13 مه 2016 .
  16. ↑ «تست زودهنگام و اغلب». مایکروسافت.
  17. ↑ «اثبات این کار: استفاده از چارچوب تست واحد برای تست و اعتبارسنجی نرم افزار». ابزار ملی 21 آگوست 2017.
  18. ↑ اریک (10 مارس 2023). "شما هنوز نمی دانید چگونه تست واحد انجام دهید (و راز شما با من امن است)". Stackify ​بازیابی شده در 10 مارس 2023 .
  19. ↑ بروکس، فردریک جی (1995) [1975]. ماه مرد اسطوره ای . ادیسون-وسلی. ص 64. شابک 978-0-201-83595-3.
  20. ↑ داویگا، نادا (6 فوریه 2008). "تغییر کد بدون ترس: از شبکه ایمنی رگرسیون استفاده کنید" . بازیابی شده در 8 فوریه 2008 .
  21. ↑ کوچارسکی، مارک (23 نوامبر 2011). "عملی ساختن تست واحد برای توسعه تعبیه شده" . بازیابی شده در 20 ژوئیه 2020 .
  22. ↑ «تست‌ها و پایگاه‌های داده واحد» . بازبینی شده در 29 ژانویه 2024 .
  23. ^ فناوری تست Bullsye (2006-2008). "اهداف پوشش متوسط" . بازیابی شده در 24 مارس 2009 .
  24. ↑ "تست های واحد - زبان برنامه نویسی D". زبان برنامه نویسی D. بنیاد زبان دی . بازبینی شده در 5 اوت 2017 .
  25. ↑ استیو کلابنیک و کارول نیکولز، با مشارکت انجمن Rust (2015-2023). "چگونه تست بنویسیم" . بازبینی شده در 21 اوت 2023 .
  26. ↑ «مشخصات کریستال». crystal-lang.org . بازبینی شده در 18 سپتامبر 2017 .
  27. ^ "تست - زبان برنامه نویسی Go". golang.org . بازبینی شده در 3 دسامبر 2013 .
  28. ↑ «تست واحد · زبان جولیا». docs.julialang.org . بازبینی شده در 15 ژوئن 2022 .
  29. ^ اسناد پایتون (2016). "unittest - چارچوب تست واحد" . بازبینی شده در 18 آوریل 2016 .
  30. ^ ولش، نوئل؛ کالپپر، رایان. "RackUnit: تست واحد". PLT Design Inc. بازبینی شده در 26 فوریه 2019 .
  31. ^ ولش، نوئل؛ کالپپر، رایان. "بسته تست واحد RackUnit بخشی از توزیع اصلی Racket". PLT Design Inc. بازبینی شده در 26 فوریه 2019 .
  32. ↑ «Minitest (Ruby 2.0)». Ruby-Doc.org.
  33. ^ سیرا، استوارت. "API برای clojure.test - Clojure نسخه 1.6 (پایدار)" . بازبینی شده در 11 فوریه 2015 .
  34. ↑ «چارچوب Pester». GitHub . بازبینی شده در 28 ژانویه 2016 .

در ادامه مطلب

لینک های خارجی