מהי בדיקה

כשכותבים תוכנה, אפשר לוודא שהיא פועלת כראוי באמצעות בדיקות. ניתן להגדיר את הבדיקה באופן כללי כתהליך של הרצת תוכנה במערכות ספציפיות כדי להבטיח שהוא יפעל כמו שצריך.

בדיקות מוצלחות יכולות לעזור לכם להרגיש בטוחים שכשאתם מוסיפים קוד, תכונות או אפילו לשדרג את יחסי התלות, התוכנה שכבר כתבתם ימשיכו לפעול באופן הרצוי. הבדיקה יכולה גם לעזור בהגנה על מפני תרחישים בלתי צפויים או קלט לא צפוי.

דוגמאות להתנהגות באינטרנט שכדאי לבדוק:

• וידוא שהתכונה של אתר פועלת כראוי כשלוחצים על לחצן.
• בדיקה שפונקציה מורכבת מניבה את התוצאות הנכונות.
• השלמת פעולה שמחייבת התחברות של משתמש.
• בדיקה שטופס מדווח על שגיאה בצורה תקינה כשמזינים נתונים שגויים.
• אימות שאפליקציית אינטרנט מורכבת תמשיך לפעול כשיש למשתמש הרבה מאוד רוחב פס נמוך או עובר למצב אופליין.

בדיקה אוטומטית לעומת בדיקה ידנית

אפשר לבדוק את התוכנה בשתי דרכים כלליות: בדיקה אוטומטית ובדיקה ידנית בדיקה.

בדיקה ידנית כוללת בני אדם שמפעילים תוכנה באופן ישיר, כמו טעינת בדפדפן שלהם, ולאשר שהוא פועל כצפוי. ידניות קל ליצור או להגדיר בדיקות? לדוגמה, האם האתר שלכם יכול להיטען? האם אפשר לבצע את הפעולות האלה? - אבל כל ניסיון של המרה עולה כמות עצומה הזמן של בני אדם. בעוד שבני אדם הם יצירתיים מאוד, זה יכול לאפשר סוג של בדיקה שנקראות בדיקות חקירה, אנחנו עדיין עלולים לזהות כשלים או לזהות כשלים חוסר עקביות, במיוחד כאשר מבצעים את אותה משימה מספר רב של פעמים.

בדיקה אוטומטית היא כל תהליך שמאפשר לקודד ולהפעיל בדיקות שוב ושוב במחשב, כדי לאשר את ההתנהגות של התוכנה במכשיר שלכם בלי אדם מסוים יכול לבצע פעולות חוזרות, כמו הגדרה או בדיקת תוצאות. חשוב לציין שאחרי הגדרת הבדיקה האוטומטית, אפשר להפעיל אותה לעיתים קרובות. זו עדיין הגדרה רחבה מאוד, וכדאי לציין ומבחנים שונים. רוב הקורס עוסק את עצמה באמצעות בדיקה אוטומטית.

אכן, אין אפשרות לבצע בדיקות ידניות, אבל גם כשהבדיקות האוטומטיות הופכות לבלתי אמינות מדי, וההיקף שלהן רחב, או קשה לכתוב.

העקרונות הבסיסיים באמצעות דוגמה

עבורנו, כמפתחי אתרים שכותבים JavaScript או שפות קשורות, הבדיקה האוטומטית יכולה להיות סקריפט דומה, שמריצים כל יום. דרך Node, או על ידי טעינתו בדפדפן:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

זוהי דוגמה פשוטה שמספקת את התובנות הבאות:

