חודש: נובמבר 2018

מה כדאי לסטודנט לדעת – Git

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

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

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

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

אז מה זה ניהול גרסאות ולמה זה חשוב?

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

דבר נוסף שיכול לקרות, שננסה לשנות איזה משהו מסובך בקוד שלנו, ניגע באיזה 5 מחלקות בכמה קבצים שונים, נשנה כל מיני ברירות מחדל ואופס- לא חשבנו על משהו ובעצם זה לא ילך. איך חוזרים אחורה? לא חושב שמספיק לעשות Ctrl+Z לכל הקבצים..

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

הבעיות

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

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

הפתרון

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

בשונה מהרבה תוכנות לניהול גרסאות, ששומרות שינויים שנעשו מגרסה לגרסה (למשל- שורה 3 בקובץ file.f נמחקה, שורה 8 בקובץ my.file נוספה), גיט שומר בכל פעם את הגרסה הנוכחית של הקובץ. מכיוון שגיט שם דגש על מהירות, היכולת הזאת מאפשרת לגיט לעבור בין הגרסאות השמורות בקלות, כי כל גרסה פשוט שמורה במסד הנתונים, בעוד שתוכנות אחרות יצטרכו לעבור על כל השינויים שהם שמרו ולעשות אותם מחדש.

איך זה עובד?

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

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

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

אז מה יש לנו:

נעבור על ארבעת הבעיות שתיארנו.

חוסר יכולת לבטל שינויים של הקוד

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

"זוכרים"? בשביל שלא נצטרך לזכור (ובשביל עוד דברים) יש לנו את הענפים (מצביעים, כן?).

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

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

קושי בעבודה מבוזרת

אז איך פותרים את הסיפור הזה?

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

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

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

ביצוע Merge– שני ענפים שונים (אמנם אותו שם, אבל ענף אחד בשרת וענף אחד אצלנו) מתאחדים לCommit אחד אחרי Merge.

גיבויים של הקוד

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

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

עבודה במקביל על כמה שינויים ללא תלות של שינוי אחד בשני

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

מעבר בין ענפים לצורך תיקון באג במוצר

יתרונות נוספים

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

  • Blame– אם אני מגיע לקטע קוד בפרויקט מאוד גדול, ואני לא מבין מה קורה שם, אני יכול לראות מי האחרון שנגע בתיקייה / בקובץ / בשורה, ולפנות אליו כדי לקבל מידע נוסף.
  • Bisect– אם אנחנו מגיעים לגרסה מסוימת ומגלים שיש באג. איך אנחנו מוצאים מה גרם לבאג? אם מקפידים שבכל Commit הקוד יתקמפל, אפשר לעשות חיפוש בינארי בעזרת Bisect. אנחנו אומרים לו מה הCommit הטוב האחרון שאנחנו זוכרים, וגיט מעביר אותנו כל פעם לCommit באמצע הדרך ושואל אותנו אם הוא טוב או רע. בסוף גיט אומר לנו מה הCommit הראשון שבו יש שגיאה, ואנחנו רואים מה השינוי שבוצע ומבינים (או שלא) מה גרם לבאג.

קריאה נוספת

  • רן בר זיק באתר "אינטרנט ישראל"– רן בר זיק הוא מפתח Frontend והוא מסביר באתר שלו על המון דברים מעניינים, מפיתוח בטכנולוגיות Web ועד "סייבר". הקישור מפנה לסדרת ההדרכות שלו על גיט.
  • הספר של גיט– לקוראי האנגלית, כאן ההסבר הרשמי של גיט על הטכניקות של הכלי, תוך כדי הסברים על אופן השימוש בפועל.
  • ממשק משתמש לגיט– תוכנת Git Extension היא תוכנה נחמדה לעבודה מול גיט בממשק משתמש אינטראקטיבי ולא בשורת הפקודה. אני משתמש הרבה בתוכנה הזאת.

מושגים

  • Git– גִיט הוא כלי לניהול גרסאות, שמאפשר לנו לעבוד על אותו קוד עם אנשים אחרים, ולעבור בקלות ובמהירות בין גרסאות שונות של הקוד לצורך משימות שונות.
  • GitHub– גִיטהָאבּ הוא אתר לשיתוף קוד שמתבסס על תוכנת גיט.
  • Commit– קוֹמִיט היא הפעולה הבסיסית בGit, שאומר לכלי לשמור את המצב הנוכחי כגרסה.
  • Feature– תכונה. משמש אותנו לתיאור "יכולת" מסוימת. למשל- "ווטסאפ הוסיפו פיצ'ר חדש, וי כחול".
  • Branch– מצביע על Commit מסוים בגיט. או ביותר אנושי- רצף קומיטים כלשהו.

Hyper-V: מכונה וירטואלית בWindows

החל מWindows 8, חברת Microsoft הוסיפה למערכת ההפעלה את תכונת Hyper-V, אפשרות לדמות כונן, נתב או מערכת הפעלה בתוך Windows. אם עד עכשיו היינו צריכים להוריד תוכנה מסוימת לשם כך, עכשיו זה זמין יותר, ולדעתי גם פשוט ובטוח יותר.
הרעיון של מערכת הפעלה בתוך מערכת הפעלה (virtual machine- מכונה וירטואלית) משמש אותנו במידה ואנחנו זקוקים למערכת הפעלה שונה מזאת שיש לנו עכשיו, או שאנחנו רוצים לעשות ניסויים או פעולות בלי חשש לפגיעה בקבצים, הגדרות, תוכנות וכד'. מעין סביבת עבודה מוגנת.

דרישות:

