Syntax

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

[00:43] (external link, opens in new tab) אוקיי אז השילוב הוIT testing אתם יכולים לעשות דבר עכשיו גרation testing אתם יכולים להוסיף אחר כך unit testingים הרבה יותר מהירים אז אפשר לקבל פידבק הרבה יותר מהיר ששברת משהו גרשן test אתה מקבל פידבק הרבה יותר איתי אבל אבל אתה גם בודק הרבה יותר דברים באותו זמן זה תמיד שילוב ששני שני הדברים האלה חברה שיש להם שיש לה רק סוג אחד בדרך כלל חברה שחסר לה משהו או חסר להגהירות פיתוח כי נורא מפחיד לקבל פידבק או אתה עושה משהו וא רק אחרי יומיים מקבל פידבק אם שברת משהו

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

[01:50] (external link, opens in new tab) החדשה עובדת גם עם חלקים אחרים שלא עברו את המיגרשן הזה זה יכול להות דקה נוספת מעניינת אינטגרש test נוסף שהייתי מוסיף אבל הוא לא הוא לא משהו שאולי רץ בנילי ביד אלא רץ לפני שאתה עושה deפמ זה את >> זה מה שהטest שלנו בעצם לא בודקים את זה כי עושה מהגרש test אם אתה רוצה לבדוק אתה מה שלך לסביבה סביבה by definition third party זה משהו שאין לך שליטה עליו אם זה רץ בקלאד אין לך שליטה על זה אתה חייב test אז אתה אומר אני מרים איסance ואני בודק מה קורה אני יכול להריס המוןגרש test על אפליקציה עכשיו דרך אגב זה יכול להיות מעניין אין שום מניעה ש שאתם תריצו גם את הוITטestים בקלאוד אם הקלאוד איך שהוא משנה את ההתנהגות של הקוד למרות שלא נראה לי

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

[03:07] (external link, opens in new tab) וזאת הבעיה הכי גדולה של clודף זה שוקח המון זמן לעשות פלוי גם ולבדוק שהטest שכתבת באמת יכול לרוץ אטגרש >> אבל זה באמת נושא קצת זה נושא שצריך לשבת ממש עם אנשים ולנסות לפתור אותו כי כל חברה זה סביבה אחרת לגמרי האינטגרשט test נכתב באותה תשתית כאילו זה עודסט של unit testing >> תחשוב על integrגרation test כטest שנכתב באותה תשתית נגיד במקרה שלנו זה יהיה NUnit (external link, opens in new tab) כי כל הקפורס הזה נעשה ב-NUnit ואבל גם יכול להיות בMS הוא פשוט מפעיל אפליקציות אבל הוא לא עושה פייק (external link, opens in new tab) לשום דבר הוא פשוט מפעיל את הAPI ומצפה שהכל יעבוד הוא כביכול UI שרץ

[03:45] (external link, opens in new tab) וקורה לhtר אוקיי. אז אם אנחנו רוצים לכתוב את הטestטים בצורה ש שהיא מקלה עלינו לכתוב את הטestטים בצורה שיהיה repatable ובצורה פשוטה אז יש המון המון פרwורקים לדבר הזה. עכשיו test frameworks בגדול נקראים x unit framewor או unit test framewor נקראים x unit frameworks הרמ שהx זה שם של שכר כלשהי ואז אומרים unit

[04:23] (external link, opens in new tab) אז הראשון היה בכלל בסמלט ונקרא SUnit אחרי זה יש JUnit (external link, opens in new tab) CppUnit ו-VBUnit זה הפרוק שאני התחלתי איתו עכשיו NUnit שזה הפרוק שאנחנו נתחיל איתו זה הפרימוק שהיום הכי הרבה משתמשים בו למרות שמסטest הוא באמת המתחרה הגדול שלו אבל יש ביניהם הבדלים תאומיים מבחינת החשיבה ומבחינת היכולות את JUnit זה ה זה המקור שממנו הIT testing בדיוק. זאת אומרת לפני שהיה MSTest היה NUnit ו היה של JUnit

[04:56] (external link, opens in new tab) ובתור פורט של J הוא גם לקח כמה מהקונבנציות שהיו בג'אבה באותו זמן ולכן חלק מהשמות שאתם תראו הם נשמעים בהתחלה נורא מוזרים. MSS דווקא שיפר חלק מהשפה הזאת ועשה את השמות קצת יותר קלים וקריים. היום יש פריורק לunitesting בגדול לכל שפה שקיימת רובם הם open source free. אז אם אנחנו מדברים על גאבסקריפט unit testing וtdd אתם יכולים לעשות גם את זה מדברים על flashש אז גם בזה אפשר אני אפילו ראיתי

