Introduction

[00:03] (external link, opens in new tab) כמה אנשים פה יש ניסיון עםסים אוקיי למי יש ניסיון עם obקטס דברים כמוס בערך בסדר כמה אנשים שמעו בכלל testing כמה אנשים חושבים שזה רעיון טוב יופי מצוין כאילו מין שאלה כזאת מוזמינת אבל תכף נדבר אם זה באמת רעיון טוב או לא משה מתכוונים כל הסיידים שאתם תראו פה אפשר להוריד בPDF אחד גדול פשוט תלכו הURL הזה ותורידו את זה. אני נסה לא להרוג עקסים כמה שאפשר.

[00:36] (external link, opens in new tab) חוץ מזה מרבית הקורס הזה הוא בכלל לא סליידים אלא מרבית הקורס הוא כל כך קידוד. אז כאן אני אסביר לגבי השלושה ימים היום זה יום שמדבר על unit testingd ברמת הביסיקס בלבד. אנחנו לא נכסה מ objects בכלל אבל המון המון נכסה נושא של מה זה לכתוב testים טובים מבחינתability וust. שלושה דברים שהם חשובים שבעדיהם כל הנושא של יניטestינג בארגולים נכשל כמובן נכסה את כל הרעיון של מה זה יestיננו שמישהו שמעולם לא כתב unitטest בחיים שלו יוכל להתחיל את הקורס הזה אז גם אם בחיים שלכם לא כתבתם שורה של קוד עם משהו כמו NUnit (external link, opens in new tab) או MSTest בסדר גמור והקורס הזה לא מניח שום הנחות את הדיטה שלכם אז אנחנו נצח ברמה מסוימת שמי שכבר יש לו ניסיון בהתחלה יחשוב שזה קצת טיפ טיפה מוכר אבל במהלך זה גם נכסה המון דברים המון prctices גם בטestטים הכי הכי פשוטים אפשר לכתוב אותם בצורה מאוד גבוהה אנחנו נתחיל לחסות את הדברים שגורים לטסestינג להצליח בא הרבה פעמים יוני testing אני לא יודע למה יש חברים שניסו

[01:36] (external link, opens in new tab) לעשות יוני testing ונכשלו אבל זה קורה המון אנשים מנסים לעשות יוניט testing לי זה קרה בפרויקט הראשון שלי שאחרי שישה חודשים בערך התחלנו בעצם למחוק יוניטestים בגלל שכל פעם ששימינו את החוד היוטestטים התחילו להתפרק לנו התחילו ליפול ובשו שלב העלות והתועלת כבר לא היו שוות ואז התחלנו כבר להגיד אוקיי אז כל ההשקעה הזאת הייתה די לשב והתחלנו למחוק טestטים אז הרבה מהשיעורים שאתם תראו פה זה דברים שנלמדו בדרך הקשה כן כל החוקים האלה נכתבו בדם וכולי וזה ממש ככה זה ממש היה המון שיעורים מאוד קשים על איך לא לעשות ואיך כן לעשות

[02:15] (external link, opens in new tab) אני אישית עובד בנושא של יונטסing וtvd 10 שנים בערך תשע שנים התחלתי בVB5 וV6 שש עוד אז היו כבר פריורקים ליוטesting וניסיתי אותם וכבר אז כתבתי דברים בצורה מאוד גרועה אבל למדתי בדרך אז I say you don't have to אבל unit testing (external link, opens in new tab) tdd (external link, opens in new tab) הם שני דברים שונים הרבה פעמים אנשו אומרים שהם עושים TDD אבל הם עושים unit testing הם לא עושים test driven and development אז יש פה שני פסטים שונים אנחנו נלמד את שניהם

[02:50] (external link, opens in new tab) Unit testing זה האקט של כתיבה של הטestינג איך כותבים אותם וזה הסקיל של איך לכתוב אותם כמו שצריך. TDD זה מתי אתם כותבים את הטestים ואיך אתם משתמשים בהם כדי לדחוף את המוצר. ‏test dream development זה הרבה פעמים מדברים על זה שכותבים את הטestטים לפני הקוד אבל זה אבל אנחנו בהתחלה בחצי הלשון שלהם לא נתמקד בכתיבה של הטסטים לפני הקוד בכלל נתמקד באיך לכתוב אותם אחרי זה נראה איך הכתיבה שלהם בפני הקוד איך היא משפרת ומה היא עוזרת וכולי אבל הרבה פעמים הנושא של tdtd וני testing אנשים מחברים אותם ביחד חשוב שתבינו שאפשר לכתוב testים גם test first והם יהיו מאוד מאוד גרועים אוקיי וגם אפשר לכתוב testים שהם כתובים אחרי הקוד והם יהיו מאוד מאוד טובים לשני סקיל שם שהם לא קשורים חדשים.

[03:33] (external link, opens in new tab) יש סקיל אחד נוסף שאני לא מלמד בחוץ הזה וזה דזיין. הרבה אנשים מדברים על TDD ואומרים test driven design מי ששמע. וראינו שהטestטים עוזרים לעצב את הדיזיין של הקוד שלכם ותוך כדי אתם גם יכולים ליצור דיזיין של הקוד שלא חשבתם שבהתחלה יהיה לכם. אז אנחנו נעשה אולי טיפ טיפה מזה אבל אני לא הולך ללמי זignק conceptפט בקורס הזה. נושא של design patterns solid principles (external link, opens in new tab) של איך לתורק oנט כל כצורה שהיא compפונט בשביל זה יש זה סקיל נפרד