חשוב לשים לב לדברים הבאים:

  1. קובץ iso- בשביל להפעיל מערכת הפעלה נוספת, נצטרך את קובץ הiso שלה. פשוט מחפשים בגוגל Windows 7 iso ומורידים, ממקור אמין כמובן.
  2. Maximum RAM- לתוכנת Hyper-V יש מגבלה כלשהי של זכרון שהיא מאפשרת. המערכת שאנחנו רוצים להפעיל חייבת לתמוך בכמות הזיכרון הזאת. את המגבלה אפשר לבדוק בהמשך בשלב 6, מה שאומר שצריך להמשיך רגע במהירות במדריך, לבדוק את המגבלה, ואז לחזור ולהוריד קובץ iso מתאים.

התקנה:

כדי להפעיל את Hyper-V נצטרך להוסיף את התכונה לWindows.

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

תפריט

לחיצה על "הפעל או בטל תכונות Windows":

 

בחירה בHyper-V ולחיצה על אישור:

 

לאחר ההתקנה אפשר לחפש את Hyper-V Manager ולפתוח אותו. נקבל חלון כזה:

 

כדי להוסיף מערכת הפעלה וירטואלית חדשה, נלחץ על New>Virtual Machine, והגענו לחלון ההגדרה:

  1. Next.
  2. לתת שם למכונה שלנו.
  3. Next.
  4. Generation 1 (אם המערכת הפעלה שאנחנו מתכוונים להפעיל תומכת ב64 ביט, ניתן לבחור גם בGeneration 2).
  5. Next.
  6. 1024, Next.
  7. Next.
  8. Next.
  9. Install an operating system from bootable CD/DVD-ROM.
  10. Image file.
  11. לבחור את הקובץ iso של המערכת שאנחנו רוצים להפעיל (מה זה הקובץ הזה- אני מסביר בהמשך.)
  12. Next.
  13. Finish.

 

מה כדאי לסטודנט לדעת- טסטים

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

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

אז הנושא הראשון שבחרתי הוא-

טסטים- בדיקות (Tests)

ואחרי כל ההקדמה- על מה מדובר?

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

מקרה לדוגמא:

מבוסס על סיפור אמיתי- הטסטים הראשונים שלי.

ניקח תרגיל ממבנה נתונים:

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

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

אני אציג רק את הקוד הרלוונטי כדי לא להעמיס (המימוש הוא בשפת #C. אני מחפש תוסף שיאפשר להציג בכמה שפות):

<br>
class PersonList<br>
{<br>
    private Person head;<br>
    public void InsertNewPerson(Person person)<br>
    {<br>
        var temp = head;<br>
        while (temp.Next()?.age > person.age)<br>
        {<br>
            temp = temp.Next();<br>
        }<br>
        var next = temp.Next();<br>
        temp.SetNext(person);<br>
        person.SetNext(next);<br>
    }<br>
    public int GetMinAge()<br>
    {<br>
        var temp = head;<br>
        while (temp.HasNext()) temp = temp.Next();<br>
        return temp.age;<br>
    }<br>
    public double GetAverage()<br>
    {<br>
        var temp = head;<br>
        var sum = 0, i = 0;<br>
        for (; temp.HasNext(); i++, temp = temp.Next()) sum += temp.age;<br>
        return sum / i;<br>
    }<br>
}<br>

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

לא!

סוגי הבדיקות

הבדיקות נחלקות ל4 קבוצות, כשכל קבוצה מרחיבה את הבדיקות של הקבוצה הקודמת.

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

בדיקות יחידה (Unit Tests):

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

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

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

[TestClass]
class PersonListTests
{
    [TestMethod]
    public void InsertNewPerson()
    {
        var personToAdd = new Person("Baruch", 25);
        var personList = new PersonList();
        personList.InsertNewPerson(personToAdd);

        Assert.AreEqual(personToAdd, personList.GetHead());
    }

    [TestMethod]
    public void GetMinAge()
    {
        var personList = new PersonList();
        personList.InsertNewPerson(new Person("A", 34));
        personList.InsertNewPerson(new Person("B", 100));
        personList.InsertNewPerson(new Person("C", 0));
        personList.InsertNewPerson(new Person("D", 34));
        personList.InsertNewPerson(new Person("E", 22));
        personList.InsertNewPerson(new Person("F", 57));

        Assert.AreEqual(0, personList.GetMinAge());
    }

    [TestMethod]
    public void GetAverage()
    {
        var personList = new PersonList();
        personList.InsertNewPerson(new Person("A", 34));
        personList.InsertNewPerson(new Person("B", 100));
        personList.InsertNewPerson(new Person("C", 0));
        personList.InsertNewPerson(new Person("D", 34));
        personList.InsertNewPerson(new Person("E", 22));
        personList.InsertNewPerson(new Person("F", 57));

        Assert.AreEqual(41, (int)personList.GetMinAge());
    }
}

אם נריץ את הקוד בעזרת הפקודה `dotnet test` למשל, נקבל דו"ח עבור שלושת הטסטים והאם הם עברו.

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

בדיקות אינטגרציה (Integration Tests):

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

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

בדיקות מערכת (System Tests):

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

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

בכך שאנחנו עושים את הבדיקות בשלבים, אנחנו יודעים שאם נתקלנו בבעיה בשלב המערכת, כנראה שהבעיה היא בסביבה ולא בלוגיקה של הקוד (אם כי תמיד צריך גם לחשוב- אולי יש בעיה בלוגיקה של הקוד שלא כיסינו בשלבים הקודמים?)

בדיקות קבלה (Acceptance Tests):

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

להרחבה:

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

מושגים

  • agile– עדיין אין פירוט למושג הזה.
  • unit-test– עדיין אין פירוט למושג הזה.
  • integration-test– עדיין אין פירוט למושג הזה.