[05:26] (external link, opens in new tab) Unitest frameworks לדברים כמו hot מישהו מכיר את אוטו יפה אז אני אפשר לחתוב בזה unitest למי שלא יודע שזה פרימו בכלל לאוטומציה של המחשב לוקלית אתה עושה מקרואים זאת אומרת כשאני לוחץ f3 אז תפעיל את הנטפד ותשים בו את הטקסט הזה כל מיני דברים מוזרים אז אפשר לכתוב ביזה טסים לסקריפטים הזה אני בעיקר בעבודה שלי התעסקתי עם עם JUnit, NUnit, VBUnit ו-CppUnit. זאת אומרת אני בא מהרבע שפות האלה אבל בשנים האחרונות אני גם עבדתי ברובי שנתיים וגם בדוטנט ב-10 שנים האחרונות או עד שזה התחיל לדבר

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

[06:33] (external link, opens in new tab) בדרך כלל די סטנדרט. יש קלאסים ובתוכם יש טestטים או שיש להם אטרביוטים יסיים או משהו שני naming convention ש מסמן שהם testים. ההרצה שלהם יש גם commנדלי line וגם UI וכשמריצים אותם ויש תוצאות אז רואים מה נכשל ובאיזה שורה זה נכשל את את הxpectד results זוכרים הרבה דברים by deffaultט אבל זה אינפסטקר מאוד קל ומאוד פשוט בכל test יש לנו שלושה חלקים כמו כל דבר בצבא arrange up והסט

[07:05] (external link, opens in new tab) ובunit אנחנו נכתוב test בתוך קס שנקרא test fixurms test זה נקרא ‏test classס שזה שם הרבה יותר טוב תחשבו על פיקure כcס תחשבו על זה כמדף כלשהו testure זה אריבוט שהוא חלק מ-NUnit שמוסיפים referלס ל-NUnit מקבלים את האatבט הזה ועוד כמה מכיוון שכל הטסטים שלנו הם בעצם פונקציות הם חייבים להיות בתוך קלאס לא משנה מה השם של הקלאס אני בדרך כלל מתחיל בשם שנגמר שמתחיל בפרויקט שאני בודק

[07:37] (external link, opens in new tab) אם זה הקלאס היחיד אם זה הפרויקט אני מתחיל בשם של הפרויקט ואם זה אם אני בודק קלאס אז אני כותב את השם של הקס שאני בודק. אם הUNIT work שלי הוא יצול מקס אני כותב את הUNIT לדוגמה לoging אבל הרבה פעמים ו90% מהזמן זה ברמת הקלאס כי שם נמצא הפאבליק מוד שלי איפשהו ובדרך כלל הוא גם שם נגמר ואז את המילה test אבל אני לא חייב לתוך את המט פשוט עוזר לי מבחינת הקonveng

[08:08] (external link, opens in new tab) כל הטestטים יכולים להיכתב בפונקציה שלא משנה מה השם שלה עיקר שהיא פאבליק ולא מקבלת פרמטרים ולמעלה חייבים לשים את האטריביוט של test האטריביוטים האלה עוזרים לtest runner שלנו לcand ולi שמקבלים assembly או dl compile ומסתכלים בפלקlection ומחפשים את האatיוutים מי יודע מה זה reflectiontion אוקיי הם משתמשים בפלקש כדי להסתכל על האטריביוטים וכל האטריביוט שיש לו testם פשוט עושים לו עכשיו זה שם מאוד גרוע לטסט בסדר עכשיו זה ככה בן אדם שבא מגוניט היה כותב טestטים היום כי ביוניט כל test חייב להתחיל במילה ‏test כי הnaming convention לgit בזמנו לא היה אטריוטים היום בג'אבה כבר יש אבל פעם לא היה אטריביוטים

