---
title: "Summary and Discussion Day 3"
url: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/summary-and-discussion-day-3.md"
canonical: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/summary-and-discussion-day-3/"
tags: []
author: "Roy Osherove"
description: "Lesson 22 of 22 in TDD in .NET in Hebrew (Day 3 - Legacy Code), 18:48. 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/"
---

# Summary and Discussion Day 3

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 - Legacy Code

Lesson 22 of 22

Duration: 18:48 [Watch on YouTube](https://www.youtube.com/watch?v=8JAPnkm18-A) Spoken in Hebrew

## In this lesson

Roy Osherove explains that a [fixture setup](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9#sigil_toc_id_171 "Setting up and tearing down (The Art of Unit Testing, 3rd ed., ch. 9)") runs once before all tests and usually means something slow is initialized, and agrees that the [refactorings](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5 "Variations on refactoring techniques (The Art of Unit Testing, 2nd ed., ch. 3)") made the code [more testable, not better designed](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-11#ch11lev1sec3 "Pros and cons of designing for testability (The Art of Unit Testing, 2nd ed., ch. 11)"). On whether to [fake](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2 "The difference between mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)") the method that parses the links out of the content, he prefers to keep as much code in the [unit of work](https://osherove.com/blog/2020/3/12/unit-testing-entry-points-and-exit-points "Unit Testing Entry and Exit Points (osherove.com)") as stays fast, in memory and readable, fakes threads, processes and the file system, and calls the choice [the art of unit testing](https://www.manning.com/books/the-art-of-unit-testing-third-edition "The Art of Unit Testing, Third Edition (The Art of Unit Testing, 3rd ed.)"); a debate on [testing private methods](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8#sigil_toc_id_160 "Avoid testing private or protected methods (The Art of Unit Testing, 3rd ed., ch. 8)") follows. Each pair then writes two or three tests for real production code that go into source control.

## Transcript

2,872 words

[\[00:01\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=1s) בDSM שמתם לב שיש בסטestי יש פה אבט שנקרא testure setup וtest feure setup זה אטריוט שקורה פעם אחת לפני כל לפני כל הטestטים זאת אומרת גם אם יש לכם 10ה טestטים הפונקציה הזאת תרוץ רק פעם אחת קס בMS זה נקרא קס לדעתי אבל יש גם פונקציה setטאפ בחלק מהקלאסים שיורשים ממנה שהיא קוראת פעם אחת לפני כל טest משתמשים ב כדי להתחיל את כל הטestטים

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

[\[01:08\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=68s) אה שור >> קיאור אוקוד המקורי >> קיאור הקוד המקורי שהיה יפה קודם פתאום נהיה מכוער אוקיי >> נהיה פחות קר >> הוא נהיה פחות קר אוקיי בסדר הריפקטורים של הוא רק עושה אותו יותר testable הוא לא עושה אותו יותר דזי תשים לב תשימו לב זאת אומרת לכן ההבדל ביןסטב לדין מאוד גדול בסדר עדיין יכול מאוד מכוער ומאוד טסable אוקיי זה אינסט חשוב מה עוד היה משהו >> היה אצלנו בחדר ששמנו לב ש

[\[01:41\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=101s) חלק מהאנשים קראו לה פונקציה כשהם נתנו קונטנפט מסומלץ כאילו ממש סטרינג שמכיל תוכן עם לינקים >> ואומרים ואני בחרנו דווקא להתעלם מזה כאילו לעשות שם [פייק](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2 "The difference between mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)") לחלק הזה ולהחזיר ממש כזה פשוט את התוצאה שממש מחילה כבר URLים מפורסרים והיה שם איזשהו דיון כזה שבעצם הבנו שזה לא שחור ולבן אין פה תשובה בהכרח 100% טובה לתת את הURLים כסטרינגים אומר שאתה בודק יותר פיסות קוד כי אתה נכנס ליותר חלקים

[\[02:15\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=135s) ואני אישית מרגיש שזה מוריד קצת מהקריאות אנשים חיים חושבים שזה מוסיף לקריאות לשים את הלינקים בטestטים אז זה קצת עניין של טעם אבל מה שלי היה חשוב העיקר שם אני חושב זה לדעת לבחור במודע אם אתה מכניס או מוציא את הפיסה כזאת מהסקופ של הטסט שלך כאילו לדעת שאתה מסוגל להוציא את זה או להשאיר את זה ולדעת מה במה אתה בוחר ולמה אוקיי אז אני אסביר בגדול הוא דיבר על הגest from content

[\[02:46\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=166s) היכולת לעשות פרסing בעצם get your content משתמש בגular expression כדי לעשות פס לכל הURים בקונטנט אז היו כאלה שבחור פשוט לתת content שמכיל את הURLים היו כאלה שבחו לעשות [fake](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec2 "Dynamically creating a fake object (The Art of Unit Testing, 2nd ed., ch. 5)") לגט ופשוט להחזיר מה שהם רוצים ואז לא צריך לכתובנט נורא מסובך שמכיל את הURLים בפנים. שתי הדרכים הם בסדר. דרך אחת כוללת יותר אפלמנטש בתוך היוט ודרך אחת כוללת פחות. זאת אומרת אם אתם בוחרים לשלוח item נק שכבר מכיל את הURL אז בעצם אתם אומרים get your from content הוא חלק מהtest שלי.

[\[03:22\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=202s) אם הוא אם הוא לא עובד אז הטest שלי לא עובד. אבל זה גם אומר שהייטם content האינפוט שלי נהיה הרבה יותר מסובך אז יש מקרים שבהם באמת הייתי עושה פיק לגנ ויש מקרים שלא בדפולט אם אני יכול וזה לא עולה לי ברידביליות או במטנביליות או שלא זה לא מכשנה לכתוב את הטסט יותר מדי אני מעדיף לכלול כמה שיותר דברים בטסט שלי לא להוריד זאת אומרת אני מעדיף שהיוניט of work שלי יהיה כמה שיותר מנופח ויכיל כמה שיותר קוד בצפנים כל הזמן שזה רץ בזיכרון רץ מהר יש לשיטה על כל הדברים readable mable

[\[03:57\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=237s) והסיבה היא שבאמת הדבר הזה הוא נכלל בינט אבור הסיבה היחידה שלי לעשות לזה פייק זה אם נורא קשה לעשות את האינפוט הזה או נורא בלתי קרי הטest שיוצא מזה ואז באמת הייתי עושה לזה פייק כי זה מבחינתי נהיה depפendנency depפendנency זה משהו שאין לי שליטה עליו או שנורא קשה לייצר משהו שיעמוד בסטנדרטים שלי תארו לכם לייצר משהו שהוא out of memory exception זה גם אפט שנורא קשה לייצר אז עושים לו פייק זה סוג של depפendנסing

[\[04:28\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=268s) שתי הדרכים הם בסדר היו כאלה שהצליחו לעשות את הדרך שבה הם לא עושים פיק לגט והטest עדיין מאוד קרי בגלל שהשתמשו בים מאוד פשוטים סידרו את הקוד בצורה פשוטה ובויזואלית הפרידו דברים יפה עם ספייסים הויזואלית של הקוד מאוד חשובה בדברים האלה ואם אתם יכולים לגרום לזה לקרות עם משהו בפנים אז תעשו את אפילו הייתי אומר וואלה אולי אני אפילו יכול לעשות משהו עם remמוט פייל כל זמן שזה משהו לוקי על הדבר הזה ואפילו לקרוא לזהרש test אם אני לא צריך לעשות לזה אקסטרctט וואלה אני אולי אני לא אעשה לזה אקסטר

[\[05:05\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=305s) אני לא דתי בנושא שחייבים לכתוב [unit test](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)") אם הטest עדיין ירוץ מהר והוא יהיה אטגרש test אז מה אף אחד לא עומד מזה אלא אם כן הטest הוא למחשב יחוי זהגרש ואז מישהו יכול לק >> אבל כן >> הבעיה הייתה מבחינתי בזה שכבע בURL הייתה מכשילה את כל הטestטים בבת אחת כולם עכשיו כל הטestטים תלויים בHRF למרות שיש הרבה לוגיקה מעבר טוב אז ולכן זה זה משהו שנתון לשיקול אם אתם רואים שוואלה האינפוט הזה מסובך וגם האינפוט הזה צריך להשתנות כל הזמן כי הדרישות לאיך URL נראה משתנות כל הזמן אז זה משהו שהוא תן לזה

[\[05:47\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=347s) בסדר אין פה תשובה אחת בגלל זה אני קורא לזה [The Art of Unit Testing](https://www.manning.com/books/the-art-of-unit-testing-third-edition "The Art of Unit Testing, Third Edition (The Art of Unit Testing, 3rd ed.)") שזה זה החוכמה היא למצוא את השביל הדג שמחבר בין משהו שהוא readable ומטable לפי מה שאתה אומר וואלה אם אני כולל את זה זה לא בכלל מטable כי מחר אני משנה משהו ופתאום אני צריך לשנות את הרגול אקפרש ובום שברתי מלא test >> אבל לא לא תעדיף פונקציה שתתמקד רק בזה כשאתה רוצה לבדוק את זה ושהשאר ידלגו על החלק הזה אם יכולות >> יכול להיות שאני אבחר שאני אגיד זה depפendנency ואז יהיה לי test במיוחד לג אבל יש יש לי בעיה עם get your content

[\[06:26\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=386s) הוא private method private method ב implementation detail מחר get content לאח regular expression מחר הוא הסתמך על איזה webסרס שעושה ומקבל את זה מface.com איכשהו מאיזשהי צריך שוב כל הטestטים יפלו בגלל שהם ימשו את זה עם זה הם פתאום יהיו איתיים מאוד ואז אני אעשה לזה פלמנטשטל עד אותו רגע לא שינה לי אז לא השתמשתי בו זה פישט להתס ברב אם זה מסבך לי את הטest כשאני צריך לעשות פייק למשהו הטסט הקוד נהיה קצת יותר ארוך זה לא דבר רע אני בדפאולט בדרך כלל הנטייה שלי תמיד הייתה לעשות איזה פייק לאחרונה הנטייה שלי היא קצת אחרת והיא אומרת ככה תכנון יותר דברים אל תהיה יותר מדי דתי בדעות שלך בקטע הזה כי

[\[07:11\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=431s) ככל שאתה תכנון יותר דברים הסיכויים בדרך כלל בדברים האלה שהם expression parcing של url זה בדרך כלל לא משתנה טרקבק זה לא זהסטנדרט זה לא פורמט שמשתנה סתם בתור דוגמה למקרה הזה הספציפי אז יש מקרים שכן יש מקרים שלא זה כל דבר הוא ממש ממש ל ל ל ל ל ל ל ל לגופו ברוב המקרים אני רואה אנשים עושים לזה פייק כי זה פשוט זה הרבה יותר פשוט כי מה שאנחנו בודקים זה את האלגוריתם ואז אם זה מחזיר משהו וזה מחזיר משהו אז זה נקרא

[\[07:45\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=465s) נוגם לא >> לא הפשטות האמתי ההפרדה וזה אני בגלל זה אני לא לגמרי מבין איך זה כי זה או שאתה מפריד את זה או שלא. ואם אתה לא מפריד את זה אז זה תמיד יהיה לא מופרד. תמיד כל בדיקה עכשיו של הפונקציה הזאת תכלול בוודאות את זה. >> נכון בגלל זה זה מפריע לי. לא כיף >> וזה זה ההחלטה שלכם איך לעשות את זה. אני חשוב מאוד שזא תהיה בחירה ולא משהו שהוא לא מודע. ואני חושב שזה מה שאלד אמר והוא צודק >> שצריך להיות בחירה מודעת לא לעשות את זה. לא לא לעשות את זה בגלל שלא ידעת שאתה יכול דווקא לדעת אני יכול לעשות את זה ואני בוחר לא.

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

[\[08:54\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=534s) שאני עשיתי את הטestטים אני לא יודע שאני יש לי איזשהו חוק שאומר מתי כן מתי לא הבנתי אוקיי אז אני אתן לכם א' אני אתן לכם שני חוקים קודם כל אני בדרך כלל קורא פ לדברים שהם אין לי שליטה עליהם טרדים procסים דברים כאלה נגיעה בפיילסיסטם זה בטוח אני אעשה לזה פיק דבר נוסף לגבי הסקופ אתה אומר אני לא יודע מה לבדוק באיזה API לבדוק באיזה API לקבל את את התוצאה לדוגמה יש איזה שורי אומר תמיד שהאינפוטים והאוטפוטים בטסט שלך יהיו באותו לבל זאת אומרת אם בדקת בלבל של הקלאס אז תבדוק את את השאר בלבל של הקלאס אל תבדוק משהו פנימית יותר בקלאס תבדוק בלבל באותו לבל זאת אומרת מבחינת הסקורפט אם אתה בלבל מסוים אל תראה רמה אם אתה לא חייב אוקיי אז לדוגמה הסרט פארטי אם אתה ברמת הקלאס אז קלאס אחר יכול להיות סרט פארטי מבחינתך

[\[09:48\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=588s) טרקבק ‏send זה דוגמה לזה נכון נסנ זה קס אחר אני אני לא חייב לעשות בפיק אבל אז הפוך להיות אגרשט test אבל אני יכול לעשות פיק לדברים בתוך טרקבק נקסנ אם אני באמת רוצה נכון אני יכול לעשות לזה אקסטר ולהפוך לטרקבק לאינסance וכל הדברים האלה אבל מבחינתי היוטור מתחיל פה ונגמר פה אז זה מבחינתי כבר לא באותו סקופ כבר בלבל אחר אוקיי זה עונה לך קצת על השאלה זה נראה יותר מה שאנחנו צריך כאילו להגדיר בתוך הריגון

[\[10:23\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=623s) להגדיר בתוך הערגון לא הייתי אני לא בטוח אם צריך להגדיר בתוך הרגון חשוב שתהיו מודעים לזה שלא תמיד תהיה לכם תשובה נכונה תמיד לא תמיד יש תשובות נכונות יש לי הרבה פעמים הרבה שאלות והרבה תהיות והרבה ניסיונות זה לא משנה כמה ניסיון יהיה לכם תמיד אתם תגיעו למצב שבו לא תדעו מה דרך הכי טובה או הכי נכונה פשוט תצטרכו לנסות ומקסימום תגלו שאולי הייתם צריכים ללכת בדרך אחרת אז זאת אחת העבונות הכי מעניינות שאתה מגיע לאיזשהו שלב אתה אומר אין מצב שאני אדע תמיד מה לעשות

[\[10:54\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=654s) שלב אני חייב להתחיל לקבל איזשהי החלטה וזה לא תלוי רבי אני אז אני יכול לעבוד עם עם עם זוג ואז אפשר לקבל החלטה ביחד אפשר להתייעץ עם עוד אנשים אבל זה בהחלט משהו שאפשר לעשות איתו עליו דיון לא צריך להיות בירוקרטים בנושא צריך לקבל החלטה כל נושא לגופו אסור שלדעתי שיהיה יהיה רק דרך אחת לכתוב את הטestטים האלה. צריך לתת לאנשים שקודים את הטestטים את ה את החופש לבחור את הסקופ שבו הטestטים האלה כתובים.

[\[11:27\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=687s) אבל זה לא אומר שלא צריכים להיות דיונים בנושא הזה. אוקיי? כמו שיש דיונים על הנימינג יש גם דיונים על הנושא של איך לדאוק את הדבר הזה ומה הדרך הנכונה ביותר. ואתם תגלו שזה קורה הרבה. איך כדאי לי לבדוק את הדבר הזה? באיזה סקור, מאיפה נקבל את האינפוט? האם כדאי לעשות פייק לדבר הזה או לא? זה דברים שהם חלק מהעבודה. זה לא דברים שאתם אף שאתם אי פעם תעברו ותמיד יהיה לכם תשובה נוחה לי אין תשובה נוחה אז אני מניח שגם לכם אחרי זמן מסוים לא תהיה תשובה אלא אם כן תגלו מן תיאוריה של התאוריה של הכל שאומרת אה במקרה כזה תמיד תמיד תמיד כדאי לעשות ככה וככה

[\[12:04\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=724s) התשובה היא שמהניסיון שלי לפעמים זה עובד לפעמים זה עובד זאת אומרת היום מקרים שבהם הייתי עושה לזה פייק ושמחתי היום מקרים שאני לא שמח לעשות את זה פייק בגלל שהגליתי הרבה יותר ערך ולא לעשות את זה לכן אין תשובה אחת זה תמיד משתנה בהתם לקונטקסט בקשר הדבר הזה הרי המתודה הזאת היא prive >> המתודה הזאת >> לא get your cont get your contct היא prate prate st >> אוקיי אז אם היא prיבט זה אומר שאני לא יכול לעשות testing שבודקים אותה >> קודם כל אתה יכול >> אם אני לא עושה את הפרט >> אתה יכול לעשות שבודקים אותה אתה יכול לעשות עם reflection אין שום בעיה לisolate יש גם apנקרא isolate הוא מפעיל לך פורים שהם prיט בלי שתעשה את כל העבודה

[\[12:50\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=770s) של הבילר פלי של לעשות אבל אתה יכול היום להפעיל מה שאתה רוצה >> אז אם זה ככה אני ישנה את השאלה שלי האם באמת אנחנו צריכים להתייחס ליבט לפאבליק אחרת שאנחנו בונים טסטים >> אני מתייחס לזה אחרת בגלל שגיליתי שאם אני לא מתייחס לזה אחרת אז הטestטים שלי נהיים הרבה פחות מטם אבל יש גם הסכולה שאומרת וואלה חבר'ה אם אם באמת get your content זה פונקציה שהייתם רוצים לבדוק לבד זה אומר שהפונקציה ש צועקת לכם תהפכו אותי לפאבליק תהפכו אותי לפאבליק הלפר מט בקלאס נפרד והיא אומרת לכם שהדיזיין שלכם יכול להיות שצריך להשתנות זה בהחלט משהו שהוא ולידי להגיד אוקיי זה prיט אבל זה לא אומר שזה חייב להיות פרייט אולי אני אעשה את זה פריט ואני אכתוב לזה טestי במקרד בהחלט אפשרות אה אני אני רוצה להוסיף על זה ולהגיד אני חושב שזאת לא אפשרות עם דוקטורים שהם prיבט

[\[13:39\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=819s) כאילו אני חושב שכדאי שנעבור תהליך של הגדרת קונבנציות פה של מה מה כדאי לעשות ואני אני באופן אישי הולך להיות >> בלגסיקוד זה קצת בעיה להגיד שאין אפשרות כי בלגסיק all better off >> אני לא מסכים לא מסכים איתך >> למה מה אתה הפונקציה הזאת >> הפונקציה הזאת כאילו נגיד אם אם הרגשת דגדג לך שאתה רוצה לבדוק את הקטע שמפרסר אז זה בדיוק מה שהייתי עושה הייתי עושה את זה פאבליקסטיק whatבר במקום אחר פשוט חשוף והייתי בודק אותו הלוationשן

[\[14:10\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=850s) אי אפשר לקחת את האמירה שזה לגס זה המערב הפרוח ולכתוב שם טestטים שהם קקה אי אפשר לעשות את זה צריך כאילו להיות רוב הסיכויים שיהיה לכם טסטים אתם לא תהיו גאים בהם אבל הם מביאים עכשיו רמה מסוימת של ידע של משהו עובד ואחרי זה אתם יכולים לאט לאט לשנות את הקוד ואז להיפטר אחרי זה הסיבה לכתסטים יותר טובים אבל אתה לא יכול לחיות בעולם מושלם ולא יהיה לך זמן לשנות את הכל ולהפוך אותו לפאבליק וכן בעולם האמיתי שלי הייתי הופך את זה לפאבליק והייתי בודק אותו ונפרד כן לחלוקים אבל זה לא אומר שמה שנכון בקונטקט שלי נכון בקונטקסט שלכם הייתי אומר וואלה זה נכון זה משהו זה גול לשאוף אליו לא לבדוק prייטים

[\[14:50\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=890s) אני לא ראיתי עולם מושלם שבו אתה תמיד עומד בעקרונות שלך בקוד של >> אני לא פשוט לא מצליח לעשות על דעתי דוגמה שבה אני לא אצליח להזיז את זה מהפרייבט אם אני רוצה לבדוק את זה >> בסדר אבל זה לא אומר שאין דוגמה יש לך >> בצות שלכם אני עוד לא מכיר אותו מספיק השאלה שלם אתה יכול לעשות את זה פבליקט בשביל שתוכל לבדוק את זה זה גם שאלה >> שמ הייתן לך דוגמה למשהו משהו שכמעט בלתי אפשרי לבדוק בלי בלי לעשות משהו ברמה שהיא לא פאבלי כשיש לך קוד שהדפendנס שלו הוא סתם הוא לא סתם קריע למשהו שהוא חיצוני אופר prיט אלא קוד שיורש ממשהו שהוא לא שאתה תלוי בו והוא לא המימוש שלך קוד שהביס שלך לדוגמה הואפ

[\[15:32\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=932s) ואתה רוצה למחוק את הדependencies ואז אתה צריך להתחיל לעשות פייקים בפרי בגלל שאין לך ברירה כזה כי הטייפים שאתה יורש מהם הם prיט וסיד וכל הדברים דברים האלה ואז הם נחמות אז זה מאוד תלוי בדיזיין ובפרימוורק שאתה תלוי איתו אז ברגע שיש לך נגד קוד שחי בתוך פריימורק שהוא לא שלך זה סוג הדברים שבהם הדפנס כל כך חזק שכלים פרופיילר basols אין לך כמעט ברירה ואתה צריך מה שנקרא ממש לגדוע ככה מלמטה ולהגיד זה פייק זה פייק זה פייק הדברים האלה כל מה שהוא בטיפ הזה הם פייק גם prיטינג וגם כל הדברים האלה זה שונה ממה שדיברנו >> אתה לא יכול להפוך אותם לפסיק זה לא הקוד שלך אתה אתה אתה אתה מבלבל פה בין אתה דיברת על לקחת פרייטים ולעשות להם פייק כי זה אחלה אוקיי הוא דיבר על לקחת את הפרייט ולבדוק אותו שני דברים שונים

[\[16:22\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=982s) לקחת פרייט ולבדוק אותו שנראה זה שונה וזה לא שונה גם זה יכול להיות אחד תראה זה זה לא דיון תיאורטי כן יש מקרים כאלה שאסור לך להפוך משהו לפאבליקסקיורטי טריפס כל הדברים האלה יודע להפוך משהו מאינטרנל ללא אינטרנל זה אפילו לפני פרפורמנס יכול להיות שינוקש גם >> יש יש סיבות לא להפוך משהו לוטואל אני שמעתי מפה כמה אנשים שאומרים אם תהפכו את זה לוירטואל זה יערוץ לך הרבה יותר לאט

[\[16:52\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=1012s) אצלכם פרפורמנס יכול להיות משנה C++ זה מאוד משנה אז זה לא שזה הייתי נמנע מהצרות גרופות אבל הייתי אומר יש איזשהו איזשהו אידיאה לשאוף אליו וזה מין איזשהו משהו מכבה זה לא אומר לתת איזשהו אה קו אדום שאפשר להזיז אותו זה אומר שבקוד רויו אם יש ברירה אז יש ברירה עורסים אותה תמיד וזהו אבל אם אין ברירה אז אין ברירה לא צריך אה

[\[17:23\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=1043s) עברתי מספיק כדי לא לתת הצרות גורפות כל העצרות הגורפות הם לא נכונות זה מה שאני אומר תמיד אוקיי כן עוד שאלות אוקיי מה שנעשה עכשיו עד סוף היום כל זוג הולך לבחור חתיכת קוד אמיתית פרודקש קוד ולנסות לבדוק אותם. אל תלכו על משהו מסובך מדי. תיקחו משהו שבא לכם לבדוק שאתם חושבים שאתם יודעים איך לגשת אליו. תבחרו משהו ששניכם נראה לכם שיהיה לכם כיף לבדוק אותו.

[\[17:55\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=1075s) יכול להיות משהו שמפחיד אותכם, יכול להיות משהו שסתם מעניין אותכם לראות איך לבדוק את הדבר הזה. ואנחנו ננסה לפתור את זה עד הצופים. אוקיי? לכתוב לפחות שניים שלושה טestטים על קודקשן על הקוד האמיתי שלכם. והטestטים האלה הולכים להיכנס לסור קנטרול ולרוץ בקר >> למי שלא מודע יש פרויקט לטestטים גם בסולט וגם בסולוטו אוקיי כאילו יש כבר פרויקטים לצלם את זה >> שכבר רצים שלום אז כאילו תחברו לזה אותו דבר >> אם אני מזכיר לכם לגבי זה שיהיה לכם לשים אם אין לכם פרויקט שיש לו בשם unit test אז זה הזמן להתחיל אחד כזה

[\[18:38\]](https://www.youtube.com/watch?v=8JAPnkm18-A&t=1118s) >> אוקיי כן

## Related

- [Avoid testing private or protected methods](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8#sigil_toc_id_160) · The Art of Unit Testing, 3rd ed., ch. 8

    Book section on avoiding testing private or protected methods, the debate the group has in this discussion.

- [Pros and cons of designing for testability](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-11#ch11lev1sec3) · The Art of Unit Testing, 2nd ed., ch. 11

    Pros and cons of designing for testability, matching the point that the refactorings made code testable, not better designed.

- [Properties of a good unit test](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec2) · The Art of Unit Testing, 2nd ed., ch. 1

    Properties of a good unit test, such as fast and in-memory, the criteria Roy uses to decide what to fake.

- [Ensuring tests are part of source control](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec3) · The Art of Unit Testing, 2nd ed., ch. 7

    Ensuring tests are part of source control, as the tests written by each pair are committed.

### Also linked in this lesson

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

- [Setting up and tearing down](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9#sigil_toc_id_171), ch. 9
- [The Art of Unit Testing, Third Edition](https://www.manning.com/books/the-art-of-unit-testing-third-edition)
- [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

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

- [Variations on refactoring techniques](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5), ch. 3
- [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4
- [Dynamically creating a fake object](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec2), ch. 5

#### osherove.com

- [Unit Testing Entry and Exit Points](https://osherove.com/blog/2020/3/12/unit-testing-entry-points-and-exit-points)

[Previous lesson Refactoring- Introduce Instance Delegator](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/refactoring-introduce-instance-delegator/) [Last lesson Back to the course overview](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/)


---

## 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/