מה זה בדיקות אינטגרציה? הסבר + משרות בישראל

בדיקות אינטגרציה בודקות שכמה רכיבים עובדים נכון יחד - למשל שהקוד באמת שומר במסד הנתונים מה שהוא אמור, ושהתשובה מהממשק החיצוני מטופלת כראוי. הן השכבה שבין בדיקות יחידה לבדיקות מסך מלאות. בלוח HiTakeJob פתוחות כרגע 47 משרות שמזכירות CI/CD, 26 שמזכירות REST API ו-133 שמזכירות SQL.

למה בדיקות יחידה לא מספיקות

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

רוב הבאגים במערכות אמיתיות נמצאים בדיוק בין הרכיבים ולא בתוכם:

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

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

מה בודקים בפועל

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

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

מה עושים עם שירותים חיצוניים

זו השאלה הקשה בתחום, ויש שלוש גישות - לכל אחת מחיר:

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

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

איך מריצים אותן בלי שהן יהפכו לנטל

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

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

מה זה בדיקת חוזה ולמה זה קשור

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

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

איפה זה יושב בשרשרת

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

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

איך מכינים נתוני בדיקה

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

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

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

מי כותב אותן

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

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

שאלות נפוצות

מה ההבדל בין אינטגרציה למקצה לקצה?

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

האם צריך מסד נתונים אמיתי בבדיקות?

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

כמה זמן סביר שייקח להן לרוץ?

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

איך בודקים תהליך אסינכרוני?

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

מי אחראי על התשתית שמריצה אותן?

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

איך בודקים מיגרציית מסד נתונים?

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

מה עושים כשהשירות החיצוני לא זמין בזמן הבדיקה?

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

האם זה נדרש גם במשרות פיתוח ולא רק QA?

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