• זהו בדיקה כי הוא מריץ תוכנה מסוימת (פיבונאצ'י) ). פועלת בדרך הרצויה, על ידי בדיקת התוצאות שלה הערכים הצפויים. אם ההתנהגות לא נכונה, זה גורם לשגיאה, JavaScript מבטאת על ידי הטלת Error.

• גם אם הרצתם את הסקריפט באופן ידני בטרמינל או הדפדפן הזה הוא עדיין בדיקה אוטומטית כי אפשר להריץ אותו בלי שתצטרכו לבצע פעולה כלשהי בנפרד. הדף הבא, כאשר בדיקות פועלות, תקבלו הסבר נוסף.

• למרות שהבדיקה לא משתמשת בספריות כלשהן, מדובר ב-JavaScript שיכול להריץ בכל מקום — זו עדיין בדיקה. יש הרבה כלים שיכולים לעזור לך לכתוב מבחנים, כולל מבחנים נוספים שיעסוקו בהמשך הקורס, אבל הם עדיין פועלים על העקרון הבסיסי של יצירת שגיאה משהו משתבש.

בדיקה של ספריות בפועל

רוב הספריות או מסגרות הבדיקה המובנות מספקות שני עקרונות בסיסיים קל יותר לכתוב בדיקות: טענות נכוֹנוּת ודרך להגדיר בדיקות עצמאיות. נושא זה יידון בהרחבה בחלק הבא, טענות פרימיטיביים אחרים. אבל ברמה גבוהה, חשוב לזכור שכמעט כל הבדיקות שרואים או כותבים בסופו של דבר באמצעות פרימיטיבים כאלה.

טענות נכונות הן דרך לשלב בדיקה של תוצאה וגרימת שגיאה אם משהו משתבש. לדוגמה, אפשר להפוך את הבדיקה הקודמת לתמציתית יותר. עם assert:

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

אפשר לשפר את הבדיקה הזו עוד יותר על ידי הגדרת בדיקות עצמאיות, אם רוצים המקובצות בהסוויטות. בחבילה הבאה בודקים את פיבונאצ'י באופן עצמאי והפונקציה Catalan:

import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

בהקשר הזה של בדיקות תוכנה, המונח בדיקה כשם עצם מתייחס למקרה בדיקה: תרחיש יחיד, בלתי תלוי שניתן להתייחס אליו, כגון "הקשר בין רצפים' בדוגמה הקודמת.

אפשר להשתמש בבדיקות עם שם ייחודי לביצוע המשימות הבאות, בין היתר:

• קביעת איך הבדיקה מצליחה או נכשלת לאורך זמן.
• הדגשת באג או תרחיש לפי שם כדי שתוכלו לבדוק בקלות רבה יותר והתרחיש הסתיים.
• הרצה של בדיקות מסוימות באופן בלתי תלוי, למשל דרך מסנן glob.

אחת הדרכים להסתכל על מקרי בדיקה היא להשתמש של בדיקת יחידה: לארגן, לפעול ולטעון. כל מקרה בדיקה במהותו:

• מסדרים כמה ערכים או מצבים (יכול להיות שאתם רק נתוני קלט בתוך הקוד).
• מבצעים פעולה, כמו קריאה ל-method.
• הצהרת בעלות על ערכי פלט או מצב מעודכן (באמצעות assert).

קנה המידה של הבדיקות

דוגמאות הקוד בקטע הקודם מתארות בדיקת יחידה, מכיוון שהן לבדוק חלקים קטנים בתוכנה, ולרוב מתמקדים בקובץ יחיד. רק הפלט מפונקציה אחת. מורכבות הבדיקה גדלה ככל להביא בחשבון קוד מכמה קבצים, רכיבים ואפילו רשתות שונות, (שלפעמים שאינן בשליטתכם, כמו שירותי רשת או של תלות חיצונית). לכן, בדרך כלל אנחנו נותנים שמות לסוגי בדיקות על סמך ההיקף או ההיקף שלהם.

יחד עם בדיקות יחידה, כמה דוגמאות לסוגי בדיקות אחרים כוללות רכיב בדיקה, בדיקות חזותיות ובדיקות שילוב. לאף אחד מהשמות האלה להגדרות קפדניות, ועשויות להיות להן משמעויות שונות, בהתאם לכן זכרו להשתמש בהם כקווים מנחים ולמצוא הגדרות עובד בשבילכם. לדוגמה: מהו רכיב שנבדק במערכת שלכם? עבור מגיבים למפתחים: יכול להיות שזה ימופה ל'רכיב תגובה', אבל יכול להיות יש משמעות אחרת למפתחים בהקשרים אחרים.

קנה המידה של בדיקה מסוימת יכול להציב אותה בתוך קונספט שמכונה לעיתים קרובות בתור "פירמידת הבדיקה", שהיא כלל אצבע טוב ואת האופן שבו הוא פועל.

הרעיון הזה חזר על עצמו, ועכשיו נוספו לו צורות אחרות פופולריים, כמו יהלום הבדיקה לבדוק את גביע הקרח. סביר להניח שהעדיפות של כתיבת הבדיקות תהיה ייחודית ב-codebase. עם זאת, תכונה נפוצה היא בדיקות פשוטות יותר, כמו בדיקות יחידה, בדרך כלל מהיר יותר להרצה, קל יותר לכתיבה (כך שיהיו לך יותר מהם), בודקים היקף מוגבל, ואילו בדיקות מורכבות כמו בדיקות מקצה לקצה קשה לכתוב אותו, אבל ניתן לבדוק היקף רחב יותר. למעשה, השכבה העליונה של בדיקת 'צורות' בדרך כלל מתבצעות בדיקות ידניות, מכיוון שחלק מהאינטראקציות של המשתמשים הם מורכבים מדי מכדי לקודד בבדיקה אוטומטית.

הסוגים האלה יורחבו בסוגי בדיקה.

בדיקת ההבנה