نکته : تمامی این نوشته ، مانند تمامی نوشته های این وبلاگ بر اساس تجربه شخصی و سوادِ کمِ یک خر حاصل شده است.
در قسمت قبل کمی توضیح دادم که درست و حسابی تقلید کنیم. در این قسمت می خواهم در مورد ادعاها و گند هایی که منِ خرِ نوعی می توانم بزنم ، صبحت یا عر عر کنم.
یک تفاوت اساسی بین تست (TEST ) و دیباگ (DEBUG) وجود دارد. اگر آن را نمی دانید ، کلید های ترکیبی ALT +F4 را فشار دهید و دیگر به این سری نوشته ها سر نزنید.
عزیز جان ، عزیز دل ، کدی که تو می نویسی و به قول خودت تست می کنی و چند تایی ورودی به آن می دهی و می بینی درست کار می کند ، دیباگ است نه تست. البته به منظر جنابعالی شاید تست باشد ، اما به منظر منِ خر دیباگ است.
اگر می خواهی بدانی که تست چیست ، ابتدا باید بدانی که سیستمی که برایش نرم افزار می سازی، چیست و چگونه کار می کند. با تاکید می گویم ، ساخت نرم افزار نه نوشتن نرم افزار ، چون نوشتن نرم افزار برای همان کسانی است که فرق بین تست و دیباگ را نمی فهمند.
خب اگر فهمیدی یا دانستی که سیستم چگونه کار می کند ، آنوقت است که مشخص می شود به چه تست هایی نیاز داری.
تست ها هر کدام دسته بندی مختلفی دارند. از Unit Test شروع می شود تا تست سیستم و مارکت تست و غول آنها که تست تجمیع سازی یا Integration Test است. تست تجمیع سازی را هم بدین خاطر در آخرین مرحله بیان کرده ام تا برایتان مشخص شود که ، هر قسمت سیستم شما در ابتدا باید درست و حسابی کار کند تا بتواند در مرحله بعد با سایر قسمت های سیستم هم درست و حسابی کار کند.
اگر این مراحل انجام نشود :
مثل اینست که من فلسفه نمی دانم و کتابی در مورد اش نخوانده ام و می خواهم برای یک استاد فلسفه با زبانی آلمانی ، از فلسفه حرف بزنم. 
خب کسی نیست به من بگوید که الاغ فعلاً برو زبان آلمانی یاد بگیر. بعدش کمی با کتاب های ترجمه شده به زبان خودت ، فلسفه را تمرین کن. اونوقت تازه می فهمی که فلسفه یعنی چی؟
خب بگذریم از فلسفه و الاغ بودن.
اگر در هر مرحله که کار را انجام می دهی ، تست های مربوط به همان مرحله ، بازهم تاکید می کنم ، همان مرحله نه مراحل دیگر ، را اجرا کنی ، در همان ابتدا مشخص می شود که چه گندی زده ای . که اگر آنها را تعمیر و تنظیم نکنی ، در آینده ممکن است گند هایی را بزنی که دیگر دست خودت نباشد.
یا ممکن است که خودت را کور و کر کنی و چشم ات را ببندی و با خودت بگویی " گور بابای مشتری " اینها را که نمی فهمد. اما در آینده نزدیک این مشتری است که همین اصطلاح زیبا را با تعویض واژه مهندس ، تحویل خودت و خانواده محترم ات میدهد.
تست را با ورودی دادن انجام نمی دهند ، بلکه در بعضی مواقع mock object ها را باید بدهی. آنهم نه یکی و دو تا. بلکه چند برابر اندازه سیستم. برای مثال اگر می خواهی یک نرم افزار برای یک فروشگاه بنویسی و از مدیر آن فروشگاه تعداد مشتریانش را بپرسی و مدیر به تو بگوید 500 تا 1000 عدد مشتری، تو مهندس نرم افزار ، باید با 5000 الی 20000 هزار عدد این کار تست را انجام دهی. چون اگر اینکار را انجام ندهی ، بهتر است که بروی و در دبیرستان و سال دوم اش ، کمی آمار بخوانی تا با نرخ رشد آشنا شوی. بعدش شاید متوجه شوی که اینکار ها برای چیست و به چه دردی می خورد؟
حال نرخ رشد نرم افزار به کنار. بخوره توی سر منِ خر.
چون اگر با واژه نرم افزار آشنا باشی ، با غیر قابل لمس بودن یا intangible بودن نرم افزار در همه زمینه های مربوطه به آن، مطلع و آشنا هستی.
پس برادر یا خواهر عزیزی که خودت را مهندس می نامی ، سعی کن که کارهایت را هم مهندسی کنی. سعی کن قواعد را بفهمی. سعی کن سیستم را درک کنی. سعی کن که آینده سیستم را هم درک کنی و بر اساس آینده سیستم ، نرم افزار ات را بسازی و تکمیل کنی.
ادامه دارد...
