Mocks and Stubs

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

[00:32] (external link, opens in new tab) אבל אבל סטי זה לא תמיד דיזיין גרוע אז לא תמיד זה שהדיזיין הוא לא testable אומר שהדיזיין גרוע אבל הרבה פעמים זה שמשהו לא testable זה לא כזה דבר רע לעשות אותו testable זאת אומרת אין פה איזשהו גיידליין אחד קשוח וסטנדרטי אבל כאיזשהו משהו שתמיד יהיה בראש עדיף לי שהent שלי יהיה פאבלי ואם אני עושה את זה בtd מן הסתם הוא יהיה פבליק אני לא צריך לחשוב על זה יותר מדי. תחשבו שיש לכם פונקציה שהיא publicליק ואז אני עושה ל15 prvטate methods.

[01:04] (external link, opens in new tab) אז מה אם יש לי 15 prvט meods? אני בודק רק את הפאבליק והוא כבר מכסה את הפרrivateסs נכון? אז זה מבחינת הדבר הזה אני מקווה שאני איתי ואם יש שאלות אז פשוט תשאלו compפי time זה קשור לקונפיגורציה הרבה פעמים או לעשות סלושן יותר קטן או בסution יש לך solution configuration יש לדבגס אפשר לעשות גם test configuration שלא בהכרח מקמפל את כל הפרויקטים רק משאיר את הבינריies האחרונים ואז כל הבילד לוקח הרבה פחות זמן זאת אומרת כל אחד יכול לעשות אצלו קונפיגורציה שמתאימה לסוג העבודה שלו אם אם אני רק עובד על מודול מסוים וכל האחרים לא הולכים להשתנות מבחינתי אז אני יכול לעשות קונפיגורציה בסולושן

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

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

[02:57] (external link, opens in new tab) אז אתמול התחלתם את הקלקulator קט ואז בניתם לו סוג של UI איזה consolול אפליקש ועשינו את הדבר הראשון שמתחיל להתקשר להיום שזה החלפנו את האoutטפוט של הקונסול במשהו ש שבשליטתנו רגע אתם רוצה לעשות חמש דקות הפסקה שפה נראים גוי אוקיי בסדר היום אנחנו נדבר על די הרבה דברים קודם כל נדבר על נושא של מobקס וסטא אחרי זה ניכנס לisolation frameworks ולמה אני לא קורא להם frameworks למרות שכולם קוראים להם framework נסתכל על אלה ועל עוד כמה

[03:36] (external link, opens in new tab) ונדבר על מה כדאי ולא כדאי לעשות כשיש objects test קודם כל הכי לא כדאי זה שיהיה לכם object בוא נתחיל עם זה אם אתם כבר חייבים object כי הend resultלט היחיד שלכם זה third partט לאיזהגר או לאיזה סטורג או מה שזה לא יהיה ונורא קשה לעשות לזה פיק נורא קשה לעשות לזה אז משתמשים במקס מרגשה לשתות אז בואו ניקח מקרה יחסית סטנדרטי או מקרה פחות סטנדרטי ממה שראינו אתמול יש לי קלאס שנקרא logג maner

[04:09] (external link, opens in new tab) יש לו איזשהו deפנendency הוא משתמש בלוגoger שהוא מקבל בקונסטרקטור עכשיו הדרישה שלי היא שכשאני קורא לפונקציה save ושולח לאיזשהו אובייקט אם האובייקט מכיר איזשהם propפרerטies מסוימים נגיד שהוא גדול מאיזשהו ביס מסוים אז אני שומר ללוגר את את איזשהו מידע סך הכל אדנ הכי פשוט הפונקציה save לא מחזירה resultלט זאת אומרת זה לא value test אני לא יכול לעשות פה state p test אלא אם כן אני משתמש באיזשהו פייל syסטם זאת אומרת אני יכול לעשות פהסate testing אם אני מייצר לogגן maner שולח את הלוגoger מוודא שהוא מקונפג לשמור לאיזשהו פייל לוקלי

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

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