[08:50] (external link, opens in new tab) ולכן ה הרנר חיפש את כל הפונקציות שמתחילות במילה test היום אנחנו לא צריכים את זה יש לנו את הדבר הזה don't prepat המילה גם לא מספיק לבט testים בדרך כלל אנחנו ניתן להם איזשהו סוג של nameing convention זה nameing convention שאני מאוד ממליץ עליו בתור התחלה מכיוון שהוא מכיל שלושה חלקים שעוזרים לנו מאוד להבין מה היה אמור לקרות ומה מה הדבר שאני בודק בכלל. אז זה דוגמה של ט בצורה שבה אני הייתי כותב אותה ויש פה הרבה דברים יש פה הרבה הרבה לוגיקה כן איך הוא כתוב

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

[10:01] (external link, opens in new tab) לפעמים היא לא מחזירה resלט אבל אז העסרט שלי נראה אחרת אני בודק שמשהו נקרא פה אני מקבל resultלט אז אני משתמש בקלאס שנראה נקרא אסרט כמעט בכל הפריימורקים יש או קלאס שנקרא אסט או שיש פשוט מאות פונקציות שמתחילות במילה אסרט וj זה מאות פונקציות אחד בסרט לאסרט יש המון המון statics. As rquונקציה שתשתמשו ברוב הסיכויים הכי הרבה ואתם בודקים שה expectected value

[10:34] (external link, opens in new tab) Equals the actual. זאת אומרת זה תמיד מתחיל בexpected ואחרי זה זה actual. הרבה פעמ אנשים פה ותבים את זה הפוך. זה נורא מבלבל בהתחלה. אם תכתבו את זה הפוך הארורים שתקבלו עם הטest הזה יקשל יהיו מאוד מבלבלים ציפיתי להקט resultל אבל קיבלתי את הפקט כאילו כל מיני דברים כאלה כן אם נגיד שקיבלתם ארבע הוא יגיד לכם אם הטסט הזה יקשל מה שיקרה זה שתקבלו אפtion ואז יכתב לקסולנלי line או שבui אתם תראו באדום

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

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

[12:16] (external link, opens in new tab) אז השם של הטestט מורכב משלושה חלקים הדבר הראשון זה הIT of work במקרה הזה אם זה רק פונקציה אז זה השם של הפונקציה אם זה קלאס יכול להיות שזה השם של הקלאס זה מאוד משתנה בדרך כלל זה מתחיל בשם של הפאבליק פנקש שאני גוד הדבר השני שימו לב שיש פה את האנדרסקורore הזה זה מאוד חשוב לרדity בטestטים שיש את ההבדל הזה כשאין את האנדרסקור מאוד קשה להבין צריך ממש לקרוא ב ממש קשה לקרוא add two numbers זה בעצם הסנר אוקיי

[12:47] (external link, opens in new tab) כאשר אני קורא לד עם numers אז צריך לקרות את הדבר הזה שבו על זה כמו משפט אז זה הexpected behavior או expected result או expected to third part שור זה ככה אז עוד פעם add two numbers su them up בדרך כלל שלושת החלקים בדרך כלל אנשים שקוראים testingים הם שוכחים לפחות אחד מהם או שלא הם לא חושבים על אחד מהם אז הרבה פעמים אנחנו רואים ואז תחשבו על הבן אדם שצריך לקרוא את הטest שלכם עוד חמש שנים כמה הזמן הטestטים שלכם אמורים להחזיק חמש 10 שנים יחד עם כל הקוד של האפליקציה עוד חמש שנים בן אדם יקרא את הטסט שלכם גם עוד חצי שנה אתם תקראו את הטסט שלכם ולא תזכרו שאתם כתבתם אותו תגידו add sד

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

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

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

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

[15:41] (external link, opens in new tab) כשהסרט הראשון נכשל מה שקורה זה שנזרק אקפשן וזה אומר שכל הסרט מתחתיו לא ירוץ. אז אני לא אדע מה קורה איתם. אז בדרך כלל מה שאני אומר זה שלא כדאי לכתוב יותר מאסרט אחד אלא אם כן כל האסרטים הם על אותו אובייקט. כי אם הם על אותו אובייקט אז אחד נכשל אז זה כבר לא בדרך כלל הכל כבר נכשל. אבל אם זה על אובייקטים אחרים והראשון נכשל עדיין אכפת לך מה קורה עם האובייקטים האחרים אז בדרך כלל אני מפריד את זה שיש יש איזשהו סוג של one concept your test אתה בודק דבר אחד logי דבר אחד לוגogי בדרך כלל זה עליי אחד אז אם יש לך person אתה תבדוק את הname ואת הage אני יכול לכתוב את זה באותוטest אבל אם יש לי person ש אז כל אחד מהם הוא resultלט אחר אני אבדוק כל אחד בטסט אחר ואז אם טסט אחד נחשב אני עדיין רואה את התוצאה של טestט אחר

