🐊 تست یعنی چی؟!

🐊 تست یعنی چی؟!


شاید با دیدن این تیتر بگید: «چه سوال بدیهی و ساده‌ای؟! چرا داره بدیهیات رو توضیح می‌ده!»


ولی برای برخی که با تست آشنایی کافی ندارن، مفاهیم پایه ولی مهم، تاثیر پررنگی در ادامه راه وشیوه فکر کردن در مورد تست و طراحی صحیحش داره.


تست، یعنی «در صورت وقوع الف، حتما نتیجه‌ی ب باید حاصل بشه؛ نه یک کلمه بیشتر نه یک کلمه کمتر»


- این‌که کد رو اجرا کنیم و خطا نده؛ تست نیست.


- اینکه دیتا بفرستیم سمت دیتابیس و ذخیره بشه، باز هم تست نیست!

بیاید همینو تدقیق کنیم:

۱: من جدول دانش‌آموزان رو در دیتابیس دارم که ۱۰ عدد رکورد دارد.

۲: رکوردی با مقادیر [امین، مصباحی، ۱۰ ساله] درج می‌کنم.

۳: چک می‌کنم تا تعداد رکوردها حتما برابر با ۱۱ باشه، تعداد دانش‌آموزانی که امین مصباحی و ۱۰ ساله باشن حتما برابر با ۱ باشد.


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


تست نوشتن الزاما به معنی TDD یا Test Driven Development نیست! حالا بگیم TDD چیه تا بگیم چرا الزامی نیست.

وقتی قبل از اینکه خود کد نوشته بشه، اول تستش رو بنویسیم و بعد مراحلی رو طی کنیم، میشه TDD. اولین سوال: وقتی کد رو ننوشتم، تست چی؟ کشک چی؟ آها. یه مثال ساده، قراره تا متد CreateUser رو بنویسیم:

۱: می‌ریم توی تست‌دونی، یه تست می‌نویسیم به اسم CreateUser_ShouldCreateUser_WhenDataIsValid.

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

۳: حالا وقتی تست رو اجرا می‌کنیم، چون کد رو ننوشته‌ایم، تست شکست می‌خوره؛ این دقیقاً نشونه اینه که باید برگردیم و کد رو بنویسیم.


اینجاست که مفهوم TDD شکل می‌گیره: یعنی اول شکست، بعد کد رو می‌نویسیم تا اون تست شکست‌خورده پاس بشه، بعد توی گام سوم بهینه‌اش می‌کنیم. هدف از نوشتن تست قبل از کد اینه که به ما کمک کنه دقیقاً مشخص کنیم «انتظارمون» از عملکرد متد چیه. وقتی تست پاس بشه، دیگه مطمئنیم که کدمون دقیقاً همون رفتاری رو داره که می‌خوایم.


حالا برگردیم سر داستان اول، مگه ما همیشه از زمین خالی شروع می‌کنیم که اول تستش رو بنویسیم بعد کد رو؟ اصلا مگه TDD روش مناسب همه تیم‌هاست؟

جواب: TDD خیلی خوبه، ولی الزامی نیست، برای همه تیم‌ها هم شدنی نیست. تست نوشتن به معنی الزما TDD بودن نیست. یعنی شما می‌تونید اول کد نوشته باشید بعد تستش رو بنویسید، یا برای کدهایی که در گذشته نوشته شده تست بنویسید، حتی نه الزاما برای همه کدها، بلکه برای جاهایی که «مهم‌ و مستعد رفتار غیر مطلوب» است (الزاما نباید خطا یا Exception/Error رخ بده، بلگه «هر» رفتاری به جز «اونچه که ما انتظار داریم» یعنی مستعد رفتار نامطلوب؛ مثلا محاسبه فاکتور با ارقام اشتباه، Error نیست، بلکه رفتاری است که مطلوب ما نیست)


در پست بعد اصطلاحات تست رو توضیح می‌دم و بعدش می‌ریم سراغ کد.

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


* ایمان عزیز محبت داشت و پیام داد تا توی تولید محتوای بخش تست مشارکت کنه، و من هم خیلی خوشحال شدم که بشه با مشارکت ایمان، موضوع تست رو بهتر پیش ببریم. لذا به گزینه‌هایی مثل جلسه ویدیویی مشترک، نوشتار پست‌های مربوط به تست و شاید منتورشیپ ۳ تا ۵ نفر به مدت یک ماه تا رسیدن به مهارت نسبی روی unit test و end-to-end test و... فکر کنیم 🥳



💬 مثل همیشه: نظر، پیشنهاد، سوال...

در ضمن توی کامنت بگید چه زبانی براتون کاربردی‌تره برای مثال‌های تست؟ (#C یا پایتون یا گو؟)