[05:56] (external link, opens in new tab) לדוגמה הייתי רוצה לדמות שהלוגר יש לו התנהגות מסוימת. אני רוצה לדמות מה קורה אם אני לא מצליח לכתוב משהו ללוגפ נכון? תמיד יש לי את ההתנהגות הזאת. מה קורה כשאתה לא יכול לעשות משהו? אבל יכול להיות המון סיבות לעשות משהו כמו שדיברנו על הסטורג out of space out of memory וכולי וכולי. אז כדי להחליף את הלוגר יש כל מיני דרכים שאני יכול לעשות את זה. אני אזכיר לכם הIT of work שלי עכשיו הוא לא רקס אלא הוא save פלוס הקריאה ללוגoger זאת אומרת החץ הזה אבל loogגר הוא לא חלק מהunity of work שלי כי אם הייתי עושה אותו חלק מהunity of work אז הטestטים שלי יהיו יותר מסובכים או לוקחים יותר זמן אני רוצה שזה יהיה unit test (external link, opens in new tab) הכל צריך להיות בשליטתי

[06:45] (external link, opens in new tab) אז בישרפ יש כמה דרכים להחליף משהו אני יכול או לרשת ממנו או לממש איזשהו אינטרפייס אז אני יוצר במקרה הזה אינטרפייס חדש למערכת יש הרבה דרכים לעשות את את מה שאני הולך לעשות עכשיו. זאת אחת הדרכים הפשוטות ביותר והבטוחות ביותר. אז אני מוסיף אינטרפי חדש למערכת שלא היה שם קודם. אני בעצם משנה את הדיזיין של המערכת ואומר שבנתן לogגר כלשהו שנראה כמו loger אני שולח אותו לקונסטראקטור ואז לogגן מנג'ר לא יודע מה זה לוגoger יותר.

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

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

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

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

[09:25] (external link, opens in new tab) בהתאם לאיך שאתה משתמש בו זה או מוק אוסט אדברים שאני התקנתי פה ושאני אשמח שאתם גם תתקנו ותנסו התקנתי את הדבר הזה שנקרא NCrunch

[09:56] (external link, opens in new tab) NCrunch זה בעצם מה שנותן לי פה את השמאלים הירוקים האלה שאתם רואים זה אומר שלכל שורה בקוד וגם בפרודקש קוד אני רואה אם השורה הזאת עוברת כרגע או לא אז אני אתן לכם דוגמה הקלאס שאני הולך צריך לבדוק עכשיו הוא login manager with אוקיי זה הURL הזה כבר לא נכון אבל אל תנסו אותו אקראנ עצמו אפשר להוריד אותו מ ncrunch.net

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

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

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

[12:11] (external link, opens in new tab) הסיבה היא שאם אני אם אין לי הרבה טestט קלאס שמשתמשים באותו פייק אין לי שום סיבה להוציא את זה לקובץ נפרד. אני לא רוצה שמישהו שקורא את הטestטים שלי יצטרך להסתכל בכמה קבצים כדי להבין את מה שקורה. עוד פעם בטestי מהנושא של רדility החוקים הם שונים לגמרי עם prodctiontion cod. Productiontion cod בדרך כלל הייתי מפריד אבל בטestטים שלי המטרה היא שזה יקרה כמה שיותר כמו איזשהו סוג של manual שהכל נמצא בפנים. אז יש לי פה את הtest הראשון. ‏is login OK when login okay calls loger עכשיו המילה calls היא חשובה זה לא rights to loger calls loger אומר לי שיש קריאה לאobייקט