[16:30] (external link, opens in new tab) עוד שאלות? אז רגעז ברמה פרקטית אם יש לי פיסת קוד שאני רוצה לבדוק שמשפיעה באמת על שני דברים לא על פס יש לך שני resultלטס >> שני resultטס אבל זה בדיוק אתה פיסת קוד אתה ממליץ פשוט לשכפל את הטest פעמיים ופעם אחת לבדוק את >> תכף נדבר על מטability אבל קודם כל לשכפל את הטest ואחרי זה לעשות refctורing שהוא יהיהable אבל התשובה היא כן בהחלט כל אחד מהם צריך להיות בטest נכתב משלו כי גם האctטed behav שלך יהיה שונה שם נכון אני מצפה שהוא גם יכתוב ללוג וגם ישמור לדataס זה שני resultלס זה זה הIT of שיש לו שני resultלs זה בעצם שני unit of war כי כל אחד מהפיצ'רים יכול לעבוד בנפרד מאחר אתה יכול לעשות את זה אינטרמנטלי אני קודם כל גורם לפיצ'ר הזה לעבוד הנה זה עובד עכשיו אני גורם לזה לעובד בtd העבודה היא מאוד אינטרמנטלית אתה יכול לקחת כל דבר ולחלק אותו למטפלס feג'רס וזה אחד הדברים היפים בטd שכל הזמן יש לך משהו שעובד אפילו אם זה עובד ב-30% זה עובד אתה יכול לראות את הטestי הזה אתה יכול להביא משהו שהוא פרשה ששכרה עובד ועושה משהו

[17:31] (external link, opens in new tab) אז שני resultלט זה שני test. עוד שאלות מבחינת מטלבity הצס הזה הוא לא משהו שימו לב אני עושה פה ישירות ניו לקלator בדרך כלל בטסט הבא שלי אם ברגע שאני עושה טest חדש ואני רואה פה שני ניו אחרי שהשני טestטים שלי עוברים אז אני עושה להם ריפקטורים עכשיו למה אני מחכה עם הריפקטורing למה אני לא עושה פאקטורing לדעתכם למה לא כבר מראש יכולים לעשות פה איזה פאקטורים או איזה setup מתוד למי שמכיר

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

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

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

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

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

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

[21:53] (external link, opens in new tab) C#brary אוקיי ונקרא לו אקulator הכי פשוט שבר נכון שכולם צריכים לקרוא צריך להכנס לכם רואים מעולה אחורה אומר גם שומעים מעולה מהחורה >> פתו כיסא בשורה הראשונה רמי בשבילך כתוב עליו רמי אוקי כתוב לברי

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

[22:58] (external link, opens in new tab) ופה בזו Studio integraation אוקיי יש לי את הפונקציה הזאת אוקיי אני משתמש בגרסה של 2x בגלל שאני משמשתמש ישן שלהם אז אני רגיל לשורים הישנים אצלכם בדפולט זה יהיה סטודיו אם אתם הקטדתם או שלא יהיה לכם בכלל אז אם יהיה לכם שום שורטים שעובדים ברשרטר זה מה שאתם צריכים לעשות ללכת לסמן את זה ולעשות אפלי עכשיו היו הרבה שאלות ביום חמישי למה זהזל משתמש בריש ואז לאט לאט אתם תראו חלק מהסיבות אחת הסיבות הכי מעצבות אחת הדברים שהכי מעצבנים אותי עדיין ב-Visual Studio בלי רשפר זה שאם אני עושה rename לקס הוא לא עושה rename לפייל אלא כי אני עושה את זה בפס פה אז פה מה אבל רק אם עושים רני לפי עכשיו אני צריך לפתוח את הפייל

[23:46] (external link, opens in new tab) מה יותר פרודקטיביצד ימין >> צד ימין לכת לעשות כלי צריך להשתמש בעכבר בשביל זה מה הבעיה קלטור F2 דרך אגב זה הקלאס שלי אני רואה פה מלא זים שאני לא משתמש אז נסיעה על 10 אני אתטר מהם קוד נקי public in add בכ בכוונה נעשה פה איזשהי פונקציה הכי פשוטה שבעולם in x in y contנטרול shiיפ כדי לסיים את השורה ולהתחיל את החיים שלי אני x וx

