---
**برنامه نویس خفن میم ح ح:**
سلام. کسی تجربه تولید تست خودکار در لایه‌های زیر رو برای سیستم‌های نرم‌افزاری صنعتی داره؟
1. Unit Test
2. Integration Test
3. System Test
با ابزارهای AI مخصوصاً.
بدون اون هم اوکیه.
اگه بشه هزینه نوشتن تست رو با اتومیشن کم کرد و در عین حال به کاورج بالا رسید، انقلابی میشه.
ابزار و مقاله برای این موضوع زیاده. ولی تا حالا کسی رو ندیدم به صورت عملیاتی ازشون استفاده کنه.
**معمار نرم افزار با تجربه ر الف:**
نه واقعاً. ما تجربه این داستان رو داریم، ولی عموماً از نوشتن دستی تست‌ها و نوشتن اتومات کدها تجربه بهتری گرفتیم.
بعدش هم، اون تستی که به عنوان afterthought دادی یه LLM برات بزنه، فقط به درد بالا بردن کاوریج می‌خوره، که اونم به خودی خود ارزش چندانی نداره. اون فرایند ذهنی‌ای که موقع نوشتن تست طی میشه و به واسطه اون معماری کد اصلاح میشه تا تست‌پذیری (توسعه‌پذیری) بیشتر بشه، به مراتب ارزش بیشتری داره از اون تستی که فقط هست که رفتار کد رو داکیومنت کنه.
**مدیر محصول میم میم:**
چه زیبا گفتی آقا رضا!
**برنامه نویس خفن میم ح ح:**
چرا ارزش ندارن؟
**مدیر محصول میم میم:**
اون تست دستی ارزشش بیشتره.
**برنامه نویس خفن میم ح ح:**
اونو که متوجه هستم. ولی اینکه تست‌های AI ارزش نداره رو متوجه نیستم.
**مدیر محصول میم میم:**
چون در فرایند تست‌نویسی شما ریفکتور می‌کنی. حتی حالاتی که در ابتدا به ذهنت نمی‌رسید رو معمولاً توی تست‌نویسی بهش برخورد می‌کنی. اما وقتی که آخر کار میای میدی یکی تست تولید کنه، صرفاً جنبه‌ی کاورج کدهای فعلی رو داره.
اگه نیت و هدف اصلیت این هست که برای کدهای فعلی تست داشته باشی که بعداً اگه خواستی تغییری بدی، فانکشنالیتی کدت تغییر نکنه، خوبه.
**برنامه نویس خفن میم ح ح:**
شما برای ریفکتور تست می‌نویسی، نه تست بنویسی که ریفکتور کنی. تست فقط یکی از ابزارهای ریفکتور امنه. ممکنه ریفکتوری در کار نباشه اصلاً.
**مهندس رضا:**
نه واقعاً.
ما تجربه این داستان رو داریم، ولی عموماً از نوشتن دستی تست‌ها و نوشتن اتومات کدها تجربه بهتری گرفتیم.
**مهندس رضا:**
بعدش هم، اون تستی که به عنوان afterthought دادی یهLLM برات بزنه، فقط به درد بالا بردن کاوریج می‌خوره، که اونم به خودی خود ارزش چندانی نداره. اون فرایند ذهنی‌ای که موقع نوشتن تست طی میشه و به واسطه اون معماری کد اصلاح میشه تا تست‌پذیری (توسعه‌پذیری) بیشتر بشه، به مراتب ارزش بیشتری داره از اون تستی که فقط هست که رفتار کد رو داکیومنت کنه.
**مهندس مبین:**
چه زیبا گفتی آقا رضا!
**مهندس حیدری:**
چرا ارزش ندارن؟
**مهندس مبین:**
اون تست دستی ارزشش بیشتره.
**مهندس حیدری:**
اونو که متوجه هستم. ولی اینکه تست‌های AI ارزش نداره رو متوجه نیستم.
**مهندس مبین:**
چون در فرایند تست‌نویسی شما ریفکتور می‌کنی. حتی حالاتی که در ابتدا به ذهنت نمی‌رسید رو معمولاً توی تست‌نویسی بهش برخورد می‌کنی. اما وقتی که آخر کار میای میدی یکی تست تولید کنه، صرفاً جنبه‌ی کاورج کدهای فعلی رو داره.
**مهندس مبین:**
اگه نیت و هدف اصلیت این هست که برای کدهای فعلی تست داشته باشی که بعداً اگه خواستی تغییری بدی، فانکشنالیتی کدت تغییر نکنه، خوبه.
**مهندس حیدری:**
شما برای ریفکتور تست می‌نویسی، نه تست بنویسی که ریفکتور کنی. تست فقط یکی از ابزارهای ریفکتور امنه. ممکنه ریفکتوری در کار نباشه اصلاً.
**مهندس مبین:**
رضا به فلسفه‌ی TDD اعتقاد داره و ارزش‌گذاریش روی فلسفه‌ی اون هست از تست‌نویسی.
**مهندس حیدری:**
اونم یه متدلوژی تست‌نویسیه صرفاً.
که مجزا ارزش خودش رو داره.
**مهندس مبین:**
من میام امروز یه کدی می‌نویسم. برای اینکه دو روز دیگه به هر دلیلی یکی قرار شد بیاد تغییری بده، من نگران اینم که عملکردی تغییر کنه، و از شانس اونی که می‌خواد تغییر بده، بنا نداره که قبل کارش تست بنویسه.
سر همین الان میام یه سری تست می‌زارم براش.
**محسن:**
بنظرم یکمی هوش مصنوعی و تست خودکار رو دست کم گرفتید. تست خودکار از روی کد لزوماً جنریت نمیشه. اونجا داستان می‌تونه عوض بشه. حتی میشه از هوش تویTDD استفاده کرد. یه نکته دیگه هم اینه که AI Assisted رو مد نظر قرار بدید. اینجا دیگه AI فکر شما رو پیاده می‌کنه. فقط سرعت میده به کار.
**مهندس مبین:**
پسندیدم.
**مهندس رضا:**
خب اگه من قراره یه طومار بنویسم براش که چجوری برام تست بنویسه، چرا خود اون تسته رو ننویسم؟ این ادعا که با بهره بردن از این ابزار کار من سرعت می‌گیره از کجا میاد؟
ببین یه داستانی هست که می‌گه بیا و مواردی مثل امنیت، پرفورمنس و توسعه‌پذیری روShift Left بده. داستان اینه که شما هرچه زودتر به این موضوعات فکر کنی، احتمالاً پیاده‌سازیت معماری بهتری داره و در ادامه هزینه‌هات پایین‌تره. حالا سر بحث تست، من مثلاً دارم یه کد محاسباتی می‌زنم که برنچ‌های (if else) زیادی داره. اگر من اول برم کدش رو بزنم، برمیدارم همه این برنچا رو یه جا می‌زنم چون می‌خوام زودتر ببینم که کار می‌کنه و اون تصویر ذهنیم پیاده‌سازی بشه. بعد که میام تستش کنم، می‌بینم برای چندتا شرط تو در تو خدا تا تست باید بنویسم که حالتاش پوشش داده بشه. حالا برای اینکه این رو سختیش رو کم کنم (که اونLLM هم از این کارا نمی‌کنه)، میام یه تعداد کلاس میکشم بیرون و می‌برم جدا تست می‌کنم که حالتایی که باید تست کنم کم بشن. خب این وسط یه پِرتی ای وجود داره که همون زدن کد و تست و بعد جراحی کردنشون برای بیرون کشیدن منطق‌ها هست. اما اگه من اول تست رو مد نظر قرار می‌دادم، خیلی زودتر می‌فهمیدم که آقا حالتام داره زیاد میشه و تستشون اینجوری سخته، بیا اول اگه می‌تونی یه سری اینترفیس تعریف کن بگو من فلان انتظار رو ازش دارم و الان عملکردش دغدغه من نیست و همینجور برو جلو. تهش می‌بینی که کد خوش‌تعریف‌تری داری و کاوریجش هم بالاس. حالا LLM کجای قضیه میشینه؟ اول کهLLM نیاز به نظارت داره و بهش اعتماد کردن ریسک غیر منطقیه (بارها ثابت شده سوتی میده). دوم هم اینکه تست اون چیزیه که قراره عملکرد کد رو تضمین کنه و حکم نمک توی بحث "هرچه بگندد، نمکش می‌زنیم" رو داره. حالا شما بیا و این رو بده دستLLM، اینگونه رسماً داری نمک گندیده می‌زنی. پس منطقی‌تره که من تست رو بنویسم و به اون LLM بگم پیاده‌سازی کن. اینجوری اون LLM عه تهش باید حالتای تو رو پاس کنه که تضمین کنه آقا، این کد همون کاری که تو می‌خوای رو می‌کنه ولاغیر.
**مهندس رضا:**
به طور خلاصه بخوام بگم، داستان اینه که LLM سوتی میده. اگه بدم تست‌هام رو بنویسه و سوتی بده، هم تستم و هم کدم می‌تونن خراب بشن. ولی اگه تست‌هام رو بنویسم و بدم کدم رو بزنه، اگه سوتی بده تستم پاس نمیشه و تهش مطمئن هستم که سوتی‌های اون به کار من گند نمی‌زنه.
**محسن:**
شرکت ولوو سیستم مالتی‌پلکس رو به صورت بکوارد کامپتیبل پیاده می‌کنه. حجم داکیومنت ۵۰۰۰ صفحه. مشکل آتیش گرفتن خودروی ولوو علی‌رغم وجود واحد تست بسیار درست‌حسابی واقعاً هیولا.
راه نجات تولید تست کیس اتومات به همراه تولید سمنتیک همه اون ۵۰۰۰ صفحه. نوع خطایی که کشف شد بایت کد فرمان‌ها روی کاغذ دقیق بودن، اما تست اتومات پیدا کرد که این کدها در حضور نویز می‌تونن باهم قاطی بشن. گاهی یه باگ حیثیت شرکت و میلیون‌ها دلار رو نابود می‌کنه. فلسفه تست اینه.
**محسن:**
ادعا خیلی سادس. شما مجبور نیستی تست رو با هوش مصنوعی یا حتیIDE بنویسی. هرجا فکر می‌کنی کمکت می‌کنه استفاده کن. مقاله می‌گه اینجا فلان کارو کردیم دیدیم خوبه. نمی‌گه دنیا باید اینکارو کنه.
**محسن:**
مثلاً تو چک خودکار تو اصلاً تست نمی‌نویسی. تو محیط و شرایط تست رو توصیف می‌کنی. مدل تمام حالات ممکن رو به کمک کلاس هم‌ارزی تست می‌کنه. این حتی هوشمند هم نیست. الگوریتم‌های ۱۹۹۰-۲۰۰۰ هست.
**مهندس رضا:**
اینو یکم بیشتر توضیح میدی؟
**مهندس رضا:**
اصلاً تست اتوماتی که می‌گیم چیه؟
**محسن:**
مساله‌های ددلاک مثل غذا خوردن فیلسوفا یادته؟ اونجا یه الگوریتم پیاده می‌کنی ادعا اینه که هیچ starvationای پیش نخواهد اومد. این و بقیشو سرچ کن، طولانیه. کلیتش این شکلیه که چهارتا ادم داریم که قاشق چنگالشون مشترکه. سیستم به ما وضعیت هر ادمی رو در لحظه میده: گرسنه، سیر، در حال غذا خوردن. شرط ما اینه هیچ ادمی بیش از مثلاً ۱۰۰ اکشن سیستم گرسنه نمیمونه. حالا تست از اینجا خودکاره. فقط فانکشن‌ها رو می‌دیم بهش. روابط با خودشه. تهش یا شرط ما ارضا میشه یا کانتر اگزمپل تولید میشه.
**محسن:**
این مساله، مساله ددلاک و استارویشن پراسس تو سیستم عامل یا حتی اپ سین رو مدل کرده.
---
**نتیجه‌گیری:**
این گفت‌وگو نشان می‌دهد که استفاده از هوش مصنوعی در تست‌نویسی خودکار می‌تواند مفید باشد، اما چالش‌ها و محدودیت‌های خودش رو هم داره. مهم‌ترین نکته اینه که تست‌نویسی نه تنها برای پوشش کد، بلکه برای بهبود معماری و توسعه‌پذیری نرم‌افزار حیاتی‌ست. استفاده از ابزارهای AI می‌تونه سرعت کار رو افزایش بده، اما نباید جایگزین تفکر و تحلیل توسعه‌دهنده بشه.
**سوال شما:**
شما چه تجربه‌ای در این زمینه دارید؟ به نظرتون AI چقدر می‌تونه در تست‌نویسی مؤثر باشه؟ 🤔:**
رضا به فلسفه‌ی TDD اعتقاد داره و ارزش‌گذاریش روی فلسفه‌ی اون هست از تست‌نویسی.