[12:48] (external link, opens in new tab) זה אומר לי שאני יכול לצפות שיהיה לי פה איזשהו מוק object אז קודם כל אני מייצר את הפייקoger אבל אני קורא לו בתור משתנה אני קורא לו קoger עכשיו הסיבה ש הדבר הזה הוא מobקט זה בגלל שהוא באמת משהו שנראה כמו אובייקט אחר אבל אני עושה עליו הסרט בסוף המוקגר עצמו אני לא עושה שום דבר מלבד לקחת את הטקסט שנשלח לפונקציה של right שאני אעשה להר ולשמור אותו באיזשהו פבליק fieldס string

[13:26] (external link, opens in new tab) אז אתם רואים שפה האסרט שלי הכחול פה משתמש בשדה הזה גם קונטרול שיפט f7 אם רשרת פשוט מסמן את כל הages כאשר אדום זה יצירה וכחול זה שימוש אז בעצם מה שאני עושה זה אני מייצר את הפייק לoger מהתחלת לogin manג ע עם המק logger שלי קורה לad user כדי שי את הuser הזה ועושה add is login ואז בסוף אני עושה string assert content על המקטt

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

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

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

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

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

[16:47] (external link, opens in new tab) אז אם קודם היה לי dependency אחד עכשיו יש לי שני dependencies אז אני מייצר שני אינטרפייסים במערכת i loger וi webסice ואני מייצר שני fake (external link, opens in new tab) objects במערכת fake loger אולי כבר יש לי ממקודם כן ואת הפייק וובסרביס אני מייצר עכשיו עכשיו בייקובסרס אני עוד פעם אני מממש אותו בצורה הכי הכי פשטנית ש יכולה להיות אפילו בלי propפרeries בו סרביס אני עושה over לפונקציה של הובסרביס שאמורה לקבל את המידע

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

[18:00] (external link, opens in new tab) מבחינת זוכרים שאמרנו לשלושה סוגי result שיש לקוד לunit work פה ללגog manager לס יש לו כבר שני results resultלט אח זה קריאה ללגר יש לנו test לזה resultלט שני זה קריאה לו ועכשיו אנחנו חושבים test לזה זה אומר שבאחד מהם הלוגר הוא מוקצ'נט שנייה הובסרסט אין שום סיבה שפה שניהם יהיו מוקצ'נקט שיהיה לי שני הסרטים על אחד על כל אחד מהם א' בגלל שזה אומר שאני בודק פה שני דברים ואם פתאום מקריעה לזה תיקשה של אני לא יודע אם אני קורא לוובסרביס

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

[19:03] (external link, opens in new tab) הייתי מוסיף את הקוד החדש לפייקלוגר הקיים אבל לצורך השלטנות של הדבר הזה יצרתי את זה פשוט מראש אז קראתי לו פייקור ש אני עדיין שומר את המידע כמו ששמרתי קודם אבל יש לי עכשיו גם איזשהו fieldד מסוג exception שנקרא will throw ה throw זה פשוט כדי שהtest סט שלי כר נחמד וכל הבדיקה שלי זה אם הול שלי הוא לאנט אז תזרוק את מה שיש בו אין פה hardדקד את הסוג של האפtion אין פה hardcודed את המage שום דבר הטest הוא זה שקובע מהזרק

[19:42] (external link, opens in new tab) זה חשוב מאוד כי אם יש לי פה דברים שהם hardcודד אז אני לא יכול לעשות ריז לפייק הזה בטסטים אחרים אחר כך וגם הטestט שלי יהיה לא קרי אני לא מבין לא אבין למה האקספtion הזה נזרק עם המסג הזה אני צריך להסתכל בשני מקומות אז עכשיו הטסט שלי נראה ככה קריט תיצור את הפיק log אבל אני קורא לו stoger הפעם stablog will throw new logoer exception עם המessage הזה אתם רואים שעכשיו זה נראה קצת כמו סוג של משפט בגלל זה נתתי לזה את השם הזה

