Maintainability Practices

[00:10] (external link, opens in new tab) אוקיי, אנחנו עוברים עכשיו דיברנו קודם על היכולת לפתוח בטestטים, עכשיו נדבר על מטבabity של טestטים והרעיון הוא שטestטים הם צריכים להיות להחזיק מעמד הרבה זמן בעצם אחד הדברים הכי מבעסים בטסטים זה שהם הם מרגישים לפעמים כמו בטון מסביב לקוד שלנו ואז אנחנו מנסים לשנות משהו ואיזה טסט צועק עלינו אז אז עכשיו אנחנו נדבר על איך לעשות איך למזר את הנזק הזה ואחת הדרכים הכי בסיסיות זה לוודא שהיוט of work שלנו הוא באמת מתחיל באיזשהו משהו שהוא אטריפ point אמיתי משהו שמשתמש בדרך כלל מתחיל אותו והוא נגמר בend resultלט אמיתי

[00:46] (external link, opens in new tab) Resultלט זה להחזיר valtion לשנות state של המערכת ככה שההתנהגות של המערכת משתנת לא הסטייט הפנימי לא אכפת לנו מטמי התנהגות משתנת וקריאה לרד פארטי אם אנחנו בודחים כל דבר אחר בתוך המערכת אז בעצם אנחנו יוצרים דבר שנקרא over specification over specificקation זה בעצם מודל הפיקסה שאני הסברתי עליו פעם קודמת שבו אכפת לי יותר מאיך דברים נעשו מאשר האם בסוף אני מקבל את התוצאה הנכונה עכשיו יש המון המון פחד

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

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

[02:27] (external link, opens in new tab) ולכן הIT of work שלנו צריך להיות באמת באמת לוודא שכל מה שבפנים מבחינת הוIT test שלנו הוא קופסה שחורה לא לבדוק את האפלמנש יש מקרים שבהם אין ברירה בעיקר בלגסי קוד יש לנו מעט מאוד ברירות של האם לשנות את הקוד או לא ואז אנחנו נכנסים לדברים שניכנס אליהם היום שבהם כן צריך לבדוק קריאות לפרד partטties אפילו שהם לעשות בצורה פנימית או לעשות פייקים (external link, opens in new tab) לדברים אה למרות שכביכול הקוד לIT שלנו הוא לא אמור להיות אכפת מה אנחנו ניכנס לזה

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

[03:36] (external link, opens in new tab) ושזה מראה איזשהו מסג' למשתמש לכל השלושה האלה לא הייתי כל פעם עושה שלוש קריות לקוליטור בכל אחד מהטestטים אלא הייתי עושה איזשהוט invalid או to invalid או trial state ושם הייתי אומר יש לי שלוש קריות לקוטר שלי והסיבה היא שברגע שמשהו שהוא מוגדר כפיצ'ר פיצ'ר היוםטל מוגדר כשלוש קריאות מחר הפיצ'ר שלטל מוגדר כ-15 קריאות אז אני משנה את זה רק במקום אחד

[04:08] (external link, opens in new tab) במs test או איפה שאין test cases אז פונקציה של verifיפי שיש בה משהו שעושה זאת אומרתct method לסרטים מבחינת maabity אחד הדברים הכי בעייתיים זה כשטestטים תלויים אחד בשני הרבה פעמים זה לא בכוונה בכוונה זה דבר אחד ונורא קשה כשזה בכוונה שהמשתמש של הטestטים יבין שמשהו קשור אחד לשני

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

[05:15] (external link, opens in new tab) אז במקום זה פשוט עושים אסטרctוד לחלק של הrange וקוראים לו בשני הטestטים זה נשמע פה commonסנס אבל זה מאוד פשוט לאנשים ליפול לבור הזה ולכן בtest reviews צריך לבדוק את הדברים האלה מאוד מאוד לעומק. זאת אומרת צריך להיות לכם יכולת להריץ את כל הטestטים בכל סדר כלשהו. אני אגיד לכם עכשיו בבירור, כל הטestו כולל MSTest מלבד במאוד מסוים לא מבטיחים לכם מה יהיה הסדר שבו הטestטים ירוזים. היום הם מריצות את זה בסדר מסוים מחר הפלמנטשטל יכול להשתנות אתם לא יכולים לסמוך על הסדר שבו טסים רצית

