9.3 שגיאות וטסטים הרצאה
טיפול בשגיאות¶
- איך כותבים קוד נכון שמטפל בשגיאות? כמה טיפים:
- השתמש בשגיאות, לא בהחזרת סטטוסים, דיברנו על זה בהרצאה הקודמת, זכרו שכאשר אנחנו כותבים פונקציות שעלולה להרים שגיאה, אנחנו צריכים לכתוב פונקציה שצריכה לטפל בשגיאה.
- אין סיבה לכתוב try מבלי לכתוב except
- כשאנחנו כותבים שגיאה משלנו, תמיד תחזירו כמה שיותר מידע עם השיגאה, כדי שמתכנת אחר יוכל להבין את השגיאה מבלי לקרוא את הקוד.
- צור שגיאות בעצמך אם צריך, עדיף שהשגיאות יהיו כמה שיותר מתאימות לסיטואציה
יש פונקציות שזורקות שגיאות ופונקציות שמטפלות בשגיאות: זכרו, יש שני סוגים של פונקציות, פונקציות שזורקות שגיאות, ופונקציות שמטפלות בשגיאות. אם אנחנו כותבים פונקציה שקורת לפונקציה שעלולה לזרוק שגיאה הפונקציה שאנחנו כותבים צריכה לטפל בשגיאה.
זכרו: שום שגיאה לא אמורה להגיע בסוף למשתמש של התוכנה שלנו, בגלל זה צריכות להיות פונקציות שמטרתן לתפוס את ההשגיאות, דוגמה:
def safe_login(username, password):
try:
login(username, password)
except
log.info("Password or username not meet!")
def login(username, password):
if check_password(username, password):
session.start(username, password)
else:
raise AuthenticationException(message="Password or username not meet")
טסטים¶
- תכנות מונחה טסטים - זה טכניקה שמאפשרת לנו לכתוב קוד עם פחות באגים, יש לשיטה הזו 3 חוקים:
- כתוב יוניט-טסט לפונקציה לפני שאתה כותב את הפונקציה.
- כתוב את הפונקציה כדי שתעבור את הטסט שכתבת
- הוסף את הפונקציה והטסט שכתבת לפרויקט, ותבדוק שהפרויקט עדיין עובר טסטים ומצליח לרוץ.
-
עקרון זה חשוב מאוד כדי לכתוב קוד שמגיע לפרודקשן עם כמה שפחות באגים, כי אם אנחנו כותבים את טסט לפני שכתבנו את הפונקציה, יותר ברור לנו מה הפונקציה אמורה לעשות, ומה להחזיר, וגם כך אנחנו מוודאים שהפונקציה עוברת את הטסט שכתבנו לפניכן ולא נתעצל לכתוב טסטים. אנשים נוטים לדחוף את הקוד שלהם לפרודקשן מבלי לכתוב מספיק טסטים
-
איך נכתוב טסטים נכון?
- טסטים, בדיוק כמו פונקציות אמורות לבדוק משהו אחד.
- לכל טסט צריך להיות assert אחד, אם זה לא המצב נראה שהטסט בודק יותר מדבר אחד
- כל טסט צריך לעקוב אחרי חוקי FIRST
- מהיר: F - הטסטים צריכים לרוץ מהר, תדאג שהטסטים יהיו קטנים ושישתמשו במוקים כדי לרוץ מהר ולא לחכות לדברים מיותרים.
- עצמאי: I - טסטים לא אמורים להיות תלויים אחד בשני.
- חזרתי: R - טסטים צריכים להיות מספיק כלליים כדי שיעבדו בכל סוג של סביבה, (כל מחשב) כך שלא יהיה שום תירוץ לאם הם נכשלים.
- פשוט: S - טסטים צריכים להיות בולייאנים, או שהם עוברים או שלא. המנעו מלכתוב טסטים מסובכים שקשה להבין האם הם עברו או לא
- מתוזמן: T - כתבו את הטסטים לפני שאתם כותבים את הקוד, כך תכתבו קוד שהוא יותר טסטאבילי.
עוד קונבציות חשובות¶
- השתמשו בtype-hinting - אומנם לא חייב type-hinting בפייתון, אבל זה חובה כדי לכתוב קוד נקי.
- כתבו דוק-סטרינג - הוסיפו תיעוד לפונקציות, מודולים, מחלקות ולהכל.
המנעו לחלוטין ממספרי קסם. - מספרי קסם הם מספרים שנמצאים בקוד אין להם שום משמעות:
- קוד לא טוב
- קוד טוב
בפייתון כתבו קוד פייתוני:
- השתמשו בפונקציות מובנות, ובמודולים - אל תממשו דברים בעצמכם סתם.
- השתמשו בפיצ'רים של פייתון כמו ליסט קומפרהנשן, דקורטורים וכו
- השתמשו בפורמט סטרינג! אל תחברו מחרוזות: "not" + x + "clean"