[04:05] (external link, opens in new tab) ואחד הדברים שראיתי זה שהמון אנשים נכשלים בעולם של td בכלל מצפסיקים לעשות את זה כשמנסים ללמוד שלושה דברים בבת אחת שזה לכתובטest לכתוב אותם לפני שכותבים את הקוד וגם להתעקל בבעיות דיזיין תוך כדי זאת אומרת איך לעשות את הדברים את הדיזיין בצורה הכי טובה אם אתם מנסים לעשות את שלושת הדברים האלה מבת אחת הרבה פעמים נכשלים בגלל שהקיר הוא גבוה מדי. אתה מנסה לכתוב את הטest הראשון שלך ופתאום את צריך לעשות את שלושת הדברים האלה בבת אחת. ואם אתה לא יודע לעשות אף אחד מהם עדיין אז ללמוד אותם תוך כדי עשייה של משהו שאתה עדיין לא יודע זה דבר הרבה יותר מסובך.

[04:39] (external link, opens in new tab) אז אנחנו הולכים לעשות את השניים הראשונים. לכתוב testing ואז ללמוד לכתוב אותם test first person. 50% מהקורס הזה הם קידוד. זאת אומרת שבחצי השני של היום רוב מה שתעשו זה קידוד. אתם תהיו בעיקר בחברים האלה. אבל בחצי הראשון אני הולך להראות בעיקר איך לכתוב את הטestינג וגם איך נראית הסביבה שלי בתוך סטודיו איך נראית סביבה של מישהו שרוצה לעשות TDD זאת קונפיגורציה אחת של הסביבה אני אראה לכם גם הרבה כלים שחלקכם אוהבים חלקכם לא אוהבים זה גם בסדר אני אראה לכם את הדרך שלי לעשות את זה ואני גם מסביר למה

[05:13] (external link, opens in new tab) אני אוהב את הדרך הזאת זאת אומרת לכל דבר תהיה סיבה ואם יש לכם שאלות אז זה אין לי שום בעיה שזאת תהיה שיחה ולא הרצאה אמ אני גם מסביר הרבה קונספטים שקשורים לאוטומציה ואטומציה של ויזואל סטודיו בגלל שאני מאמין שכמתכנתים כאנשים מקצוענים אנחנו צריכים להכיר את הפילים שלנו בצורה הטובה ביותר פשוט להכיר את כל ה את כל היכולות שלהם או את רוב היכולות שלהם אה יש פה מישהו שמשתמש ברישרטה אוקיי מי אוהב את רישאר מהמשתמשים

[05:46] (external link, opens in new tab) יודע יש פה ליססים לקנות כולם התקינו טרייל אוקיי אנחנו נשתמש בריאפר הרבה כי אני משתמש בו לtvdd אמ לדוגמה אם רוצים להכיר את רישפר זה להכיר את רוב השורטקאטים שלו את כולם להכיר את היכולות שלו ומתי אפשר לעשות מה אז אנחנו נכנס גם לכמה פיצ'רים שלו שעוזרים בתהליך שלv בתהליך של כתיבת הטestטים עוד ניכנס בהמשך היום גם לכלים של continous test שעוזרים לנו להריץ דברים בטd אבל בצורה שהיא כמעט בלתי נראית לעין בלי שני אצטריך לעשות הרבה עבודה

[06:21] (external link, opens in new tab) אוקיי אז הקונספט קר קודם כל הקורס הזה נקרא tdd בגלל שכל כל הקידות שאתם תעשו בקורס מלבד השעה אוניה הראשונה או השנייה שלכם היום יהיו test first גם הדברים המסובכים ביותר אתם תנסו לעשות דברים test first ביום השני אנחנו נדבר על מוק (external link, opens in new tab) objects וניכנס לטestטים הרבה יותר מסובכים ממה שאנחנו כותבים היום הרבה פעמים אנשים אומרים שהיום הראשון זה היה יום קצת פשוט והכל די בסדר ונו ציפיתי ליותר אז ביום השני יש עלייה ת מדרגה מאוד גבוהה ואז אנשים אומרים או כן בסדר זה מה שרשיתי אבל אי אפשר לעשות את היום השני בלי היום הראשון חשוב שתבינו שהביסיקס האלה הם מאוד חשובים

[06:58] (external link, opens in new tab) אז נלמד המון best practices במק וגם את זה נעשה testing ביום השלישי ניכנס ללגס קוד ונראה איך כותבים testingים לקוד קיים כולל רפקטורing וגם מה קורה שאי אפשר לעשות רפקטורים אז אשתמש בקליפ כמו כדי לכתוב טestטים לקוד קיים בלי לשנות אותו כדי שתוכלו לראות שיש אופציות תמיד אפשר אפשר או להשתמש בכלי או לעשות ריפת כל גם בלגסי קוד אפשר לעשות דברים שהם test זאת אומרת אם מצאתם איזשהו בג קודם כל כותבים את הטest שמוכיח שיש בג ואז פותרים את הבג ואז רואים שהטestט עובר אז testן זה לא רק לקוד חדש זה גם בהחלט יכול להיות לקוד קיים או תיקון של קוד קיים יותר נכון