[05:50] (external link, opens in new tab) אחרת צריסה חדשה ואם יר אותו בסדר קצת אחר בגלל אופטימיזציה למי אכפת זה דווקא דבר טוב זה אומר שאם אנחנו לא יכולים לסמוך על זה אנחנו לא יכולים לסמוך שמשהו כבר קרה דרך אגב עוד אחת סיבה שבנטגרration tests הסדר מאוד משנה הרבה פעמים אנחנו מצפים שמשהו יהיה בדataבי שנוכל לעשות delate וכולי אבל גם באינטגרש test הנושא שאפשר להריץ כל test בכל סדר הוא מאוד חשוב בגלל שהמיט שלהם הוא הרבה יותר מסוכך.

[06:24] (external link, opens in new tab) נחזור חזרה לנו של multiטפל assרוצהity אז אני רוצה שתהיה לי את היכולת לראות כל תוצאה שנכשלה בנפרד. אז אם יש לי multפile as על test על אותו אובייקט אין לי שום בעיה אבל mtפle as על אובייקט אחד על אובייקט אחר שני ריזלטים אחרים מבחינתי אז אני אפריד אותם לטestטים שונים כמובן שגם זאת בעיה

[06:55] (external link, opens in new tab) זה גם mvc אני אסביר מה קורה פה כל הדבר שאתם רואים פה שנגמר במערך הזה זה בעצם מערך של anonymous objects. כל אחד מהמס יש לו שני properties. Parameter ששימו לב לכולם אותו פרamמטר וtion שהוא בעצם delגate שמפעיל overload של פונקציה שנקראת link. כל אחד מהדלגט האלה מפעיל אload נפרד בעצם פונקציה אחרת שללינק. בסדר? אז יש לנו את המערך הזה

[07:28] (external link, opens in new tab) ואז יש לנו פה לולאה שעוברת על כל אחד מהמערכים האלה ו עושה expect argument exception nempy זאת אומרת אין זה כתוב ב-MSTest אז אין הסם כתבו help משלהם שאלה האם הם מצפים שהargument exception הוא naly או שהם מקבלים argument exception of nty

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

[08:38] (external link, opens in new tab) הלולאה הזאת בעצם עוברת על כל אחד מהדברים האלה ובעצם קוראת לכל אחת מהאוברלדים ומצפה לgument exception. הוא לא argument יותר נכון. Argument בסדר? אז מה הבעיה? כמה שרים >> אני בודק פה מטפלס אם מחר האוברלוד הזה נכשל אז כל האוברלודים האלה בכלל לא נבדקים בסדר זה אומר מבחינתי ברגע שזה אוברלודים כל אחד מהם הוא פונקציה נפרדת

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

[09:56] (external link, opens in new tab) מלכתחילה, אם היה לי טest לכל אוברו של הפונקציה, צריך להיות טס לכל אווד של הפונקציה, אז הייתי יודע בדיוק שמתוך 15 אוברלודים שלושה לא עובדים וכל השר כן עובדים או 15 אוברלודים לא עובדים. בהתאם לזה יכול להיות שאני מסתכל בבק במקום אחר לגמרי. אוקיי? ולכן הבעיה הזאת שיש לי פה mטיפל as באותו test ואז אני מחביא מעצמי מידע שאלות

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