[20:14] (external link, opens in new tab) אני יוצר את הפיק weובסרס ולא אני קורא מוקסice פה אני משנה פה את השמות כי כ מי שקורא את הטestט אני בדרך כלל אחפש טestטים ואני אוודא שיש רק מוק או obקט אחד אני אראה שיש שני מקוםצ'ט זה אומר שאני בודק יותר מדבר אחד בטס ומה הבעיה עם זה שאני בודק יותר מדבר אחד בטח למה הוא נחשב >> מה לא אני יכול לדעת למה הוא נחשב >> מה נחשב >> אני יכול לדעת מה נכשל אני יכול לראות שבש >> מה קרה עם השני >> אני לא ידע מה קרה עם מה שקרה אחרי זאת הבעיה שלי אז יהיה לי פחות מידע בסוף אני קורא לזגן אוקי אבל אני פה אני מתחיל את הlogin manager with and st בעצם זאת הגרסה של הלogin maner אחרי שהייתי משנה את הדיזיין, עכשיו הוא מקבל שני אינטרפייסים בקונסטרקטור

[21:01] (external link, opens in new tab) ואולי אתם מתחילים לשאול את עצמכם אוקיי הקונסטור הזה מתחיל להראות קצת מעצבן עכשיו ובאמת בהרבה מערכות כאלה הרבה פעמים יש המון dependencies conסטרctטורים חמישה depפencies ואז יש המון סוגים של רפקטורים שאפשר לעשות ויש גם כל מיני כלים שעוזרים להקל על העבודה במקרה כזה אמ אבל תכף ניכנס לזה אני רק רוצה לראות את הדמו עד הסוף. אז עכשיו הקוד שהייתי אמור לכתוב הוא לא אבל עם try וcch ואז קרא לובסרס

[21:36] (external link, opens in new tab) לתוך הקטch. בעצם זה המטרה שלי עדה עם הלoger exception תקרא לובסice בסדר והקוד שלי עוד פעם אני מאתחל את ה login manager with m and stub (external link, opens in new tab) כמובן בפucion קוד אני המילים st לא יופיעו זה רק לצורי דמו אני שולח לו את הסבog ואת המקובסice קורא login אוקי אבל הארט שלי הוא על המקסage

[22:06] (external link, opens in new tab) המage הזה נמצא פה ‏Fובice אתם רואים שהפייקוב סרביס עוד פעם הוא פשוט עד כדי איכוך ככל שהדבר הזה יותר פשוט יותר טוב לי כי הדברים האלה הולכים לחיות עכשיו 15 10 שנים אם יש לי פה לוגיקה הסיכוי שיהיה פה באג שואף לאחד לאורך זמן בסדר אז אני רוצה שתהיה לי פה כמה שפחות לאר זה הלוגיקה הכי מסובכת שאני מוכן שתהיה לי אי פעם בקלאסים שהם פייק שהם handרי ככל שיש לי יותר לוגי הסיכוי שיש בה ב באג יותר גבוה ואתם יודעים הטest שאתם חושבים שהוא עובר אבל זה בגלל באג בפייקים שלכם זה דברים שלוקח הרבה זמן למצוא אף אחד לא מחפש את הבאגים של

[22:46] (external link, opens in new tab) ושם דרך אגב TDD (external link, opens in new tab) בורד עוזר לוודא שהטest שלך נכון אבל הבעיה האמיתית היא שגיל שאתה הטestטים נכשלים ואז עוברים אבל אז 100 טestטים אחרי זה אתה מגלה שיש לך בעפייק שעוד 50 טestטים משתמשים בו עכשיו אתה משנה את זה ו-50 טestטים נכשלים לך בגיל ת שבעצם כל הזמן היה לך בד קטן אז אז כמה שיותר למזר את ה את הבעיה הזאת של לוגיקה בטestטים שימו לב שבטestטים שלי אין שום לוגיקה גם דיברנו על דברים שלא טוב לעשות בטestטים לא טוב לעשות לוגיקה בטestטים יש לכם לולאות בטestטים ביוני testingים אינטגרש testים אין חוקים גרש test תעשו מה שאתם רוצים

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

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

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