[07:40] (external link, opens in new tab) אוקיי אמ כמה צרטים יש פה דרך אגב שלושה שושה צבטים אתם גם יושבים כרגע לפי הצבטים שלכם אחד לשני אנחנו בט לא מתערב >> יש צוות אחד שיושב למעלה או שכולם יושבים פה בחומה הזאת >> אחד שישב למעלה אבל היום לצורך הזה אנחנו כולנו יושב למעלה >> אוקיי אוקיי אז test development הוא prctice אחד שבא מעולם האxtream praming exream prraming אני מניח שובכם כבר שמעתם את של extraming מה שיפה בtd שאפשר לקחת את הrac הזה כמו שהוא ולעשים שים אותו בכל מתודולוגיה הוא לא קשור למתודולוגיה

[08:21] (external link, opens in new tab) זה משטיס שהוא בן אדם למחשבות תחשבו על זה ככה אף אחד לא יכול להגיד לכם לכתוב testing כי זה החלטה שלכם כמו שאף אחד לא יכול להגיד לכם לעשות דבג למשהו זה החלטה שלכם איך לעשות איך לכתוב קוד ולכן גם אם אתם יודעים בעולם הוורטרפול הכי גדול שיכול להיות נגיד אמדוקס אתם עדיין יכולים לעשות DVD בגלל שזה החלטה שלכם לכתוב את הטestטים מה קורה אחרי זה האם יש איזשהו בילס ו שמריץ את הטestטים אלה כבר דברים שמשפיעים על הקבוצה על על ההחלטה על ההרגשה איך זה לעבוד בתור קבוצה

[08:55] (external link, opens in new tab) אבל בכל ארגון אתם יכולים להיות הבן אדם שמתחיל את הדבר הזה ושמריץ את כל הטestטים שלו לפחות אישית לפני שהוא כותב את כל פעם זה חשוב כי בכל הרבה פעמים יש הרבה התנגדויות לדברים גם אנשים ששמעו על יוניטסing הרבה פעמים חושבים שזה לא מכחות וצריכים להרגיש באמת עוזר ואחד הדרכים לדחוף את זה זה להראות תוצאות אז כדי להבין מה זה TDD צריך כדי להבין מה זהIT testing צריך להבין מה זהIT test זאת ההגדרה של הITEST מויקיפדיה

[09:30] (external link, opens in new tab) הגדרה חלקית a test of a small function of cod יש לנו פונקציה is login אוקיי שמקבלת user וורד אז unit test יהיה חתיכת קוד אחרת שמפעילה את החתיכת קוד הזאת אוקיי אמ עכשיו לפני שיכנס להדר שלטסט כמה לדעתכם טסטים אפשר לכתוב לפונקציה הזאת בלי שאנחנו יודעים בכלל את הפונקציונליות שלה מה המספר המינימלי של טestטים אה >> ארבע איזה testing user password not user password

[10:04] (external link, opens in new tab) >> ואז password user not password user not >> אז זה כבר לא יותר מארבע >> אה חשבתי ש אה אתה רוצה טestט אחד עם שני אלה לנלים טestט אחד עם אחד נעל ואחד לא אוקיי ואז >> טestט שלישי השני נעל והראשון לא >> אוקיי >> והראשון שש שניהם לא >> אוקיי יש למישהו עוד רות אני לא >> אני חושב שזה כאילו תלוי במה מה הפונקציה הזאת עושה כלומר יכול להיות שם >> לכל פונקציית לוגן שמקלת שני פרמטרים זירה בול מה תסים המנירים של רוב הסיכויים שיהיה לך >> לפי התרחישים שמתמולדת בהם למשל אם יש יוזר קיים אז אני צריך גם לעשות בדיקה שאם היוזר הזה קיים אז לעשות את זה גם כב >> אוקיי אז לא user נעל אלא user שהוא

[10:48] (external link, opens in new tab) Does not exist אוקיי >> למשל השם של הזר לצורך הנון הוא לא חוקי לדוגמה >> שם של הזר הוא לא חוקי אוקיי >> אוקיי בעצם לפי כמות >> כן לדוגמה >> אוקיי >> >> אז כמה כבר הגענו חם אנחנו הולכים על שש >> שבע >> שבע אוקיי אז בואו רגע ננסה סטטוס פה כמה אנשים חושבים כמה אנשים חושבים שצריך פה אה לפחות שלושה טestטים לפחות ארבעה

[11:19] (external link, opens in new tab) חמישה שישה שבעה שמונה אוקיי לפחות שמונה טסטים רובה אנשים שפה חושבים שמונה טים אני דווקא אלך לקונסנוס הנמוך ביותר וזה היה ארבעה בואו נניח ארבעה ואנחנו נחיה עם ארבעה עכשיו בעינתן שלפונקציה הזאתי יש לוגיקה אנחנו בדרך כלל נכתוב נכתוב טסים לקוד שיש לו לוגיקה סוויץ כל הדברים האלה לולאות לא לכתובסטים ישירות לפרerטז שלא עושים שום דבר כי זה בדרך כלל סוג של בזבוז זמן