[11:02] (external link, opens in new tab) והרעיון הוא שהוא מסתכל על כל דבר אבל הוא לא הוא לא יכול לעבוד עם הוא רואה multטפle asest ובעצם הוא מסתכל על זה והוא הופך את זה למטפל test לtest percers אוקיי >> אוקיי אוקיי ואז עם הסרט אחד נכשל אתה רואה את האחרים וזה לא יעבוד על דבר כזה >> כן במקרה >> אוקיי שיטה אחרת כאילו לגמרי שיצר >> לא לא אין היום פתרו >> זה נראה לי לפתור ש >> נכון נכון שזה מעניין ששימו לב שאחת הסיבות היחידות שיש לי בעיה עם מטיפל זה בגלל שזה מחביא מידע לא בגלל שזה רעיון כזה גרוע זה יכול להיות אולי לברוא ברדביליטי אבל אפשר לעשות את זה לא חשוב הבעיה הכי גדולה זה שאם הסרט של זורק אקספtion ככה זה בכל הטestי

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

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

[13:22] (external link, opens in new tab) >> אז מה ההגבלה למורכבות של unit test (external link, opens in new tab) אז היה לך unit testabity maabity וט כל מה שיש לי את השלושה האלה וואלה אין לי שום בעיה >> השלושה הלה יכולים להיות גם עם מולטיפלי זה לא הסטר זה מספיר מד >> אם אפשר היה לעשות את הכליגרש test וזה היה רק מסתיק לפני הייתי עושה הכל כאנטגרש test זה היה פשוט תן לך בשנתיים האחרונות שאני יורד בעולם הרובי ורובי הרבה יותר נפוץ לעשות test מאשר unit test פשוט by default רוב הטestטים שאתה מריץ נגיד נגד rובי ril הם testים שמשתמשים בדataביס

[13:53] (external link, opens in new tab) אז מלכתחילה כל הIT testים ברובי הםation tests אז הם לוקחים יותר זמן אבל זה הדפולט אז התחלתי לכתוב הרבה acceptance test עםספק ולהריץ את האתר דרך הדברים האלה וראיתי וואלה אפשר היום להריץ headless כולל ג'ס כולל הכל את כל הטestטים את כל הקוד לבדוק בינגרation testcancest שהם דווקא מאוד קריים אם הייתי יכול לבדוק רק את הפיצ'רים של הדבר הזה unit testing זה לא כזה לא הייתי לא הייתי ננע מזה אבל יש עם זה כרגע בעיות המהירות שאני מקבל את הפיטק היא מאוד איתית וזה לכן יש תנועה שלמה של אנשים בעולם הרו שבה ואומרת זה לא מספיק טוב שאנחנו בעיקר עושים testing בואו נתחיל לדבר על unit testing להפריד מהדפיס דברים שבעולם הדנט אנחנו מדברים עליהם כבר יחסית הרבה זמן בעולם הרובי רק בשנה שנתיים האחרונות אנשים מתחילים לדבר עליהם למרות שזה תרבות שיש בה המון המון ניסיון בטestינג, רוב הניסיון בכלל בא מעולם האנטגרשט testing.

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

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

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

[16:37] (external link, opens in new tab) מה לא הבנתי execute with a syringer action compete suc ‏suf זה מאוד sucess מה אנשים אומרים מתכוונים כשהם אומרים compete successfully >> לא נזרק אפtion זה בדרך כלל מה שהם מתכוונים עוסקים איתך אז הייתי משנה את זה לדes not ווואלה הייתי שם פה את הנדרסורם כי יותר קל לי לקרוא אבל עוד פעם אנדרסקורים זה איזשהו סטייל שבהתחלה נורא עוזר אבל רוב האנשים לא כותבים אדרסקורים הם

[17:09] (external link, opens in new tab) לא בגלל שזה לא דבר דבר טוב אל בגלל שרוב האנשים לא מבינים כמה שזה דבר נחמד כשיש את האנדרסקורים האלה את השניים האלה ואז הם כותבים טestטים כאלה ואף אחד לא יכול לקרוא הם יכולים לקרוא אותם אבל אם הם לא דוברי אנגלית נייטיב שעוברים את השיניים אוקיי אז מה היה מה הבעיה בטest הזה מה הבעיה שאני מנסה להראות היא בכלל פה למטה זה משתמש במוק Moq (external link, opens in new tab) ואני רואה פה שני verifיפי זאת אומרת מלכתחילה יש פה בעיה זה בכלל לא משנה מה הטest הזה בודק שני verifיפי אם אתם זוכרים verify זה אומר שיש לי obק אז יש לי פה שני obקט ובtest אמור להיות לי בדרך כלל מוק object

