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

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

1. בדיקות מערכת

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

1. המשתמש נכנס למסך התחברות למערכת.
2. המשתמש מזין שם משתמש וסיסמא תקינים.
3. המשתמש מועבר למסך הבית של המערכת.
4. המשתמש לוחץ בתפריט על כפתור "הנפקת חשבונית"
5. המשתמש ממלא את פרטי החשבונית ולוחץ אישור. תוצאה צפויה: נוספה חשבונית במערכת עם הפרטים שהוזנו

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

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

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

2. בדיקות יחידה

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

1. נסה ליצור אוביקט מסוג Invoice ללא ציון מזהה לקוח.
2. תוצאה צפויה: הקוד זורק Exception מאחר ולא ניתן ליצור חשבונית ללא מזהה לקוח.

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

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

3. בדיקות פונקציונאליות

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

בדיקת פונקציונאליות למערכת החשבוניות יכולה להישמע בערך כך:

1. הכנס למסך Login
2. הכנס שם משתמש וסיסמא נכונים
3. תוצאה צפויה: מועבר למסך הבית

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

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

4. טכנולוגיות לבדיקה

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

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

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

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

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

5. חשוב לזכור

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

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

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

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