[11:53] (external link, opens in new tab) כמה פונקציות עם לוגיקה יש לכם במערכת איןס >> וכמה שאלת מילה אתה רוצה אלים >> אלפים לא לפחות >> לפחות כמה אוקיי אני אני אקל לכם כמה publicקפ functionנקשנס אז אם לא יש לכם במערכת לא ממש אוקיי אז רק מספר יותר מ-500 יותר מ-5,000 מה >> הייתי אומר יותר מ1,000 >> יותר מ-10,000 אז כמה טestטים לפחות צריכים להיות לכם במערכת לדעתכם

[12:28] (external link, opens in new tab) זה לא כולם מחזירות גוליה אני מניח לא כולם יש להם שני פרמטרים אבל אתכם בממוציה אחת שצריך להיות לה 200 טסים יכול שב על פונקציה אחת שצריך להיות רק ל 200 >> אוקיי איזה שנים >> אני ראיתי איזשהו אימיל שהסתובב פה על פונקציה שיהיה שמישהו פוחד של זה הפונקציה מדבר על הפונקציה >> אה אוקיי נראותה מאוד נחמדה הפונקציה >> יש עוד כמה כא >> זה דרך אגב הגדרה של הפונקציה הזאת זה נקרא גוד זה אתה לא יודע למה היא עושה מה שהיא עושה אתה רק יודע שתניח לה לנפשה והיא תעשה את מה שהיא צריכה אל תיגע אל תתערב מה שנקרא

[13:05] (external link, opens in new tab) אמ אוקיי אז אנחנו מדברים פה על כמה כמה אלפי טסטים טובים לפחות או כמה 10,000 טestטים עכשיו אתם לא החברה היחידה שיש להם את כמות הפונקציות האלה נכון אתם גם לא החברה הכי גדולה שיש כלומר זה לא הקוד הכי הקודביס הכי גדול שראיתי מרבית החברות גם כשאני שואל את השאלה הזאת ויש להם טestטים אין להם אפילו קרוב למספר של טestטים שנלתם צריך להיות מינימלי ש את השאלה למה

[13:36] (external link, opens in new tab) יש לכם רעיון למה חברות שגם שיודעות לעשות testing לא כותבות את כל הטסא של זמן >> שאלה של זמן אוקיי עצלנות צלנות >> אני לא חושב שמתכן תהיה מצ >> לחץ של זמן שתו >> לחץ של זמן זה תמיד לחץ של זמן שזה יהיהסית >> אוקיי לחץ של זמן זה מרכיב מאוד מאוד עיקרי אבל אני רוצה לפרק את זה לבעיה יותר לכמה בעיות יותר קטנות ואנחנו ננסה לדבר על הבעיות האלה והבעיות האלה בדרך כלל כשמדברים על יניטestטים אומרים אומרים

[14:10] (external link, opens in new tab) או אם אתם ראיתם פעם הרצהים אומרים את הדברים האלה על unit test כשיש לי 10,000 יוניטestים בקוד יותר קל לי למצוא באגים נכון או לא נכון או מיי חושב שזה נכון מי חושב שזה נכון מי חושב שאולי זה לא נכון זה אולי לא נכון >> אולי לא נכון למה יכול להיות שהטסטים שלך לא בודקים כלום אוקיי יכול להיות שהטestים שלי לא בודקים יכול להיות שלטסestים שלי יש בדים כן איך אני אדע אם לטסט שלי יש בד אני טס הטest ואם הטסט טס של יש בה קורסיבי

[14:42] (external link, opens in new tab) אז לא בהכרח מוצאים את הבאגים כשיש 10,000 טestטים בקוד וזה מאוד נכון הרבה פעמים אנשים כותבים את הטestטים והם לא כותבים את הטestטים הנכונים או הם בודקים את הדבר הלא נכון דווקא פה הנושא של test dream development לכתוב את הtest לפני הקוד מאוד עוזר כי כשכותבים את הטest לפני הקוד אני לא יודע אם שמה אתם מתחילים מטestט שנכשל ואז גורמים לו לעבור בלי לגעת בטestט ובצורה הזאת בודקים את הטest הוא אמור להיקשל ואז הוא אמור לעבור ואם הוא מתחיל בהתחלה בלי כישלון או שהוא נכשל אבל קמתם את הפרודקשן אבל הוא ממשיך להתקשב ולא עובר יכול להיות שמצאתם באג בטest עצמו וtd זה אחד הפרקטיס היחידים שאני מכיר שבאמת עוזר לך לבדוק את הטestטים שלך ולוודא שהם באמת נכונים בלי לכתוב טestטים לטestטים

[15:30] (external link, opens in new tab) יותר קל לעשות maננס לקוד אם יש 10,000 testים מי חושב שזה נכון מי חושב שזה לא בכלל נכון למה >> כי כל >> כתבתזה חמישה לא >> כתבתי כן כי כל כי כל שינוי בקוד עכשיו אתה צריך לשנות פי חמש טestטים מהקוד ששניתם >> אוקיי אז אני אתן לכם את הדוגמה הכי פשוטה כתבתם 20 טestטים שיוצרים אינסטנס של איזשהו קלאס וקוראים לפונקציה על הקלאס הזה עכשיו הלכתם והוספתם קונסטרקטור לקס הזה עכשיו יש לכם 20 טסטים שלא מתקמנים צריכים לשנות אותם אחד זה הדוגמה הכי פשוטה וזה אחד הדברים שקורים הכי הרבה