[17:53] (external link, opens in new tab) למה זה בעיה שיש לי שני מobקט בטest בודק שתי דברים >> מה אתה בודק שתי דברים אני בודק שני דברים ומה הבעיה עם זה מחשב שניה >> כן זה מלטפל מבחינתנו זה מטיפל אסרט זה על שני אובייקטים שונים אם הוריפיי הזה נכשל הוריפיי הזה זה לעולם לא יעבור אבל יש פה בעיה יותר מעניינת האם בכלל אני צריך פה שני objects למה יש פה שני מobטs אני מסתכל על השמות שלהם ואני אומר וואלה רוב הסיכויים שאחד מהם בכלל לא צריך להיות מט temד data provיידר

[18:25] (external link, opens in new tab) Data provיידר רק מהשם שלו אני מבין שכל מה שהדבר הזה אמור לעשות זה לתת מידע לתוך האפליקציה שלי ובדרך כלל ההבדל בין מוקים לסטאבים (external link, opens in new tab) זה הפow הכיוון שבו האינפורמש זורם סטאבים נותנים ים מידע לתוך האפליקציה ומק objects בודקים מידע שיוצא מתוך האפליקציה החוצה דata prviידר בדרך כלל אומר לי תדמה איזשהו מידע לתוך האפליקציה עכשיו מהידע הקודם שלי אני יודע שבדרך כלל

[18:57] (external link, opens in new tab) אנשים שכתבו שהתחילו לכתוב טestטים לפני יותר משנתיים הם רגילים למוד אחר של עבודה עם אוקצ רגילים לתרבות שבה אתה עושה וריפיי לכל דבר שאתה יכול לעשות לו וריפיי בגלל שאתה יכול לא בגלל שזה רעיון טוב זה בגלל שככה לימדו אותם בגלל שככה גם לימדו אותי מ לימד אותי אפילו לא זוכר זה פשוט היה איך איפה שהוא בתרבות אני זוכר שנכנסתי והתחלתי לכתוב את הטסטים הראשונים שהיה להם objects וראיתי בד verify all expectations בד בכלל לא קשור לשום test היה לי מג שמותח בסטאפ לא היה קשור לשום test וכל הטestטים שהשתמשו בו גם היה להםיפי אחי זאת אומרת by defaultט בידתי את כל הדברים ולא ידעתי אם זה דבר טוב או לא היום אני יודע שזה דבר מאוד בעייתי מבחינת המטנבity

[19:48] (external link, opens in new tab) אז בינתן שתי הידיעות האלה אני אומר הוא על רוב הסיכויים שהדבר הזה בכלל לא צריך להיות פה והסיבה היחידה שזה פה זה בגלל שיהיה איזשהיא קונבנציה בגלל שלא יודעים שזה יכול לפגוע במטנabity של הטest אם הייתי יכול להסתכל על השם של הטest ולהבין מה הected behavour אז הייתי גם יכול להגיד איזה מה הוא בטוח צריך להיות גם הבעיה היא שפה הect ב הוא שהוא שום דבר לא זור exception אין פה שום expected behav שאומר שמשהו צריך להתרב

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

[20:51] (external link, opens in new tab) תשימו לב גם שלכל דבר פה קוראים מוק למרות שהרבה פעמים חלק מהדברים הם סטב מוקטם tata provider expectect במקום mq הישן זה הסetאפ החדש זאת אומרת קריאה ‏low temp data ותחזיר new dictiontionary של string ותשימו לב verifiable verifiable verifiable זוכרים את verifiable evil זכאני עושה verify

