Quest Ladder
TeachFORGE.ai
Quest Ladder / הרצת קוד
שאלות הרצת קוד
קבעו את השפה, כתבו את מקרי הבדיקה, ותנו לקוד להישקל לפי אם הוא עובד.
קוד או שהוא רץ או שלא. זו מתת נדירה בעולם הבדיקה.
מה זה
הלומד כותב קוד; הקוד מורץ מול מקרי בדיקה; התוצאה קובעת את הניקוד. שתי הגדרות מעצבות את זה בהגדרות נוספות: שפה, וגם מקרי בדיקה מ-1 עד 6, כברירת מחדל 2.
זה הפורמט היחיד שבו תשובה שגויה יכולה להיות שגויה בדרך שהיא באמת אינפורמטיבית בלי שתכתבו דבר — הכישלון עצמו מספר ללומד איזה מקרה הוא לא טיפל בו.
כתיבת מקרי הבדיקה
שני מקרים הם ברירת המחדל והמספר השימושי המינימלי: אחד שכל ניסיון סביר עובר אותו, ואחד שמפריד פתרון אמיתי מניחוש. שישה הם התקרה, והתקרה נמצאת שם מסיבה — לומד שנכשל בחמישה מתוך שישה לומד פחות מלומד שנכשל במקרה הבודד שחשוב.
- הפכו את המקרה הראשון למובן מאליו, כך שלומד שבכיוון הנכון מקבל משוב שהוא באמת בכיוון הנכון.
- הפכו מקרה אחד לגבולי: קלט ריק, אפס, מספר שלילי, קצה הטווח.
- הימנעו ממקרים שנבדלים רק בגודל. בדיקה שהיא אותה צורה עם מספרים גדולים יותר בודקת סבלנות, לא הבנה.
התעלם מרווחים בהשוואת הפלט בשלב התשובה הנכונה היא כמעט תמיד ההגדרה הנכונה. בלעדיה, שורה חדשה בסוף הפלט מכשילה תוכנית נכונה, ואין ללומד דרך לדעת למה.
ניקוד וזכות חלקית
כל מקרה בדיקה הוא משבצת עם ניקוד משלה, כך ש- מצב ניקוד מוגדר ל משוקלל נותן זכות עבור המקרים שעוברים. לומד שהפתרון שלו מטפל במסלול הרגיל אך לא בקלט הריק כתב משהו ששווה את רוב הניקוד.
להכול או לא כלום יש מקום — כשהשאלה מציינת במפורש לגרום לכל הבדיקות לעבור — אבל כברירת מחדל היא זורקת לפח את הסיגנל השימושי ביותר שהפורמט מייצר.
מה זה לא עושה
מקרי בדיקה בודקים התנהגות, לא איכות. קוד שעובר כל בדיקה יכול עדיין להיות לא קריא, ריבועי במקום שצריך להיות לינארי, או טבלה מקודדת קשה של התשובות הצפויות.
אם סטייל או יעילות הם חלק ממה שאתם מלמדים, שלבו את זה עם שאלה כתובה שמבקשת מהלומד להסביר את הגישה שלו, ובדקו אותה ב- תור הבדיקה. הבדיקות מטפלות בנכונות; אתם מטפלים בשאר.