[16:08] (external link, opens in new tab) אז פתאום המייטנס של הקוד נהיה הרבה יותר גרוע לא הרבה יותר טוב אז כל הזמן שהטסם אמורים לחסוך לכם אולי בדיבגים או במציא באגים פתאום עולה לכם בזמן של מינס זה אחד הפיונים הכי מרכזיים שאנשים שקורים לאנשים להפסיק לעשות יני testing זה שכשהשינו של פרודקש קוד עולה הרבה יותר זמן בגלל שהטestטים דורשים תחזוקה גם במהלך הקורס הזה אנחנו נתמקד הרבה בלגרום לטסטים להיות הרבה יותר מנטינבילים כדי שהעלות הזאת תהיה כמה שיותר נמוכה.

[16:41] (external link, opens in new tab) אם אנחנו לא נטפל בעלות הזאת אז הטestטים פשוט יאכלו לנו את את הזמן של הפרודקשן ולא יהיה שווה לעשות אותו. אז אם אנחנו לא עושים טestים שהם מינטינable לא שווה לנו בכלל לעשות טסים. פשוט ככה לא שווה לעשות אותם בגלל שאנחנו שלושות שים להתפתר מהם. אולי שווה לעשות כמה כמה inרation test ככה פה ושם מדי פעם זורקים ואז כותבים מחדש אבל ממש להיכנס לנושא הזה לא שווה כי הזמן שזה יעלה הוא הרבה יותר גבוה הרבה ארגונים נופלים דווקא בדבר הזה

[17:12] (external link, opens in new tab) ובפרויקט הראשון שכתבתי אי פעם זה באמת הייתה הבעיה זאת אחת הסיבות שהתחלנו להיפטר מהטestטים ושראינו שהקוד מתחיל להרגיש כמו בטון שכל דבר שאתה מנסה לשנות יש 20 טestטים שאומרים שהוא צריך להראות בצורה מסוימת ועכשיו אי אפשר לשנות את הצורה הזאת ואנחנו נדבר על איך אפשר לפתור את הבעיה הזאת. ועוד דבר שאומרים על testי, יש לך 10,000 טestטים, יותר קל להבין את הקוד. וכשאומרים את זה, מתכוונים לזה שהטestטים סוג של executable specificק שאתה לוקח מתכנת חדש לצוות ואתה אומר לו הנה הקלאס והנה הטestטים, תסתכל על הטestטים ותבין איך הקלאס עובד.

[17:50] (external link, opens in new tab) הרבה פעמים גם זה הדבר הזה בכלל לא נכון כי כשאנשים כותבים testים בהתחלה השמות שהם נותנים לטestטים הם test אחד test 1 שט test also שת וכולי לא אכפת להם בכלל מהשמות של הטestטים לא אכפת להם מהרדity של הטesting ואז הדבר הזה לא נכון בכלל אז אנחנו גם נדבר על הרדילטי של הטestטים ועל עד כמה הוא חשוב ואיך לגרום להם להיות יותר יותר רק אם שלושת הדברים האלה נכונים אז באמת קל יותר לפתח עם טesting אם אפילו אחד מהם לא נכון הוא משפיע על כל ה וכל החוויה הזאת נהיית הרבה יותר גרועה

[18:27] (external link, opens in new tab) ו וביחד תיקחו כל חברה היום שאין לה אין לה את ה אין לה את הזמן לעשות טestטים או חברה שהתחילה והפסיקה היא תגיד לכם שזה קשור לאחת הסיבות האלה אבל הם יגידו עוד כל מיני דברים חלק יגידו אנחנו כבר עושים יוניטestטים אבל הם לא באמת עושים יניטסטים בהגדרה שלנו. זאת אומרת הם כל פעם בודקים בצורה ידנית. מישהו פה כתב אי פעםפור עם כל מיני טקסט בוקס וכפתורים בטן אד בטן שתיים. אם לוחצים עליהם בסדר הנכון אז יודעים שהכל עובד.

[18:59] (external link, opens in new tab) אי פעם מישהו עשה את זה? אני עשיתי את זה. מישהו עשה את זה? אוקיי זה לוקח הרבה זמן ואתם היחידים שיכולים להריץ את הדבר הזה. אז ברגע שאתם כתבתם את זה ברגע שאתם לא משתמשים באיזשהו פריימורק אז הטestטים שלכם הם אינדיבידואלים. אינדיבידואליסטים לחלוטין. המטרה שלנו היא שהטestטים האלה הם יהיו repפatable שכל אחד יוכל לחזור עליהם. שהם יהיו מהירים, אבל גם אנחנו רוצים שזה יהיה על כל הקוד שלנו. הרבה פעמים אנחנו לא כותבים טסטים על כל הקוד שלנו בגלל שלוקח הרבה זמן לכתוב אותם בגלל שלא משתמשים באיזשהו פריימורק.