[21:23] (external link, opens in new tab) אני בודק גם שהפונקציה הזאת נקראת וגם שהפונקציה הזאת נקראת ותשימו לב atm זה משהו שיכול להיות מאוד מסוכן save temp data אמור להיקרה מקסימום פעם אחת. עכשיו בדרך כלל לא הייתי בודק דבר כזה. הסיבה היחידה שהייתי בודק אם מה שהוא נקרא רק פעם אחת זה אם זה באג לקרוא לזה יותר מפעם אחת.

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

[22:25] (external link, opens in new tab) האנדריז הוא עדיין אותו דבר. אז אני לא רוצה להכריח את הקוד שלי את הקוד שלי לעבוד בצורה מסוימת אם אני לא חייב. אוקיי? ולכן יש פה המון דברים שהייתי יושב עם הבן אדם הייתי אומר האם באמת צריך פה את המוקט הזה? האם הדבר הזה הוא לא בכלל סטב הייתי עושה לונame והוא מוציא את הוריפי מפה האם זה צריך להיות שני testים אחד שאתה קורא לזה ואין אספtion ונתן exceptפtion

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

[23:30] (external link, opens in new tab) יש לי does not thr אם אני באמת רוצה לעשות את זה >> בכל מקרה גם האפש >> מסכים איתך אני בכלל לא משתמש באסט אני פשוט כותב בשם של הטtion בסדר ואז אין לי שוםט אבל השם של הטסט אומר לי למה אין לי שום אסרט ואז אני עושה רביו ואני מבין עוד שאלות אוקיי זה מבחינת maintainability (external link, opens in new tab) בואו נדבר על readability (external link, opens in new tab) structure solution שהוא קריסution

[24:01] (external link, opens in new tab) שבו אתה יכול למצוא כל דבר ואת הדברים שמתאימים לו אז קודם כל יכול להיות שיש לכם איזשהו convention איזשהו פולדר שתחתו תחתף שמים את כל הטestטים כל הtest proקטס מתחילים במילה test או נגמרים במילה טסט אבל יש איזשהו קונבנציה זה חשוב מאוד גם בגלל הסדר וגם בגלל שמישהו שנכנס יש לו איזה מישהו שנכנס לצוות יש לו איך להמשיך הוא לא צריך לנחש את הדרך שלו אוקיי דרך אגב אנשים שנכנסים לצוות שכבר כותב בTD הרבה יותר קל להם להתחיל לכתוב בTD בגלל שבדרך הם נכנסים

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

[25:16] (external link, opens in new tab) ועוד פעם אני מחפש פה תשימו לב זה לוity שזה פרט toen source של מיקרוסופט שימו לב שאין לי פה את המילה integraation tests אבל בדרך כלל אני יכול לנחש interception configuration רוב הסיכויים שזה שם יש לי כל מיני configuration files וכולי הייתי משנה את השם הזה שם של הtest לפחות אבל אין לי פה את ההפרדה בין unity inration test מה שאומר שרוב הסיכויים שיש לי פה מיקס אם הייתי מריץ את כל הטestטים ושניים היו נכשלים. צריך לבדוק טוב מאוד אם השניים האלה זהרation test או לא. ואם כן הייתי שם אותם בפרויקט נפרד כדי לוודא את זה.

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

[26:19] (external link, opens in new tab) >> מה אני יודע שאתה בודק את זה אבל מה אמור לקרות זה מה שנקרא what the fuck test. אוקיי, הסיבה שזה what theפק test בגלל שלא רק שהשם גרוע, העשרט בכלל לא קשור לשום דבר. שש >> שש. מאיפה שש הגיע? לא שש. >> שש זה חשוב אולי זה לא חשוב? >> לא רואים את זה ב >> איך ידעת שזה יהיה שש?

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

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

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

