مسئله‌ای که باید حل می‌کردم
وقتی یک خطای حکم فقط در انتهای دست رخ می‌دهد، بازی‌کردن دوبارهٔ همهٔ مراحل روش کندی برای فهمیدن آن هست. من به مشاهده و ساخت وضعیت مشخص نیاز داشتم.
پیاده‌سازی در نسخهٔ فعلی
HokmDebugQaTools.BuildSnapshot وضعیت بازیکنان، دست، دور و مسابقه را جمع می‌کنه. ForceHakemForNewHand، ForceTrump و SetTrickScoreForDebug اجازه می‌دهند یک سناریوی هدف را بسازم.
تصمیم و هزینهٔ طراحی
ساخت snapshot از نمایش نهایی جداست و FormatSnapshot متن قابل خواندن می‌دهد. محدودیت‌های عددی در تغییر امتیاز بررسی می‌شوند تا ابزار اشکال‌زدایی هم ورودی کاملاً بی‌معنی نسازد.
مرزهای فعلی
ابزار debug تأیید محصول نیست. من از موجودبودن runtime tester یا گزارش مستندات ادعای اجرای موفق روی این خروجی نمی‌کنم؛ محیط Unity و صحنهٔ کامل برای آن لازم هست.
ساختن وضعیت نزدیک پایان برای بررسی
فرض کن ایراد فقط وقتی امتیاز دورها شش به شش هست دیده می‌شود. SetTrickScoreForDebug می‌تواند وضعیت دست را بازنشانی کنه، حکم را بگذارد و با AddTrickPoint شمارش دو تیم را به مقدار درخواستی برساند. این کار جای بازی کردن همهٔ کارت‌ها را برای یک بررسی هدفمند می‌گیرد، اما تاریخچهٔ واقعی دورهای قبلی را تولید نمی‌کنه. بنابراین سناریوی ساخته‌شده برای پرسیدن یک سؤال محدود مناسب هست: مثلاً رفتار پایان دست با این شمارش چیست؟ نباید آن را مدرک یک مسابقهٔ طبیعی و کامل با همهٔ رویدادهای قبلی معرفی کرد.
BuildSnapshot اطلاعات دست‌های بازیکنان، نوع کنترلر، حاکم، دیلر، صندلی فعال، رهبر دور، خال‌ها و امتیازهای دو چرخه را کنار هم می‌گذارد. برای assignment فاقد بازیکن از آن عبور می‌کنه و برای برخی stateهای null مقادیر پیش‌فرض مثل Seat0 یا صفر می‌گذارد. این انتخاب کمک می‌کنه گزارش ناقص هم ساخته بشه، ولی خواننده باید پیش‌فرض را با وضعیت تأییدشده اشتباه نگیرد. گزارش صفر الزاماً معنای شروع واقعی مسابقه را نداره. FormatSnapshot همین داده را خوانا می‌کنه و تفاوت امتیاز دور با امتیاز مسابقه را با برچسب‌های جدا نشان می‌دهد.
ابزارهای تغییر وضعیت محدودیت عددی دارن: امتیاز منفی و امتیاز بالاتر از آستانه رد می‌شوند. با این حال، بررسی این حدود تمام سازگاری‌های بین تعداد کارت‌ها، دور فعلی و جریان انیمیشن را اثبات نمی‌کنه. ForceTrump و ForceHakemForNewHand نیز استثناهای عملیات وضعیت را به نتیجهٔ Failure تبدیل می‌کنند تا بررسی‌کننده پاسخ مشخص بگیرد. در این مطالعه فقط قابلیت‌های کد و مستند را می‌توانم شرح دهم؛ اجرای موفق runtime tester یا عبور کامل QA نیازمند محیط Unity و صحنهٔ کامل هست. وجود ابزار عیب‌یابی را به عنوان گزارش تست انجام‌شده منتشر نمی‌کنم.
چیزی که از این مرحله یاد گرفتم
این ابزارها کمک می‌کنند دربارهٔ وضعیت واقعی سؤال دقیق بپرسم. نتیجه برای من کمتر حدس‌زدن بود: ابتدا بدانم کدوم مرحله و کدوم داده غلط هست، سپس سراغ ظاهر یا قانون بروم.
مثال عملی عیب‌یابی وضعیت حکم
اگر بخواهی عیب‌یابی وضعیت حکم را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. پیش از یک انتخاب اشتباه، کارت‌های آشکار، دست ربات، حکم و صاحب نوبت را ثبت کن. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
ثبت صرف پیام خطا بدون وضعیت، بازسازی مسئله را به حدس و تکرار تصادفی وابسته می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. برای گزارش عمومی، دست پنهان و اطلاعات شناسایی بازیکن را از خروجی حذف کن. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
با همان تصویر وضعیت، نتیجهٔ انتخاب باید دوباره بازتولید شود. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | پیش از یک انتخاب اشتباه، کارت‌های آشکار، دست ربات، حکم و صاحب نوبت را ثبت کن. |
| ریسک اصلی | ثبت صرف پیام خطا بدون وضعیت، بازسازی مسئله را به حدس و تکرار تصادفی وابسته می‌کند. |
| روش بررسی | با همان تصویر وضعیت، نتیجهٔ انتخاب باید دوباره بازتولید شود. |
| مرز نتیجه‌گیری | برای گزارش عمومی، دست پنهان و اطلاعات شناسایی بازیکن را از خروجی حذف کن. |
پرسش‌های کاربردی دربارهٔ عیب‌یابی وضعیت حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: پیش از یک انتخاب اشتباه، کارت‌های آشکار، دست ربات، حکم و صاحب نوبت را ثبت کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. با همان تصویر وضعیت، نتیجهٔ انتخاب باید دوباره بازتولید شود. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. برای گزارش عمومی، دست پنهان و اطلاعات شناسایی بازیکن را از خروجی حذف کن.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