[19:29] (external link, opens in new tab) אם היינו משתמשים בפריים הרבה פעמים יותר קל לכתוב את הטestטים בגלל שהפרימוקים מקלים עלינו. בפנים זה הרבה יותר קשה לכתוב את הטסטים בגלל שאין לנו את פרימו כזה בגלל שאנחנו צריכים להריץ אותם בצורה אוטומטית לעשות איזה איזשהו קומנדלי כדי להריץ אותם. אבל אני רוצה לחזור להגדרה של unit test מה זה unit

[20:00] (external link, opens in new tab) ופה אנח אנחנו צריכים את הורד מה זה יוני דה לפני שאד חוזר מהם אזור בקוד >> מה >> אזור בקוד >> אזור בקוד אוקיי אז איפה האזור הזה מתחיל פה קצת מעל הפונקציה פולה את הספייס מעל הפונקציה אה אז יוניט משתנה בהתאם להגדרות שלך זה ניחוש >> אוקיי יש למישהו עוד ניחושים לא אומר שזה ניחוש לא נכון אה >> פונקציה >> מה >> פונקציה פעם חשבתי שזה פונקציה אתה צודק

[20:37] (external link, opens in new tab) מהח של הטסט בודק >> מה >> החלק של הטסט של הפונקציה >> החלק של הקוד שאתה בודק החלק של הפונקציה >> החלק שלו >> כמה שהוא שרוקות בפונקציה אוקיי יש עוד אפשרויות קלאס >> קלאס לפעמים אתה בודק קלאס שלם עם כל הפונקציות שלו נכון אנחנו צריכים כן

[21:17] (external link, opens in new tab) יכול להוריד את המחשפה זה בסדר >> זה לא מזל טוב או משהו הדבר הזה כנראה שלא >> יכולים למעלה למה למעלה זרוק אתה למעלה אותה לא >> אוקיי אז יכול להות פונקציה אה פשן x זה יכול להיות קס

[21:50] (external link, opens in new tab) מהו זה יכול להיות תהליך >> תהליך מה זה תהליך פעולה מס פעולה של מי מתחיל כל אחד אתה תהליך דוח כל אחד זאת אומרת מפתח מתחיל אותה תהליך >> user אוקיי אז יוזר מתחיל איזשהו תהליך ואז מבחינת הקוד מה התהליך הזה כולל כלול את הקוד שקס עם הפרמטרים האלה הוא לא בהכרח הפונקציה כי הוא יכול להגיע לעוד פונקציות למטה >> אוקיי

[22:21] (external link, opens in new tab) אבל הוא מחובר לאיזשהו סטייט איזשהו צריך איזשהו סטייט הוא יכול לכלול יותר מקלס אחד >> כן כן >> כן >> אוקיי שתיים בסדר יכול לכל יותר מפרויקט אחד התהליך הזה כןס מצוין אוקיי יש עוד איזשהו לבל יכול להיות מסיבt אחד לאסution אבל אסמלי

[22:52] (external link, opens in new tab) יכול להיות אוקיי ומה ש בהתחלה כשאת בהתחלה כשרק נתקלתי בכשרק התחלתי אתITטסדנ כשכתבתי את הספר הספר דרך אגב התחיל להקדל לפני שש שנים היום אני כותב גרסה חדשה שלו שמתקנת הרבה מהדברים שפעם חשבתי אז פעם חשבתי שיוני זה היחידה הכי קצת נשפות שיש ללוגיקה זאת אומרת פונקציה אבל יש פונקציות שאני לא רוצה לבדוק יש הרבה פעמים פונקציות שהם prייט שאני לא רוצה לבדוק כי אם אני בודק אותם אז באמת הרוכות שלי נהיה כמו בטון מחר אני משנה אותה אני עושה לה רפקטורי

[23:31] (external link, opens in new tab) ווכל הטestטים שלי נכשלים למרות שאולי בסוף הכל כות עושה את העבודה הנכונה אז התחלתי לחשוב מה זה אומר שאני יודע שמשהו בסוף עושה את העבודה הנכונה איך אתה יודע שמשהו בסוף עושה את העבודה הנכונה גם אם עשית ריפקטורים תוצאה חלפס >> תוצאה מה זה תוצאה איזה תוצאות יש הצלחה כישלון מה זה הצלחה כישלון הצלחה וכישלון זה משהו שאתה מחליט עוד קיבלת שלוש זה הצלחה או כישלון אוקיי אז איזה סוגי תוצאה יש לזה אני מתכוון

[24:04] (external link, opens in new tab) אוקיי אלה שציפים שלנו זה מבחינת הטestטים אבל איזה סוגי תוצאה יש בקוד >> exceptפtion exceptפtion אוקיי אז אם יש לנו איזשהו יוניט בואו נחליט מה היוט הזה עוד לא נחליט מה זה היוט הזה יכול לזרות exception מה עוד valגם return valtion זה אותו דבר זה גם ס מה עוד שהוא קרה למשהו שהוא קרה למשהו

[24:35] (external link, opens in new tab) אוקיי מה זה קרה למשהו לדוגמה לוגר או קלאס אחר אוקיי אדפט ומה עוד יש בדבס >> בדataביס ומה זה אומר מהו >> כן אבל הזה קרה i בסדר זה שינה משהו כן אבל מבחינת היוזר זה שינה משהו