[28:31] (external link, opens in new tab) על מה אני אעשה לבדוק שרג'יסטר באמת עובד שאני מקבל משהו לא חשבו על שום דבר אומר אה בוא נבדוק בוא נבדוק את הפסורד אז תח את הפסורד אז פתחו את הפסורד במקום זה אפשר לבדוק שהVW resultלט שקיבלת זה רגסטרw זל אפשר לבדוק שזה לפחות is not אבל הדברים הכי בסיסיים פה בעצם הם אומרים קיבלת את הדברים שאני שטלתי ככה שאני יודע שבאמת השתמשת באובייקטים שלי אז לפחות פה הייתי עושה פה איזשהו consס שאומר

[29:02] (external link, opens in new tab) Fake (external link, opens in new tab) viwד data מינימוםפורד לנפס או משהו בסגנון הזה כדי שהייתי יודע מאיפה השש הזה מגיע עוד דברים חשובים אם כבר מדברים על דברים שהם הרדקורד ד או לוגיקה הנה הדבר הזה אני קורא לו hן prוקocוקol hen prוקocוקol אומר שאיפהשהו בטestינג באינפסטרקט יש לך איזשהו פרוטוקול שאם היית יודע אותו הייתי יכול לקבל המון המון ערך ממנו פה אתה רוצה ליצור user במership של ASP.NET

[29:36] (external link, opens in new tab) אז אז בעיקרון בfake mership provider אם אתה שולח לו usernר name שסuse לפורד שהוא goodפס והאמייל הוא אימייל אז אתה תקבל שהממברשיפ הצליח אתה צריך לדעת את זה זה לא נמצא בשום מקום אבל בוא נניח שאתה רוצה לדמות שהממברשיפ לא הצליח זה פשוט מאוד

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

[30:43] (external link, opens in new tab) תחשבו שהוא מייצר יוזר והוא אומר זה אותו עם יוזר אחר לא ממברשיפ לא הצליח אז אף פעם לא לעשות את הדברים האלה בלי איזשהו פרוטוקול שהוא public constני יכול להתייחס אליו מבחוץ אם eסם נקודה fake membersh provider נקפת good image להוציא את הדברים האלה לקנס כדי שבטest שלי אני אראה מאיפה הסטרימים האלה מגיעים

[31:20] (external link, opens in new tab) עוד דברים שקורים הרבה שכל דבר קוראים לו מוק אבל מה שאני מבקש זה שכשמייצרים דברים שיורשים מדברים אחרים תקראו להם פיק כי הרבה פעמים אתם לא יודעים איך תשתמשו בהם אז זה מוק princiפle אבל בעצם הייתי קורא לזה fake principleפle לגביing לא נדבר יותר מדי עוד דבר שהייתי עושה זה הייתי מפריד את הארט מהact זה דבר מאוד חשוב בגלל שאחרת הסרט שלי יכול להיות מאוד מאוד ארוך ואני מעדיף שהוא יהיה יופרד לשתי שורות ואז אני יכול גם לעשות דברים עם המסג או לדוגמה אקספש או דברים כאלה

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

[32:30] (external link, opens in new tab) היום אם אנחנו משתמשים בפריורקים החדשים כולל tyמוס ומק גם לדעתי FakeItEasy (external link, opens in new tab) וסבסט הם עושים מה שנקרא recury face אז בעינתן שאפשר לעשות over או משהוטי אוטלי או פנקציה וירטואלית היא מחזירה משהו שהוא לא value אלאקט אז האובייקט הזה by defaultט יהיה fake לא צריך להגיד לו שזה יחזיר אז אם אני אעשה fake substitute for substitute for i principle נקודה identiity

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

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

[34:14] (external link, opens in new tab) אם אתה לא יכול אז משהוז תעשה את זה שזה שזה יהיה ברור יקרים בסדר עוד שאלות לגבי input values גם readability אז שימו לב אני אוהב input value שהם לא אותו דבר גם בגלל שלפעמים החדר משנה אבל גם בגלל שאני אוהב שאני רואה איזשהו פאטרן אנחנו מתוכנתים לזהות פאטרנים גם בעיניים שלנו ואני אוהב במיוחד