---
title: "Unit Testing Best Practices"
url: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/unit-testing-best-practices.md"
canonical: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/unit-testing-best-practices/"
tags: []
author: "Roy Osherove"
description: "Lesson 16 of 22 in TDD in .NET in Hebrew (Day 3 - Unit Testing Practices), 35:00. Free video by Roy Osherove."
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Unit Testing Best Practices

1. [Courses](https://courses.osherove.com/#courses)
2. [TDD in .NET in Hebrew](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/)
3. Day 3 - Unit Testing Practices

Lesson 16 of 22

Duration: 35:00 [Watch on YouTube](https://www.youtube.com/watch?v=L7m3myFfWMk) Spoken in Hebrew

## In this lesson

Roy Osherove groups his rules into tests that are readable, [trustworthy](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7 "Trustworthy tests (The Art of Unit Testing, 3rd ed., ch. 7)") and [maintainable](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8 "Maintainability (The Art of Unit Testing, 3rd ed., ch. 8)"), and tells how a [bug in a test helper](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-11 "How can we know we don’t have bugs in our tests? (The Art of Unit Testing, 3rd ed., ch. 11)") cost him and a [pairing partner](https://osherove.com/blog/2005/4/3/how-do-you-explain-pair-programming.html "How Do You Explain Pair Programming? (osherove.com)") 90 minutes on a Go engine built with [TDD](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27 "Test-driven development (The Art of Unit Testing, 3rd ed., ch. 1)"). For [trust](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7#sigil_toc_id_134 "How to know you trust a test (The Art of Unit Testing, 3rd ed., ch. 7)") he separates [unit tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_17 "Defining unit testing, step by step (The Art of Unit Testing, 3rd ed., ch. 1)") from [integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25 "Integration tests (The Art of Unit Testing, 3rd ed., ch. 1)") that need configuration, so a failing unit test is never "fine", and recommends [code reviews that start from the tests](https://osherove.com/blog/2007/3/13/test-reviews-vs-code-reviews-some-helpful-tips.html "Test Reviews Vs. Code Reviews - Some Helpful Tips (osherove.com)"). He argues that [code coverage](https://osherove.com/blog/2005/4/3/test-coverage-and-testing-angles.html "Test Coverage and testing angles (osherove.com)") means little without reviews, then reviews a test from [Microsoft's Unity](https://osherove.com/blog/2009/3/23/test-review-3-unity.html "Test Review #3 – Unity (osherove.com)") source that has no expected behavior in its name, a loop and [several asserts](https://osherove.com/blog/2005/4/14/try-to-avoid-multiple-asserts-in-a-single-unit-test.html "Try to avoid multiple asserts in a single unit test (osherove.com)"), and prefers [readability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9 "Readability (The Art of Unit Testing, 3rd ed., ch. 9)") to [removing duplication](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8#sigil_toc_id_161 "Keep tests DRY (The Art of Unit Testing, 3rd ed., ch. 8)").

## Transcript

5,263 words

[\[00:02\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=2s) אוקיי אז ככה טוב לא מי את המצלמה עוד וטרפל מציתך דרך אגב ש מצלמה במקום אחד כל הקורס >> >> היא לא באותו מקום כל הקורס >> איפה היית צת פעם שמה שם >> כל היום היום אנחנו הולכים לעשות לחלק את היום הזה לשני חלקים בחלק הראשון אנחנו הולכנו לדבר על practices, דברים שצריך לעשות או כדאי לעשות בזמן שכותבים

[\[00:36\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=36s) Testים. אנחנו נעשה קצת פורמליזציה לחלק מהחוקים שתמיד אני מבקש ממכם לשמור עליהם. אז אנחנו נדבר עליהם ב תחתוב של שלושת הרעיונות המרכזיים במה עושה עושה טestטים טובים יותר. טובים יותר זאת אומרת מחזיקים לאורך זמן קריאים יותר טestטים שאנחנו סומכים עליהם. אחרי זה קצת נסתכל על קוד של פרויקט קיים וננסה לכתוב לו testingים

[\[01:06\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=66s) אבל לפני זה גם נסתכל על קודים של כמה פרויקטים open source וננסה להסתכל על הטestטים שלהם ולראות אם אנחנו מוצאים שם בעיות או דברים שהיינו רוצים לשפר ובעצם לקראת סוף היום אנחנו נכתוב טestטים לקוד קיים כולל קוד שיש לו testingים אבל לא [unit testing](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec1 "Defining unit testing, step by step (The Art of Unit Testing, 2nd ed., ch. 1)") זאת אומרת קוד שיש לו ‏test ו שיאפשר לנו לעשות רפאקטורing ולודא שלא שברנו שום דבר או לפחות לראות איך זה מרגיש כשיש סיד של inration test שמאפשר לנו לעשות כרצונינו בקוד וממש להתקדם עם testing

[\[01:44\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=104s) אז בעצם שלושת החלקים של testים שמבחינתי נחשבים טובים זה readable [trustworthy](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-8#ch08lev1sec1 "Writing trustworthy tests (The Art of Unit Testing, 2nd ed., ch. 8)") maaintainable או RTF או RTM אבל היה כמובן תמיד איזה חכמולוג שאמר תעשה את זה RTFM כי זה גם צריך להיות מהיר אז RTFM test זה אחד הדברים החשובים שצריך שיהיה אז >> RTFM במושג המקורי או במושג הזה במושג המקורי מכן >> readable trustable fastי

[\[02:16\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=136s) >> אוקיי אם אנחנו רוצים שהנושא של unit testing יצליח בחברה אנחנו צריכים לדעת ולהכיר אה איך איך לקרוא טestט ומה לחפש בו כדי למצוא בעיות, כדי לשפר אותו. וזה הנושא של testwס. עכשיו אני יודע שהיום אתם עושים קודw באיזשהי צורה, נכון? >> מישהו פה עושה קודw? גם אוקיי, אז מה שאנחנו נעשה זה שאנחנו גם בחמישהים שאני אהיה פה וגם אחרי זה, מה שאני מקווה שתמשיכו לעשות זה שגם כל הטestטים שנכתבים יעברו קודיו.

[\[02:50\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=170s) בעצם הם יעברו קוד רוw ראשונים והרעיון הוא להתחילקוד רוwז מה 100טestטים כי בדרך כלל אם מתחילים קודיו מהטestטים לפעמים יותר מהר למצוא בעיות או בעיות בהבנה של ה של הבן אדם שכתב את הקוד בגלל שהשם של הטestט לפעמים אומר שהבנת את הדרישה בצורה לא נכונה ולפעמים זה גם פשוט קל יותר לעשות דרילדאון כדי להבין איך כל הפיצ'ר שמישהו כתב עובד אז תחשבו על זה שטest טestטים הם בסך הכל דוגמאות לאיך פיצרים עובדים במערכת אם אנחנו חושבים על זה במושג של אז במקום סתם להגיד אוקיי איזה קלאסים שתנו זה יותר תראה לי איפה הנטריפ point של הפיצ'ר הזה ובוא נתחיל לראות איך משתמשים בו גם מבחינתity גם מבחינת ההבנה שלך של הפיצר גם אפשר לעשות drלדאון לכל פונקציה שאנחנו קוראים לה

[\[03:37\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=217s) אז מבחינתי אם מוסיפים testwס הקודw יכול להיות הרבה יותר מהיר מבחינת מציאת בעיות וותיקון שלהם אוקיי דברים שאני אני מחפש בestw הם קשורים לשלושת החלקים האלה mainity וust למה חשוב לי שהטestטים יהיו קריאים זה נשמע פשוט אבל למה זה בכלל חשוב זה לא שאין טestטים בלתי קריים בעולם איך זה משפיע קריאים יכול להיות בהם בעיות ואם יש בהם בעיות אז זה הכי גרוע >> אם יש בעיות בטסטים זה הכי גרוע למה

[\[04:15\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=255s) טסטח ס אני אתן לכם דוגמה אמ אני עכשיו עושה סדרה של אה וידאוים של [TDD](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec6 "Test-driven development (The Art of Unit Testing, 2nd ed., ch. 1)") שאני עושה פרingנ עם מישהו בכלל בסאטל במקרה הוא עובד גם במייקרוסופט הוא אחד מהחבר'ה שעושים טestטים ל לוינדוס אחד מהצטסרים של ווינדוס פונ אז אנחנו עושים פרing ברמוט ואנחנו עושים משחק שנקרא מישהו מכיר אתג משחק סיני עתיק אז אנחנו עושים מנוע שלג go בTD

[\[04:46\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=286s) זה משחק שהוא לא כזה מסובך הוא גם לא כזה פשוט, נורא נורא מעניין. אז סילמנו כבר שישה, שבעה וידאוים כאלה, משהו כמו תשע שעות ביחד סך הכל. ובסך הכל תחשבו שתשע שעות זה יום וחצי של עבודה בתור זוג. וב ב באיזודה האחרונה שהיא בערך שעה וחצי זה 90 דקות של תסכול מצד מצידי ומצידו. אוקיי? זאת אומרת מה מה את רוב ה-90 הדקות פילינו בלהבין למה הטestטים נכשלים.

[\[05:17\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=317s) ואיך לגרום להם לעבור. למרות שאנחנו כתבנו ביחד את הטestטים. אז הדברים שעזרו לנו להבין מה הבעיה היו השמות של הטestטים. השמות של הטestטים הצילו אותנו כדי להגיד וואלה יש לי חמישה טestטים שנכשלים אבל וואלה אני רואה רק לפי השמות שהטest הזה הוא הרבה יותר פשוט מכל השער. אז הבעיה היא כנראה במקום אחר לגמרי ממה שאנחנו חושבים. רק הדבר הזה בעצמו יכול להציל אתכם. אני אדפיל את זה כדי להבין למה משהו קורה. אם אתם לא יכולים להבין למה הטest נכשל אז בגלל הרדילי אז אתם לא יכולים גם לתקן אותו המטנabity שלו גם נתקף

[\[05:54\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=354s) אז ניסינו לעשות פיצר ואז הטסטים התחילו להכשל וגילינו דרך אגב שהבעיה היא בטestטים יש לנו היה לנו באג בטestטים באיך שאנחנו ממלאים את הלוח של הג עכשיו הבאג הזה לא קלטנו אותו ברגע שכתבנו את הקוד הזה את הבאג הזה מצאנו חמש שעות אחרי שכתבנו שני סשנים אחרי מבחינתנו להבין שהיה לנו באג בטestטים לקח לנו שעה וחצי ברגע שגילינו אותו לקח דקה לתקן אותו אוקיי אז מבחינת הטestטים יש כל מיני דברים שאנחנו עשינו בצורה לא נכונה שהיינו יכולים לעשות בצורה הרבה יותר טובה ומה שאני רוצה להגיד זה שזה לא משנה כמה ניסיון יש לכם אתם עדיין יכולים לעשות מה שנקרא roוק י מסקס כי אני זה שכתב את הטestט הזה ואת ואני זה שאמר וואלה אני לא צריך לבדוק את הלוגיקה הזאת בטestט אני תמיד אומר לכם וואלה אל תשימו לוגיקה בטסטינג זה סוג הדברים שלוגיקה יכולה לעשות לקחת זמן של שני אנשים 90 דקות כדי להבין למה משהו קרה ואם זה היה בן אדם אחד שעובד על זה

[\[06:54\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=414s) 90 דקות הוא לא היה מוצא את זה שני אנשים היינו צריכים כדי לבדוק את זה כי רק הדבאגינ של הדבר הזה היה שעה וחצי וגילינו שני באגים באותה פונקציה שהיא helperפנקש בטestטים שלנו אוקיי אז זה יכול לקרות לכל אחד ולכן צריך מאוד מאוד להיזהר אז הנושא של trust זה אחד הדברים שאכל אותנו אנחס שמחנו על הטestטים שלנו ואז יום אחד גילינו שהטestטים שיקרו לנו הם לא גילו לנו שיש להם ב רק שניסו להשתמש בהם בסדר נוצת יותר מסובך פתאום גילינו שכל שחלק מהטestטים שכתבנו עד אותו רגע נתנו לנו תוסאה שהיא יכולה להיות שקרית

[\[07:31\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=451s) אז היינו צריכים ללכת לכל הטסטים הקודמים ולבדוק שהם גם נכשלים כשהם צריכים להקשר אחרי שקילינו את זה למזלנו היה רק חמישה תרתיל אז בלי רדבילטity לא היינו בכלל יכולים לגלות את זה זה היה לוקח הרבה יותר מ-90 דקות. המיטבabity זה הרעיון שהטestטים מחזיקים הרבה זמן. כמה זמן הטestטים שאני כותב יחד עם הבן אדם הזה יחזיקו? הכוונה היא 5-10 שנים בקלות. אוקיי? ויש כל מיני דרכים כדי לוודא שהם יחזיקו מעמד. זאת אומרת שלא באיזשהו שלב ועוד שנה מישהו יגיד

[\[08:02\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=482s) לוקח לי יותר מדי זמן לשנות כל פעם את הטסט כל פעם שאני אשן את הבורד שניות. Screw this אני לא רוצה לעשות את זה יותר. ואז מישהו מוחק את הטסט עושה לו איגנוור. הכי גרוע שעושים אגנור. מישהו עושה אגנור לטסט אף אחד לא יזיז את האגנור הזה יותר בחיים מהטest הזה למשך חמש שנים יהיה אגנור על הטest הזה מישהו ישאל למה יש אגנור מישהו אומר עזוב לא יודע אין לי מושג ואז האגנור הזה נהיה כמו כל חתיכת [קוד לגאסי](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12 "Working with legacy code (The Art of Unit Testing, 3rd ed., ch. 12)") וזה שם אל תיגע תן תפגע וזהו אז הנושא של טestטים שמחזיקים מעמד קשור מאוד לרדבity כי אם אתה לא מבין למה הטest עושה מה שהוא עושה אתה יכול לעשות לו mainנס

[\[08:38\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=518s) ואם לא יכול לעשות פה maנס אתה לא יכול לסמוך על אותו הם כולם מחוברים אז בואו דווקא נדבר על trust קודם כל trust זה אחד הדברים הכי חשובים שיש לנו בטestטים אם אנחנו לא סומכים על הטestטים אז כמעט הכל לא היה שווה לעשות את זה make it easy to run הקונספט פה אומר אם אני מסתכל עכשיו על פרויקט אחד הדברים שאני מסתכל עליהם זה בסutושtion לראות כמה כמה test projטס יש לי

[\[09:08\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=548s) אם אני רואה שיש לי רק testקט אחד זה יכול להגיד כמה דברים יש לכם רעיונות מה זה יכול להגיד שפט אחד מתוך סלוש פרויקט אחד מתחסן >> רק פרויקט אחד מתוך הסולושן הוא פרויקט של טestטים זה מה שאני אומר מה זה אומר לגבי הסולשן >> שיכול להיות שהוא מרכז הרבה פרויקטים >> שיכול להיות שהוא מרכז הרבה פרויקטים יכול להיות שהוא רק לפרויקט אחד >> יכול להיות שכל הטestטים של כל הפרויקטים הם בפרויקט הזה זה

[\[09:42\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=582s) אז מה זה בטוח אומר >> בטוח שכל הטסטים תמיד אותו אז תריץ את כל הטestטים שאם תריץ אותו תריץ את כל הטestטים שיש לך נכון אבל זה גם יכול להגיד כמה דברים אחרים זה יכול להגיד א' שיש לי אינטגרש test וניט test מחוברים באותו באותו פרויקט יכול להגיד או שאין לי מספיק testים אבל אם אני לא יודע זה אומר שאין לי מספיק readדity שלהבין למה משהו אה הטestטים של מה קשורים למה אם אני לא יכול להבין שיש יש את לפרויקט הזה יש טestי אז הרבה יותר קשה לי אחרי זה לעוב ולתחזיק את זה ולחפש את הטestטים

[\[10:17\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=617s) אבל בואו נתחיל דווקא בדבר המרכזי אני רואה שיש רק פרויקט אחד מה שקופץ לי לראש זה שאנגרש test ו test הם מניingס במערכת הזאת זאת אומרת יכול להיות שחלק מהפקט מהטestטים האלה הםation חלק מהtestים הם unit מי זוכר מה ההבדל בין test >> זמן ריצה זמן ריצה יכול להיות ההבדל אבל זה לא חייב להיות חייבים לראות הרבה מאוד תנאים שניסים לעמוד בהרבה תנאים כמו היותים ברורים קצבים

[\[10:47\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=647s) יש להם הרבה קונסטרנטים >> אבל בגדול מה ההבדל יש איזשהו הבדל מטה ביניהם זה כולל כמה >> עכשיו אני מרגיש פה באנטגרש test מה >> זה כולל כמה unityים >> כמה יוטים testל כמה testבדוק כמה דברים אבל יש משהו יותר חשובדביסים מה זה אומרפטי פטי אוקיי ומה זה אומר >> זה אומר ש >> מה metס פה האם יש לי שליטה בכל הדברים שאני בודק

[\[11:19\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=679s) >> אוקיי זה ההבדל בינגרש test מבחינתי הם שניהם בדרך כלל ירוצו בזיכרון אני יכול לעשות test שהם מאוד מהירים אבל אם אני עושה integraation test עם random number generator והוא הכל בזיכרון זה עדיין מבחינתי [integration test](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec3 "Integration tests (The Art of Unit Testing, 2nd ed., ch. 1)") כי אין לי שליטה על המספר שיצא אוקיי גם אם עושה testing frדים גם אם הוא רק בזיכרון עדיין test כי אין לי שיטה על פרדים נפרדים זאת אומרת אני צריך להרוג אותם בנפרד אין לי שליטה על הדברים מהמערכת הנה הדבר הכי מוזר שקרה לי זוכרים עכשיו דיברתי לכם על משהו שהסשן של היה 90 דקות של תסכול אז היו שני באגים בבאג של הגו הבאג הראשון

[\[11:56\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=716s) היה שאני עשיתיגט לדס לכל הטestטים והיו משהו כמו 20 טestטים סוף ואצלו כל הטestטים עברו ואצלי שני טestטים נכשלו אוקיי, הקוד היה אותו קוד, אצלי שני טסטים נכשלו ואצלו שני טestטים עברו. אז אחרי 10 דקות של דבאגנ אני מנסה להבין ואנחנו מבינים שאנחנו עושים ספליט לכמה סטרינגים ואצלי הספליטים מכילים newני line ואצלו הספיטים מכילים new line בסג

[\[12:27\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=747s) ולכן אצלי הספליטים לא עובדים ואצלו הספליטים כן עובדים. אוקיי עכשיו לא היה פה שום דבר שקשור לקאלצ'ר. אמרתי אוקיי וואלה אולי אצלך משהו קשור לקלצ'ר במחשב ואז איכשהו ניולינס נראים אצלך אחרת אבל אז שתבינו לא בכלל לא חשבתי על זה שיכול להיות פה איזשהו אישי בסוף התברר ששנינו משתמשים בגיט ואצלנו הגיט מקונפג לעשות גט אין שהוא משנה את את הCRLF את את הקומנדל line ואת הרן כדי שבעצם הסטרינגים יהיו שונים בפיילים

[\[12:59\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=779s) זה סוג של דוגמה למשהו שאתה כמעט ולא יכול לשים לב אליו אז פתאום אמרתי וואלה אולי בעצם כתבנו integrגרש test ולא שמנו לב עד עכשיו אולי משהו קשור לקצר אבל זה היה קשור בכלל לשימוש שלנו לקונפיגורציה של גיט אוקיי אז אפילו דבר כזה פשוט פתאום יכול לגרום לכם לתוצאות מוזרות עכשיו למה אני אומר את זה אני אומר שיש הבדל ביןגרש לוit test ואני אומר וואלה פה unit test ונingration test מעורבבים עכשיו לי יש בעיה עם זה שמערבבים unit test ואינטגרation test באותו פרויקט

[\[13:31\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=811s) למה מה הבעיה? שת אתה מוריד את כולם ביחד בעצ >> מה >> אתה מוריד את כולם ביחד >> נו אז אני מוריד את כולם ביחד ו >> דבר ראשון זה פחות זה פחות מהיר >> יש לי זמן בוא נניח שיש לי זמן מה הבעיה testרך כנראה איזשהיא סביבה מוכנה מסוימת שאתה רוץ עליה לדע בדיוק מה היא test לעבוד אותו דבר הכל אז שם מתחילה מה שם מתחילה הבעיה שינטגרש בדרך כלל דורשים קונפיגורציה וטest אמורים לא לדרוש שום קונפיגור רציה זאת אומרת

[\[14:07\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=847s) ב בbest cas סנר שלי אני אמור לעשות גטלי ואנריץ את כל הטestטים וכל היוטestטים אמורים לעבור ב-100% זאת אומרת אף אחד לא עושה צקור בלי שכל הוIT testים עוברים אבל test יש סיכוי שהם לא יעברו בגלל שיש לי קונפיגורציה שונה על המכונה כל מיני דברים אחרים הדatביס לא מותכן יש לי אקנ לא מותקן ואז אם אם הם ביחד באותו פרויקט יכולה להיות לי בעיה שה בעיה מאוד אנושית

[\[14:37\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=877s) אני מריץ יש לי 100 טestטים שלושה נכשלים אני מסתכל אני שואל מישהו בצוות יש לך מושג למה הטסטים נכשלים ואז המישהו הזה בצוות יכול להגיד לי את הדבר הכי גרוע שצריך שאפשר להגיד למישהו שהריסטי ונכשלו זה בסדר אם אומרים זה בסדר אז אנחנו בעצם מפסיקים להאמין לטestטים אנחנו לא סומכים עליהם יותר על התוצאות האלה זה בסדר חסר לך דטבס זה בסדר אולי פשוט חסר לך קונפיגורציה ואז במקום להבין במקום בום לדאוג מהטestטים אני פשוט יוצא מקודת הנחה שהטעות היא לא אצלנו אלא הטעות היא בקונפיגורציה של המערכת ואז אני ממשיך הלאה הרבה פעמים אין לנו את הזמן ללכת ולקלטק את המערכת לכל האנטגרש test

[\[15:16\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=916s) או פתאום טסט אחד נכשל ולפעמים לא נכשל ולא נכשל ואז מישהו אומר לא זה בסדר זה אמור להיקשל כל פעם שלישית עכשיו אם הייתי מפריד את זה התוצאה הייתה יכול להיות אחרת לגמרי אם אני מפריד את זה לנד unit test ונדגרation בחלק המינימלי אני יכול להניח שאני עושה gets verion לכל הפרויקטים עושה קליק ימני על הפרויקט של הניטestים והם כולם אמורים לעבור ואם אפילו אחד מהם לא עובר אני צריך להרגיש מודעג

[\[15:48\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=948s) אני צריך להרגיש מודעג צריך להיות לי איזשהו saיגreין זone ביניט testing שהם כולם אמורים להיות ירוקים ואם אחד מהם לא ירוק אני צריך להרגיש דאגה ואני רוצה לעשות משהו לגבי זהרation test אני מכתחילה יוצא מכלת הנחה שצריך קונפיגורציה וצריך צריך כל מיני דברים אחרים ואז אני באמת פחות מאמין לתוצאות שלהם אבל מכיוון שיש לי פרויקט נפרד שהוא מובטח לי שהוא אמור לעבור כי הוא כולו אמור להיות unitest אז כמבחינת הביטחון שזה נותן לי זה ביטחון הרבה יותר גבוה להגיד וואלה בטestטים האלה שום דבר לא נכשל ואם משהו נכשל אז משהו לא היה בסדר אבל מכיוון שהכל עובר אז הכל בסדר מבחינת היוניטסטים האלה הכל בסדר זה נותן יותר ביטחון ויותר אמ ואני יותר בוטח בטסטים שלי אז השלב הראשון זה להפריד בין unitgגרation test כדי שאני אוכל לבטוח בתוצאות.

[\[16:37\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=997s) אם יש לי תוצאות שבהם הדברים מעורבבים אז אני לא יודע אם מה שנכשל זה unit אונגרation test. ואז אני צריך להיכנס ולבדוק ולאף אחד אין זמן להיכנס ולבדוק את הדברים האלה ואז מניחים שאולי הבעיה היא בכלל בקונפיגורציה במקום בטest עצמו או ש או שלוקחים את הזמן ומגלים ואז מגלים שזה האינטגרש test והבקונפיגורציה ואז בטestט הבא שנכשל כבר לא עושים את זה יותר אז זה נותן לנו את הרישיון להתעלם מהתוצאות של הטestטים כשאנחנו מערבבים בין שני הסוגים האלה זה אחד הדברים החשובים שכדי לסמוך על הטestטים צריך להפריד ביניהם כדי שיהיה לי פרויקט אחד שעליו אני באמת יכול לסמוך בפרויקט אחר שעליו יהיו הוראות איך לקנפק וכל הדברים האלה ואני יודע שהפרויקט הזה לא בהכרח יעבור ב-100%

[\[17:26\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1046s) אז דבר ראשון שאני עושה אני מסתכל על על המבנה של הסolution ואני מחפש אם יש בכלל פרויקט של test אם אין פרקט של integration tests אני מחפש subfoldרים של unit ונטגרation לפחות בקטע הזה לפעמים אנשים שמים קטגוריות של slow וfast זה התחלה אבל זה לא תמיד קשור למהירות ות ואם אני באמת רואה שאין את ההפרדה אז דבר ראשון שאני עושה זה כשאני עושה ריwטestטים החדשים שמישהו כתב אני מוודא שהטestטים שאני עכשיו עוד בודק הם נמצאים במיקום הנכון אני יוצר פרויקט שלי אם טestטים אין ואני שם אותם בפרויט שלי זאת אומרת מאותו רגע יש ברגע שאני עובר שם אז מאותו רגע לפחות כבר המצב יותר טוב ממה שהוא היה ל לבוב מרטין יש משפט שאומר חוק הצופים תמיד תשאיר מקום נקי יותר ממה שקיבלת אותו וזה נכון גם לגבי קוד אם אני נכנס לקוד אני תמיד משאיר אותו במצב יותר טוב ממה שקיבלתי אותו זה לא חייב להיות עכשיו ללכת לכל הטestטים ולשנות אותם במקרה שלכם זה דווקא כן יכול להיות אם יש לכם שמונה טestטים אז זה בסדר

[\[18:26\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1106s) תחו את השלוש דקות האלה כל אחד לוקח טestט מזוגות ומשנים את המקום שלו למקום הנכון שאלות לגבי זה אוקיי קודק [coverage](https://osherove.com/blog/2005/4/3/test-coverage-and-testing-angles.html "Test Coverage and testing angles (osherove.com)") אקד coverage זה משהו שבדרך כלל אני לא משתמש בכלים יותר מדי כדי לבדוק אותו. אני משתמש הרבה יותר בבדיקות ידניות כי אני יוצא מט הנחה שכל קוד שנכתב נבדק בקוד רב.

[\[18:57\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1137s) אבל נשאל את השאלה כמה cod coverage זה coverage טוב? כמה קודג' צריך? 100% >> 100% אוקיי מישהו בדק את הקודק שיש לו דרך אגב על הסטרינקulator שהוא ניסה אולי יחס תעשו את זה תבדקו כמה קוד קורג יש לכם אם יש לי 90% קוד קורג בפרויקט אתה יודע מה אם יש לי 99% קוד קורג בפואט

[\[19:28\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1168s) אוקיי יש לכם פה לוח והוא אומר 99% קוד זה טוב או לא טוב אפשר לדעת אי אפשר לדעת למה אי אפשר לדעת זה תלוי במה את הקוד הכי קריטי >> ה1% אוקיי >> לא אם הטestטים עושים את המטרה שלהם >> מה המטרה של הטestטים לא לעשות ק >> זה לא עניין רק של קוד זה עניין של תרחישים אם הם עונים על התרחישים שהכל מטפל בהם הם טסטים טובים יכול להיות שעל כיסיתי פונקציה מסוימת אבל לא כיסיתי אותה בכל מבחינת הדברים וגם גם יכול להיות קוד שהואגנט אוטומטיק שאין לי בכלל מה לעשות

[\[20:06\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1206s) >> אוקיי >> אז זה טוב או לא טוב מספר >> זה לא אומר שום דבר >> זה לא זה לא המטרה >> זה לא המטרה אבל אני חשוב שתבינו שבהרבה ריבונים קודק coverage הוא כן מטרה קוד קורג ה הוא לא יכול להיות מטרה בפני עצמה בגלל שהוא לא אומר שום דבר על קולטיק הוא רק אומר coverage אם אני אומר לכם עכשיו תשיגו 100% קודo coverage תוך שבוע יכול להיות פה קודק coverage של 100% זה לא אומר שאתם בודקים משהו אני מכיר והרבה חברות שיש הרבה מתחים שעשו בדיוק את מה שאמרו להם אז הם הגיעו לקוד קבר של 100% אבל לא היה להם שום אסרטים אפשר לעשות את זה אין שום בעיה הגיעו למטרה שאמרו להם נכון גם ככה אין זמן אז יאללה טוב אמרו לנו להשיג קוד קורג שחייבים לעשות את זה זה עובר קודם בקוד קורג מריצים נגיע ל-100% אין שום בעיה

[\[20:53\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1253s) אם יש לי 20% קוד קורג מה זה אומר זה אומר משהו >> זה לא הבדל זה לא שמ שזה בדלת מה >> לא נשמר שזה המדד >> לא נשמע שזה המדד אבל זה אומר משהוכ >> זה אומר משהו >> מה זה אומר זה אומר שיש לך עדיין קוד שאתה לא ניסית לעשות הגובות >> זה אומר שיש לך מה >> זה אומר שיש לך קוד בהנחה ש80% שנשאר הוא לא כולו קוד שאתה לא מעוניין גם לבדוק קוד שאתה לא יודע >> זה אומר בטוח זה בטוח אומר משהו וזה אומר שחסר לך טestטים >> בדרך כלל זה אומר משהו מעט מאוד חברות 20% מהקוד שלהם זה כל הקוד שלהם אלא אם כן זה חברות שמייצרות ID שמג'נרטים קודשהו

[\[21:30\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1290s) אבל גם קוד מג'נר ד אפשר לכתוב לו טestי מגנרטים גם לטסט זה גם לא לא בלתי אפשרי אבל 20% קודק coverage אם 20% קוד אומר שחסר לכם קוד אבל 99% או 100% לא אומר שום דבר מה עושים עם המידע הזה איך אפשר איך אפשר ש100% או 99% קורג יגיד משהו זה לא כתוב פה יש לכם רעיון דאוג לקליט שלו >> איך דואגים לקולטי

[\[22:05\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1325s) ‏Rw של הwטestטים אני מסכים איתך לחלוטין בליקוד revws cod cage לא שווה שום דבר קוד קורג גבוה הדרך היחידה שבה אני יכול לסמוך על cod cover cverage זה אם הקודק cover cverage הזה עבר גם testw אם אני יודע שהטestטים טובים והקוד קoverage גבוה אז אני יכול להגיד אנחנו במצב קל אוקיי זאת אומרת שאם אתם לא עושים testwusew אם אתם לא עוברים אחד לשני על הקוד כולל הטestטים זה לא משנה כמה קודק יהיה לך לכם יכול מאוד להיות שאתם משדרים לעצמכם. הדרך היחידה לדעת את זה זה ממש לשבת בין אדם מבן אדם ולעשות אינטראקציה אנושית ביניכם

[\[22:40\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1360s) ולדבר עם אנשים וללמוד אחד מהשני ולהסתכל על הקוד. זה לא רק לשלוח קומנטים ולהגיד שכחת אסרט מהבית. זה לשבת אחד ליד השני ולהגיד וממש לדבר אחד עם השני. לדבר על התהליך חשיבה בכל רם להגיד אה מעניין אותי למה זה כתבת ככה. למה איך למה אתה בודק את זה ככה? מה אתה מנסה לבדוק פה? ממש לעשות דיון על הקוד הזה. זה גם דרך מדהימה ללמד ולהעביר ידע בחברה, אבל גם חשוב מאוד זה מוודא שאתם בודקים באמת דברים, אתם בודקים את הדברים הנכונים.

[\[23:15\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1395s) >> אכן, אבל כן, כאילו בגלל זה אני חייב לדעת שאני לא מסכים איתך. אני חושב שבמקרה הזה מידה והבדיקות הם כן טובות. הקוד קורג כן מספק לך מדד מרגיע. כלומר, אם אתה בבדיקות הם טובות, אבל זה זה התנאי, אבל איך תדע שהבדיקות טובות? >> זה סבבה. ולכן אבל שוב אתה אומר שזה לא מוכיח ש שהבדיקות הן טובות אבל אם הבדיקות הם טובות זהח שהבדיקות זה יוכיח שאת במצב טוב אם יש גם testרwס וקודק coverage גבוה >> סבבה >> בסדר >> עכשיו בדרך כלל אם אנחנו עובדים בTD אני כמעט אף פעם לא בודק coverage זה אני אישית אבל אין לי שום בעיה שאתם תבדק coverage בגלל שבדרך כלל אני רגיל לעבוד בחברות יותר קטנות 10 12 יש פה כמה כמה ככה יש 18

[\[23:55\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1435s) זה כבר חברה יחסית יותר גדולה ממה שאני ממה שאני רגיל לעבוד בה אבל קודק coverage י יכול להיות מדד נחמד עם >> אבל מה כשאני בודק קוד של מישהו אחד הדברים שאני עושה זה אני יושב עם הבן אדם במקום סתם לבדוק קוד ק שאני מסתכל על testסט ואני אומר אוקיי מה יקרה אם אני אלך לפרודקש קוד ואתה רואה את האיף הזה אני אהפוך אותו לתמיד טר יקשה לי איזשהו טestט מה יקרה אם לא יקשל שום טestט מה זה אומר >> מה אם יקשל שום טסט או שהקוד הזה מותר או שחסר >> או שחסר טest זה בטוח אומר משהו אבל הנה עוד דבר חשוב כשמדברים על אינטראקציה אנושית אני אומר מה יקרה אם אני אעשה את הדבר הזה ואני מסתכל על הפנים של הבן אדם שכתב את הקוד

[\[24:39\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1479s) עכשיו אם הבן אדם הזה עשה את זה בTD בצורה הפשוטה ביותר הוא הגיד לי בביטחון מחלט לא יקשה לך לבחוש שניטסט עכשיו אם הבן אדם לא כתב את זה בטd זה מאוד פשוט הוא יאסס הוא יגיד נראה לי שמשהו יתקשר עכשיו זה לא דרך לצלוב מישהו זה דרך קצת להבין מה באמת קורה גם להראות ש שנורא אכפת לך מהקוד של הבן אדם זה לא סתם אתה נכנס לטיני טilס לדברים הכי הכי קטנים שחשוב לך איך שדברים כתובים זה לא סתם שפיצ'ר עובד זה גם קשור לקראפטנשיפ למקצוענות

[\[25:17\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1517s) להגיד שאצלנו יש איזשהו קול דיבור שאנחנו לא מוותרים עליו שאני לא מוותר עליו אישית אז לראות את הפנים של הבן אדם במה שאני עושה זה נותן לי המון המון מידע. זה לא אומר שאני אעשה משהו עם המידע הזה, אז זה בכלל אומר לי משהו לכיוון הבאות, לפיצ'רים הבאים שאני אבדוק. יש הבדל גדול מאוד בהתחתו של בן אדם שעשה משהו בTD לבין בן אדם שעשה טestטים אחרי מבחינת הביטחון שלו שמשהו ייפול או לא ייפול. זה דבר מאוד נחמד. אם אני עכשיו אלך לכל אחד מכם אני אגיד מה יקרה אם אני אשנה את העיף הזה?

[\[25:47\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1547s) כולכם תגידו לי בביטחון. אין שום מצב שזה לא יעבוד. אבל יכול להיות שאולי איזה זוג אחד פה שכתב כבר דברים regular expression ולinkקר יגיד מה לא בטוח שזה ייפול לא בטוח שיפול ב איזשהו כסף בגלל שככל שפותרים דברים בצורה יותר מסובכת הביטחון בזה שכל הדברים באמת נבדקים יורד אבל הרצון שדברים יעבדו מאוד גדול ולכן המנחות נוטים לעשות דברים בצורן מאוד מאוד ג'נרית אז אמרתי להימנע מלוגיקה בטestטים הנה דוגמה לטestטים לוגיקה

[\[26:21\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1581s) כולכם צריכים לקרוא את זה. אוקיי, כשאני מסתכל, זה test אמיתי, כמובן, הטestט הזה הוא ממיקרוסופט unity source cod. כשאני מסתכל על test, הדבר הראשון שאני מסתכל זה השם של הtest. Select constructor with two parameters. חסר משהו בשם? מה? ‏Behav תשימו לב כמה זה חשוב.

[\[26:52\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1612s) אם אני לא יודע מה אמור לקרות, אני עכשיו צריך לקרוא את הקוד של הטest, לחפש את האסרטים, לראות שיש לי פה את הדברים האלה. אז קודם כל הדבר הראשון שאני שם לב זה שיש לי פה לוגיקה. אתם רואים את הלולאה הזאת? לולאה כזאת זה לוגיקה. לולאה מחר יכולה להישבר בדרך כלל בנולאות מלבד פוריג', אבל גם פורי יכול להיות בו איזשהו בד שאתה לא רוצה לעבור על כל האייטמים. יש לי פה גם כמה אסרטים

[\[27:23\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1643s) עכשיו בואו תשימו לב לדברים שקורים פה יש לי פה אריקול 2 על paramמטר keys count ואז יש לי עוד פעם אריק 2 על הזנ אוקיי שני הסרטים האלה הם אותו דבר זאת אומרת שניהם מקבלים את הלנס ועושים את הרגול שתי איך איך מגיעים למצב כזה אם אני מסתכל על על test ואני רואה דבר כזה אני צריך להתחיל להתנהג קצת כמו שרלו ולנסות להבין איך זה הגיע למצב הזה וזה חשוב מאוד כדי להבין איך להבין איך זה דבר כזה מגיע למצב כזה כי זה אומר המון על מה כדאי לעשות כדי לפתור את זה כדי שזה לא יקרה יותר

[\[28:05\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1685s) איך לדעתכם אם זה מגיע למצב כזה >> מי ששינה את הפונקציה get parametטרסיז ורצה לבדוק אתה שכו כבר עוסרת לזה קטע אחרון פשוט נוסף אחרי זה >> הקטע אחרון נוסף אחרי זה >> ומתי שהוא קיז לא היה שתיים אז עשה עליו אסרט או יש פה כבר אסרט >> כן >> הוא לא שם לב לזה >> הוא לא שם לב לזה זאת אומרת שהוא לא כתב את הקוד הזה >> מישהו אחר עושה >> שני אנשים כתבו את הטestט הזה לפחות אוקיי זה מגיע למצב כזה כששני אנשים עורדים על הקוד הזה ואף אחד לא מדבר עם אף אחד אחר אז מישהו בא מסתכל על הקוד

[\[28:39\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1719s) אם קשה לקרוא את הטestט אז רוב הסיכויים שאנשים פשוט יוסיפו את את מה שהם חושבים שהוא חשוב ובכלל בכלל לא ישימו על שום דבר אחר שקיים בטסטופשוט יניחו שהדברים האחרים הם סוג של לגסי כבר אז אם קשה לקרוא את הטest אנשים לא ידרחו לקרוא אותו עכשיו asert policy is correct תשימו לב יש פה איזשהו help ftion שלכל אחד מהקיז הוא בודק יש לו איזשהוט בפנים

[\[29:12\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1752s) איזה מהאסרטים הוא החשוב לדעתכם שהפולicy הוא קורקט או שיש לנו שני casספולסי מה >> הפולסי >> פוליס אז למה צריך את האחרים כאילו אחר >> כדי שהפוריץ לא יעוף >> שהפוריץ' לא יעוף הפוריד לא יעוף אם יש לך רק אחד בתוך הפ >> הוא בודק שני דברים ואתה test פשוט הוא בודק שני result שימו לב יש פה שני result אחד זה שקיבלתי באמת שניים ממשהו והשני זה גם שיש לי קורק בינתן משהו שני results ואז מה קורה אם מחר יש לי רק אחד זה לעולם לא יבדק.

[\[29:48\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1788s) בסדר? וזה חשוב לי לדעת את זה. אז כמו רופא שמקבל מישהו לאבחון והמישהו הזה אומר לו רק חצי מהסימפטומים שלו, יכול להיות שהוא יתן את התרופה הלא נכונה, יחבש את הבג במקום הלא נכון, ינסה לתקן את זה ואז זה יעבור ואז זה יקשל. עכשיו נשאל את השאלה האם זה תמיד נכשל או שזה נכשל רק בגלל התיקון שלך. אוקיי? ואז יכול להיות מרדף די מעצבן בנושא הזה. אז דבר ראשון זה להפריד את זה לשני טestטים. דבר שני זה להתפטר מהנולאה הזאת. אני לא צריך את הלולאה הזאת.

[\[30:18\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1818s) אני יודע שיש לי רק שניים. אין שום מה לכתוב פה שני שתי קריאות לפוליסי. ברוב הסיפורים שאני לא צריך לבדוק אפילו שניים בעינתן כי בענתן אחד אני יכול לבדוק שהפוליסי קורק. זה אנזלט נפרד. אם אני יודע שהפוליסי הוא קורק לכל אחד שנכנס עכשיו אני יכול לבדוק שיש לי שניים. אני יכול לבדוק שהפוליסי יה קורקט רק כדי להרגיש אולי יותר בנוח עם הכל. וזה גם משהו שאתם תמצאים את עצמכם עושים הרבה. לפעמים אתם תראו שאתם מוסיפים טestטים שהם אמורים לעבור, הם לא אמורים להיקשר,

[\[30:48\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1848s) אבל הם ירמו לכם להרגיש יותר טוב עם הקוד. זה בסדר גמור להוסיף כאלה טestטים. אלה טestטים שבעצם עוזרים לכם לוודא שאתם יכולים לעשות דליבר לקוד הזה. בסדר גמור. רק תוודו שהשמות שלהם נכונים ושאתם לפעמים אתם יכולים לשים את זה ממש בקובץ נפרד והקובץ הזה יכול לבוא ולהגיד או advanceed usage או משהו בסגנון כדי להראות לקורה שפה לא מדובר במשהו שנעשה בtd אלא הוא מדובר במשהו שהוא מראה איזשהו סנר קצת יותר אמיתי עם הקוד

[\[31:25\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1885s) הטestטים האלה הם לא טestטים שהם לא חשובים אבל חשוב מאוד לשים אותם במקום שבו אתה מבין שהטestטים האלה לא מייצ מיצגים את הסקס הכי פשוט מאצגים casי שהוא כבר יותר מסובך בעינתן שכל הטestטים האחרים עוברים סוג של כביכול acceptט test אבל הכל בזיכרון בלי דברים שאין לך שליטה שאין לך שליטה כביכול pr אינטגרש שאלות לגבי זה שאלה >> כן

[\[31:56\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1916s) העניין של הסימת אסרט אחד בכלל זה לא יכול להגיע למצב שבו יהנו לנו הרבה מאוד דקות כפול בטסטי קוד כפול בטסטים אה אוקיי אז לגבי קוד כפול בטסטים אז דברים כמו הלפר מט שמייצרים לך את האובייקט אבל אז אבל אז הופך לטסט לא קריפר שקורה לאפר כאילו כמו שאמרת זה ביום הראשון ש הטסט מצד שבו אני יכול לקרוא אותו דבר ככה אחת >> אבל אם יש לי הלפר שקורא לאלפר שקורא לאלפר אז אז הקוד הוא לא כפול אבל קודם כל אחד אני לא זוכר רמי רמי צודק שאם יש לי הלפרים יש לי מגלבל של הלפרים אז זה לא קרים אני בל מנסה שתהיה לי רק שכבה אחת של הלפרים שאני קורא למטסט ולא אחד שקורא לשני כי אחרת זה באמת בלתי קרי

[\[32:39\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1959s) ולפעמים אני אפילו מסכים שיהיה לי דפליקיש בטestי כי יותר חשוב לקריאות מאשר mainity של testing זה חשוב קריאות בלי קריאות זה לא משנה כמה הטest שלי הוא מינable אם אף אחד לא יכול להבין אותו אחד הדברים הכי מסובכים שראיתי זהטestטים שיש להם cles עם שלוש חבות גמ ככה שאתה רואה איזשהו טestט קלאס ולכל טestט מאחורה קורים 350,000 דברים ורק להבין את כל הסייד אפקט של כל טestט

[\[33:11\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=1991s) זה כמעט בלתי אפשרי אז הטestטים הם באמת היו מאוד מינטינable ומבחינת אינג'נירנג הם ממש ממש היו יפים אפשר להגיד מבחינת ההבנה של מה להזזל קורה שם היית רואה איזשהו אסרט מאוד בסיסי כאשר למטה הוא היה עושה עוד 50 אסרטים אחרים ובסטאפ שבכלל לא היית רואה הוא היה בבייס קלאס היו קוראים עוד 30 דברים כמו לשים מלא [מוקים](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_76 "Interaction testing, mocks, and stubs (The Art of Unit Testing, 3rd ed., ch. 4)") [וסטאבים](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_62 "Reasons to use stubs (The Art of Unit Testing, 3rd ed., ch. 3)") וכל מיני דברים כאלה אז הקריאות הייתה גרועה מאוד ולכן כל פעם שמישהו רצה להוסיף טestטים חדשים היה נורא מסובך להוסיף טestטים חדשים כי כמעט אף אחד לא הכיר את הפרוטוקול של איך להוסיף טestטים מה יש בביס האלה כי האינפסטראקטור של הטestטים היה כל כך מסובך הוא היה אובר engineר שהיה מאוד קשה למישהו להוסיף טסטים חדשים בלי לשכפל קוד ורק לשים איזה איזשהו קופי משהו פשוט ואז פתאום לקח שאל הוסיף טסט חדש בגלל שכל הדepנen האלה דרשו שימלאו אותם במקום משהו שאתה יכול לעשות סטריפ לקרוא אותו ולגמור עניין אזדפליקישן

[\[34:10\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=2050s) ברמה מסוימת זה משהו שלדעתי הוא בסדר אם זה על חשבון קריאות זאת אומרת אם אני צריך לבחור בין דופליקיש לבין קריאות אני אבחר קריאות לא אבל זה לא רק נגיד הבדיקה הזאתי קודם כל בודק שהקונסטקצור נכון ורק אז מהקיז שלו נכון עכשיו אם אני עושה את זה כשתי טestטים יפדים אז מספיק שהקונסטקטור יקשל ואז זה קבל שתי טסים שכשלו ואז זה כמו שכאילו תראות ביפול פתאום 15 אקספו שגיעות קופילצ לא קשורות אחד לשנייה אם היא תקבל רק את השגיעה הראשונה שבגללה אתה יודע כל הידה ביותר הכריף השגיעות היו יותר קירות >> אנחנו נדבר על זה בהמשך אבל בגדול

[\[34:45\]](https://www.youtube.com/watch?v=L7m3myFfWMk&t=2085s) שני טestטים האלה הייתי משאיר אותם את שני הסרטים האלה ביחד תשימו לב ששניהם על אותו אובייקט מתחילים על אותו אובייקט בדרך כלל שיש לך מטיפלסרס על אותו אובייקט אז אז אכפת לך רק מהראשון שנכל ועל השר כבר לא אכפת לך אבל כשיש לך שני הסרט

## Related

- [The pillars of good unit tests](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-8) · The Art of Unit Testing, 2nd ed., ch. 8

    The pillars of good unit tests: trustworthy, maintainable, readable, the three groups the lesson organizes rules into.

- [Mixing unit tests and flaky integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7) · The Art of Unit Testing, 3rd ed., ch. 7

    Book section on mixing unit tests and flaky integration tests, why the lesson keeps them apart for trust.

- [Test Reviews Vs. Code Reviews - Some Helpful Tips](https://osherove.com/blog/2007/3/13/test-reviews-vs-code-reviews-some-helpful-tips.html) · osherove.com

    Tips on reviewing tests instead of code, matching the advice to start code reviews from the tests.

- [Test Review #3 – Unity](https://osherove.com/blog/2009/3/23/test-review-3-unity.html) · osherove.com

    Roy's video review of Microsoft Unity's tests, the same codebase whose test is critiqued in this lesson.

### Also linked in this lesson

#### The Art of Unit Testing, 3rd ed.

- [Maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8), ch. 8
- [How can we know we don’t have bugs in our tests?](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-11), ch. 11
- [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27), ch. 1
- [How to know you trust a test](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7#sigil_toc_id_134), ch. 7
- [Defining unit testing, step by step](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_17), ch. 1
- [Integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_25), ch. 1
- [Readability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9), ch. 9
- [Keep tests DRY](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8#sigil_toc_id_161), ch. 8
- [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12), ch. 12
- [Interaction testing, mocks, and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_76), ch. 4
- [Reasons to use stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_62), ch. 3

#### The Art of Unit Testing, 2nd ed.

- [Defining unit testing, step by step](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec1), ch. 1
- [Writing trustworthy tests](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-8#ch08lev1sec1), ch. 8
- [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec6), ch. 1
- [Integration tests](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec3), ch. 1

#### osherove.com

- [How Do You Explain Pair Programming?](https://osherove.com/blog/2005/4/3/how-do-you-explain-pair-programming.html)
- [Test Coverage and testing angles](https://osherove.com/blog/2005/4/3/test-coverage-and-testing-angles.html)
- [Try to avoid multiple asserts in a single unit test](https://osherove.com/blog/2005/4/14/try-to-avoid-multiple-asserts-in-a-single-unit-test.html)

[Previous lesson Day 2 Summary](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/day-2-summary/) [Next lesson Best Practices Continued](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/best-practices-continued/)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/