[25:07] (external link, opens in new tab) אז עשיתי משהו בעיות זה שינה משהו זה יש איזשהי תוצאה זה יכול להשקיע תהליכים אחרים פה זה יכול להשקיע תהליכים אחרים זה אומר שזה שינה איזשהו סטייט זה לא סתם היה הסטייט של המערכת משתנה המערכת מתנהגת אחרת אלה שלוש שלושה סוגי התוצאה שיכולות להיות על זאת אומרת פעם כשהייתי כותב testים לprvateטפש ואז הטestים שלי היו נכשלים שנית prvate function ידעתי שהטס סטים שלי טועים בגלל שההרגשה שלי הייתה שהמערכת בסופו של דבר עושה את הדבר הנכון אבל לא ידעתי להגדיר מה זה הדבר הנכון הזה היום אני יודע קצת יותר טוב להגדיר מה זה הדבר הנכון מבחינתי unit

[25:45] (external link, opens in new tab) זה לא פונקציה unit זה unit of work (external link, opens in new tab) זה סוג של באמת תהליך אבל זה תהליך שמותחל על ידי המשתמש או מיוצג על ידי איזשהו משתמש ולכן זה חייב להתחיל בפאבליק זה משהו שאפשר לעשות לו אז יוניט מתחיל באיזשהו פאבק והוא נגמר באחת מהתוצאות האלה או שהוא מחזיר valו או ש או שהוא משנה סטייט במערכת ואז הוא הולכת מתנהגת אחרת או שהוא קורא לאיזשהו פטי משהו שהוא לא בשליטתנו לדוגמה לוגר שצוות אחר כתב לדוגמה

[26:22] (external link, opens in new tab) קוד בשרפנט שאני לא רוצה לגעת אחד אז יש לי התחלה סט ויש לי איזשהו סוף ואז כל הדברים שפה באמצע לא אכפת לי מהם בכלל לא אכפת לי אם זה פונקציה לא אכפת לי אם זה שלושה קלאסים לא אכפת לי אם זה 17 פרויקטים unit of work יכול להשתנה יכול להיות קטן כמו פונקציה יכול להיות גדול כמו כמה קלאסים

[26:53] (external link, opens in new tab) מבחינתנו ההגדרה של unit test אני יכול לכתוב testים לסקופ כשהוא קטן או לסקופ שהוא גדול. הרבה מההחלטות או הרבה מהאומנות שאני רואה בדבר הזה זה ההחלטה באיזה סקופ לכתוב את הטestטים. אבל אני לא אכתוב testingים לדברים שהם prיט כי מבחינתי כל דבר שהוא prיט הוא חלק מunitive work אחר. כל פונקציה שהיא prיבט אצלכם בקוד יש לה סיבה שהיא קיימת. זאת אומרת מישהו קורא לה. אם אף אחד לא קורה לה אפשר למחוק אותה. היא לא צריכה להיות שם. אז הסיבה היחידה שהיא קיימת זה בגלל שמישהו קורא להבסופו של דבר המישהו הזה מותחל על ידי משהו שהוא פאבליק.

[27:27] (external link, opens in new tab) לכל פונקציה קיים קיים לפחות סיבה אחת לפעמים היא יכול להות חלק ממile units of work שבגללה היא קיימת אז אני יכול למצוא דרך לבדוק את הפונקציה הזאת על ידי מציאת הUNIT of work הנכון והend resultלט הנכון ואז אני יודע שהכל בדרך עובד עכשיו זה הכוח האמיתי כשמדברים על מיity הרבה פעמים הבעיה של mainity קוראת בגלל שהטestים שלנו מגדירים יותר מדי מה צריך להיות פה בפנים אתה צריך לקרוא לפrivate fun הזאת ואתה צריך לקרוא ל קלאס הזה והקלאס הזה צריך לקבל שלושה פרמטרים ואתה קורא לביס קלאס שלך לא אכפת לי ככל שלא אכפת לי כמו שאני מתייחס לזה כסוג של הקופסה שחורה

[28:07] (external link, opens in new tab) ורק אני מתייחס לשלושה אדריז האלה אז הטestים שלי הם הרבה יותר maintainable (external link, opens in new tab) בגלל שאז אני יכול לשנות פה הכל זמן שהאנדריזל אותו דבר הצestסטים שלי עדיין ימשיכו לעבור והם לא יכסו עליי על זה שגידו משהו שלא אכפת שלא אמור להיות אכפת להם אלו הרבה מהמטility problem היום קורים בגלל שאנשים אנשים עושים מה שנקרא overפication. הם בודקים דברים ש הם לא אמורים לבדוק. ככל שאני חושב על זה היום, צריך להתחיל במשהו שהוא פאבליק ולהיגמר במשהו שהוא publicקly visible.

[28:38] (external link, opens in new tab) זאת אומרת משהו שהמשתמש יכול להרגיש. לדוגמה אם אני מכניס לדataביס אז עכשיו הלוגן שלי אמור להצליח, נכון? אני משתמש באותו API או בAPI אחר ועכשיו API אחר מתנהג אחרת. זה בסate change אבל או שאני מקבל value אחר או שאני מקבל אפtion אחר והטestטים הכי מסובכים זה הטestטים שקורים לרדd part אלה הטestטים אלה המקומות שבהם מתחילים להשתמש במק objects ובגדול כשמדברים על testים או על unit testים