[24:22] (external link, opens in new tab) אתם רואים פרוגמים עובד אוקיי ואני פה שיפט כדי לסיים את השורה פשוט חכם אני כי אני יודע רק מה צריך לעשות לעשות לעזור לקפיילר אבל אני בכוונה אוסיף פה קצת לוגיקה כי פונקציה כזאת זה לא פונקציה שהייתי כותב לה unit testing network כי זה אין פה לוגיקה יש פה מתמטיקה מתמטיקה וואלה הייתי עושה פה עכשיו מיליוני טestטים שבודקים את כל הרנ של המספרים הייתי עושה פה לולאות וכולי אבל ביוני testים אני בדרך כלל לא עושה לולאות אני רוצה שהטסטים שלו כמה שיותר פשוטים אז בדרך כלל אני אכתוב אותם רק לדברים עם לוגיקה אז בוא נוסיף פה לוגיקה if x קטן מאפס

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

[25:56] (external link, opens in new tab) אוקיי אז מה שאני עושה זה אני בכוונה עושה clסליבר אם הייתי כותב פרויקט של MSTest הייתי עושה פה test אבל אנחנו משתמשים פה בג עכשיו יש כמה סיבות להשתמש בני א' הטestטים רצים הרבה יותר מהר וב יש הרבה יכולות בוניט שאין ב-MSTest יש לפחות שתיים מאוד חשובות אנחנו נעבור עליהם עוד מעט והדבר השלישי זה שitate הוא extensible אם אנחנו רוצים להוסיף לו פיצרים מאוד קל לסט זה כמעט בלתי אפשרי להוסיף פיצ'רים

[26:28] (external link, opens in new tab) עכשיו מה השם של הפרויקט שלי אופס אוקיי מה השם של הפרויקט צריך להיות בדרך כלל זה השם של הפרקט זה השם של הproקט אז אם שזה byור ‏prodctט אז זה יהיה my calculator product unit tests אוקיי זה נראה ככה

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

[27:48] (external link, opens in new tab) אוקיי, בואו ניפטר גם האלה, אני לא צריך אותם עד שאני לא באמת צריך אותם. השם של הקלאס הזה במקרה הזה שלי זה יהיה tests. עכשיו אני צריך את האatטים של NUnit, אבל אין לי פה n unit. אז מה שאני אעשה אני משתמש ב-NuGet כדי להתקין NUnit ולהוסיף את הרפרס אליו. למי שלא ישתמש בנוגט, מישהו השתמש בנוגט בעבר. מי יודע מה זה נוגט? אוקיי,

[28:18] (external link, opens in new tab) יש כמה אנשים שלא יודעים, אז אני אסביר. NuGet זה extension ל-Visual שנורא מפשט את התהליך של להוסיף dependencies לפרויקט שלנו. אז אם היום אם פעם הייתי צריך ללכת לאתר של anu.com להוריד את הזigגפייל לעשות לו unz לקחת את dl לעשות לו reference מתוך הפרויקט שלי אז עכשיו אני יכול ללכת פשוט ללי package manager package manager consו שעובד בטח כפגין לתוך studio עם power shell

[28:48] (external link, opens in new tab) יש לו גם UI אבל אני בדרך כלל כבר לא משתמש בUI כי הui הרבה יותר אני יכול פשוט לכתוב פה אני עושה טב פשוט כד להתחיל להמשיך פק ואז אני נותן פה שם של פק אם אני עושה nu ואני עושה tab עכשיו הוא מביא לי את כל הדברים שמתחילים בNU אתם רואים שיש לי NU city NU analize אם אתם לא רואים זה נראה ככה מה שאני צריך זה NUnit אז אני פשוט כותב NUnit אני לא צריך אני לא אני יודע את השם שלו אני עושה install package NUnit ומה שקורה עכשיו זה שהוא מוריד את הפקage מוריד את הזיפייל והוא מתקין אותו אבל לפויקט לא נכון בדפאולט זה הולך לגרות לכם כמו שזה קרה לי עכשיו כי אני תמיד שוכח את החלק הזה פה בקומבו בוקס אתם צריכים לבחור באיזה פרויקט זה אקטיב

[29:35] (external link, opens in new tab) אז אתם זוכרים הפרויקט אתם בוחרים את הפרויקט של הITסטים ופשוט חוזרים על הפעולה >> אנחנו רגע נצל את זה להפסקה קטנה นะ