[29:09] (external link, opens in new tab) אני רוצה לוודא שהטestטים שלי שולטים בIT בצורה מלאה זאת אומרת שאני שהכל א' אני יכול לגרום לו לרוץ כמה שיותר מהר בדרך כלל זה אומר לגרום להכל לקרות בזיכרון אם יש לי איזשהו IO אז צריך שתהיה לי שליטה עליו לדוגמה להחליף אותו באמצעות משהו כדי לעשות פה מה שנקרא כדי להחליף אותו שאני נוכל לקנות את הטסט אבל לפעמים האנדרי resultלט שלי היחיד הוא לא שינוי סטייט ולא החזרת אלא פשוט איזשהו קריה ללוגר איפשהו

[29:41] (external link, opens in new tab) נכון לפעמים צריך לקרוא ללוגר לפעמים צריך לעשות משהו שעושה לאנשו ואז המערכת השנייה כבר מטפלת במה קורה כשאתה מקבלטיפיקציות פה נמצא הנושא של הסד particני כשאני מחליט איפה הגבול בין המערכת שלי למערכת חיצונית בדרך כלל הגבול הזה עובר איפה שאין לך שליטה יותר זאת אומרת הקוד שלך לא יכול להחליט על ההתנהגות של המערכת או שזה נורא נורא מסובך להחליט אז אתה פשוט מחליף אותה באיזשהו מוקט משהו שנראה כמו מערכת החיצונית ואתה בודק שקריאה למשהו שנראה כמו מערכת החיצונית התקבלה

[30:14] (external link, opens in new tab) וזה הסוג השלישי של הטסטן שבדקת האינטראקציה בין מערכות שאלות. כן. >> במקרה של עבודה עם עם דatבי במקרה שלנו clוד זה אומר שיש צורך לעשות תשתית נוספת שהיא עושה מוק לקוד וובעצם רב הטestטים בכלל לא צריכים לגשת לדטה עצמו. >> בקלאוד. זה נושא מעניין כי כי זה מאוד תלוי כמה שכבות יש לך מעל.

[30:45] (external link, opens in new tab) אם אני מדבר על השכבות של אפליקציה הרבה פעמים בעיקר בעולם המייקרוסופט מדברים על זה שיש לך שלוש שלושה סוגי שכבות יש לך את הui יש לך את הBL ויש לך את הl ואז פה למטה יש איזשהו דabיס אוקיי בדרך כלל testים על UI לא שווה לי לעשות מבחינת הCOST versusס אעלות אות לא שווה לי בגלל שUI משתנה כל הזמן ואז הטestטים שלי כל הזמן צריך שנות פשוט אין דרך החוצה מזה כמעט אתה עושה testים על UI

[31:19] (external link, opens in new tab) BL בדרך כלל הביזנסיק או הביזר זה המקום שבו עושים את מרבית היוטי דהר בעצם השכבה שמדברת ישירות עם הדביס או אצלכם מבחינתכם זה ישירות עם הקלאוד יש לכם איזשהיא אסטרציה מעל הקלאד זה מה שאתם ראיתם עכשיו הרבה פעמים באפליקציות שבה אם יש דטביס סטנדרטי אני לא בודק את הדataל ואני עושה פייק (external link, opens in new tab) לדataביס בגלל שהרבה פעמים הדביס עצמו מחיל חלקים מהלוגיקה. זאת אומרת המבנה של הדatביס הרבה פעמים הוא סוג של לוגיקה.

[31:50] (external link, opens in new tab) טריגרים חלוקה בין טבלאות שהם כיעוד אחת בשנייה. פורנקי זה גם סוג של לוגיקה. ולכן גם אם הייתי בודק את הדבר הזה והייתי עושה לזה פייק אז זה שזה עובד לא אומר שהאפליקציה שלי עובדת. אוקיי? זאת אומרת חצי מהלוגיקה היכולות שנמצאת פה ואני לא בודק אותה בכלל. אז הרבה פעמים באפליקציות סטנדרטיות שיש דabס את הדatר עצמו אני לא כותב לו unit testing אני כותב לו integration testingation testing זה אומר שהunit of work שלי כולל את הדatabס

[32:21] (external link, opens in new tab) כולל את הדatab בגלל שאני רוצה לראות שלא רק שאני יכול שזה קורה לו עם הSQLים הנכונים גם לבדוק שמשהו נקרא עם הSQLים הנכונים או עם הQU הנכונים זה גם זה חתיכת mainity CRP אבל אם אני רוצה אבל אם אני באמת רוצה לבדוק את זה אני אני עושה דביס לטestינג ואני בודק כשהמבנה של הדטביס תומך בהכל שאני יכול לעשות אינסרטים ואפדייטים וכל הדברים האלה עכשיו במקרה של clוד אני לא בטוח אני צריך להסתכל על הכל כי cלא זה הכי דפארטי שיכול להיות אתה לא יכול באמת ליצור קלאוד פרטים משלך לוקחלי אצלך שרץ רק אצלך למחשב אתה טועה >> כן >> כן אני טועה או כן אתה יכול >> כן אתה טועה יש סימולציה של קלאד אצלך

[33:05] (external link, opens in new tab) >> אם זה סימולציה זה לא קלא דבר