---
title: "Best Practices Continued"
url: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/best-practices-continued.md"
canonical: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/best-practices-continued/"
tags: []
author: "Roy Osherove"
description: "Lesson 17 of 22 in TDD in .NET in Hebrew (Day 3 - Unit Testing Practices), 25:20. 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/"
---

# Best Practices Continued

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 17 of 22

Duration: 25:20 [Watch on YouTube](https://www.youtube.com/watch?v=50LeVOHrplA) Spoken in Hebrew

## In this lesson

Roy Osherove advises against tests that depend on each other's order and against [magic numbers](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9#sigil_toc_id_169 "Magic values and naming variables (The Art of Unit Testing, 3rd ed., ch. 9)") such as a 37 in the Unity tests, preferring the simplest value or a named variable. He shows an [ASP.NET MVC](https://osherove.com/blog/2009/3/21/test-review-2-aspnet-mvc-unit-tests.html "Test Review #2 – ASP.NET MVC Unit Tests (osherove.com)") [test helper](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec6 "Building a test API for your application (The Art of Unit Testing, 2nd ed., ch. 7)") that builds a [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)") HTTP context with [Moq](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec5 "Current isolation frameworks for .NET (The Art of Unit Testing, 2nd ed., ch. 5)") and is full of ifs, suggests overloads instead, and wants [expected values hard-coded](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7#sigil_toc_id_142 "Logic in asserts: Creating dynamic expected values (The Art of Unit Testing, 3rd ed., ch. 7)") rather than computed, so a production bug is not repeated in the test. Reviewing a [NerdDinner](https://osherove.com/blog/2009/3/20/test-review-1-nerddinner.html "Test Review #1 - NerdDinner (osherove.com)") test named "should be valid when all properties correct", the group debates splitting it into [one test per validation rule](https://osherove.com/blog/2011/2/9/multiple-mocks-asserts-and-hidden-results.html "Multiple mocks, asserts, and hidden results (osherove.com)").

## Transcript

3,677 words

[\[00:03\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=3s) על שני אובייקטים שונים זהפל result ואז אכפת לך אז זה לא איזשהו משהו דתי שצריך להגיד עם הסרט אחד בקטקסט אבל זה קונספט אחד שנמצאת בקטסט אדלט אחד אוקיי אז אז אם אני רואה אובייקט אחד בשני הסרטים מתחיל הייתי אני אגיד לך אומר זה לא נורא אני בודק person name ו number ואם הני נכשל אז מתלכתחילה כבר כל הפרסון לא בסדר אז זה בסדר זה לא כזה נורא אבל אם אני רואה person A נקודה A name ופר B נame ואז יכול להיות ששני אנשים זה כבר משהו שונה או מנג'ר כן באופן כל יותר כמה מה שרב שואל מספרן אותי

[\[00:39\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=39s) אה יש איזשהי דרך להגיד depפendנen testing להגיד שאם test אחד נחשל אל תמשיך הלאה או תראה לי רק את הראשון אני בדרך כלל ממליץ שלו זה לא יהיה אני יש דרך במסט test להגיד שטestטים יראו אותו בסדר מסוים אבל לא dependency בין testing אוקיי עכשיו הסיבה היא שאני לא ממליץ על דבר כזה זה בגלל ש המינטנבity שלהם נפגע מאוד מחר אתה מזיז test אפילו או אתה מוחק אותו ופתאום טestט אחר נחשב שבכלל לא חשבת שהוא קשור לזה ולכות שהטestט הזה הוא עדיין בודק אין רזלט אחר אם הטestטים האלה יכולים לראות בנפרד אז אני מעדיף את זה עכשיו פה הנימינג מאוד חשוב אני שובר פיצ'ר וחמישה טestטים נכשלים

[\[01:25\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=85s) אוקיי אני מסתכל על השמות שלהם ואני רואה וואלה הסצנריו שלהם שונה לחלוטין או הendat expted behav יכול להיות שיש לי חמישה behaviס לפח להבין את זה אז כן יש סיבה שכל הטסים נמצאים שם אני מעדיף שיהיה לי חמישה טסים שנכשנים מאשר אף אחד שלא נכשל בסדר ופה באמת יש לך חמישה שנכשלים אם אתה רוצה לדעת לאיזה להתחיל לדבק השמות מאוד חשובים פה כי אתה רואה שיש אחד עם הסנריו הכי פשוט זה זה שאתה תתחיל איתו בסדר

[\[01:57\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=117s) עוד שאלות יש עוד דברים שאתם לא אוהבים בטסט הזה? אה, אחלה. >> למה 37? כאילו 37 הרוצח הסדרתי יבוא. כן. >> לא ברור לי. הR אקל הראשון מה הוא משווה? הוא משווה טיפים >> לא R equal משווה vales. אם אתה רוצה להשוות טיפים אז אתה עושה Rame זאת אומרת לוודא שהיance הזה והאינס הזה זה אותו אינסטנס. כן. אבל זה לא קונסטר

[\[02:29\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=149s) משהו לא ברור >> הקונסטרקטור infו זה משהו שרפלקlectionקש מחזיר unity הוא מערכת שמשתמשת הרבה ברפלקשן אז בעינתן שאתה מוצא משהו אתה מקבל חזרה את המידע הנכון הוא עדיין בודק את הוליו של הקונסטרקטור אינפו יכול להיות לך שני קונסטרקטור אינפו שמתארים את אותו קונסטקטור בסדר אמ בעייתי מאוד כי אף אחד לא יודע מה זה 37 זה יכול להביא לצרות מאוד מאוד מעניינות. בן אדם כותב טestט חדש והוא אומר איך מישהו כבר כתב טסט?

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

[\[03:34\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=214s) ולפעמים פשוט אין שום דרך לגלות את זה אז לא להשים מספרים כאלה במקום זה לשים או את המספר הכי פשוט או לתת שם של משתנה שאומרס number מאוד חשוב בטestטים להגיד מה לא חשוב בסדר להגיד למישהו אל תתרכז בזה זה לא ה זה לא האישue פה בגלל זה גם פה הסנר הוא מאוד חשוב זה הפטד resultל אם יש לי את כל הסרטים האלה והיה לי פה איזשהו expectectד resultלט נורמלי כי יודע איזה מהסרטים חשוב אבל בדרך כלל אם יש לי מטיפלט שבודקים כמה דברים אז זה מאוד הגיוני שיהיה לי קשה מאוד לפתור expectד resultלט

[\[04:10\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=250s) ז ככל שאתם בודקים יותר דברים ככה לתת שם לטest יהיה הרבה יותר קשה כי השם יצטריך להיות הרבה יותר גנר הנה עוד דוגמה ללוגיקה זה מ-ASP.NET MVC [ASP.NET MVC](https://osherove.com/blog/2009/3/21/test-review-2-aspnet-mvc-unit-tests.html "Test Review #2 – ASP.NET MVC Unit Tests (osherove.com)") זה לא test זה helper methodד של test הלפרer metוד הזה משתמש

[\[04:40\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=280s) במק [Moq](https://osherove.com/blog/2012/6/27/the-future-of-isolation-frameworks-and-how-moq-isnt-it-for-n.html "The future of Isolation frameworks, and how Moq isn't it (for now) (osherove.com)") ומה שהוא עושה זה הוא הלר שמחזיר [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)") htp contct אחד הדברים האיפים שהם עשו בhp. ‏MVC זה הם עשוי את הזign קצת יותר testable זאת אומרת אתה יכול לעשות fake לhtpx base ורוב הפונקציות שם הם virטס מה אני אומר שאתה יכול להחזיר מה שאתה רוצה מquest application וכולי אז הלפר הזה testים יכולים לקרוא לו ולקנפג איך נראה הHT קנטקסט שלהם

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

[\[05:55\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=355s) כי למצוא את הבאג בטestטים זה ממש קשה למצוא את הבאג בהלפר של הטestטים זה ממש ממש באסה כמו שגיליתי בשבוע שעבר נזכרתי עוד פעם כמה זה באסה כי בדיוק מה שהיה לנו זה הלפרer metod שמגנרט לוח של ופה זה הלפר מוד שמגנרate htp contטקס אם הוא מקנפג אותו בצורה לא נכונה אתה מחפש איזשהו בג שבכלל לא קיים בפרודקש זה יכול לבזבז המון זמן אז איך נפטרים מזה אחת הדרכים הכיות זה לעשות ורסיה של htpקטeקסט פר פרמטר זאת אומרת לעשות אוברלים ואז אין שום שאלה אם להשתמש בפרמטר או לאפונקציה

[\[06:30\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=390s) הזאת תמיד משתמשים בפרמטר הזה אתה לא רוצה את הפרמטר תקרא לפונקציה אחרת אוקיי ואז אתם מפטרים מכל האיפים האלה וזה יעבד כעשיתי קוד רוw ראיתי שרק שני טestטים משמשים בפונקציה הזאת אז בכלל לא היה צריך את כל הלוגיקה עשו לזה overרing לכתחילה שאלות כן >> באופן כללי פנ כמו שיש לנו זה לא אפשר ש לעשות כאילו נגיד אסמלי של הלפר ליוט testing נגיד בקונטקסט מסוים ואז להעריץ לו גם בליקות לכתוב לו באמת testסטים ואז יהיה אפשר להשתמש בזה הדבר היחיד שבאב הייתי אומר לפעמים אתה צריך פילפרים מסובכים וואלה תכתוב להם טestטים

[\[07:12\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=432s) בדיעבד היום אני אכתוב טestטים לזה של ללוח של הגוב אני לא אשתמש בטסטים הקימים שלי כדי לבד שהוא עובד כי אתה צריך לסמוך על זה שהוא עובד כבר >> כלומר להפריד את זה ול >> אם אין ברירה אז אין ברירה וגם זה צריך לכתוב טסטר כי ההשפעה של בג בזה היא הרבה יותר גדולה מההשפעה של בגוד של קודם כי זה משפיע הרבה טestטים שמשפיעים על פודק של ואז כל הטסט של הרבה אבל בדרך כלל אתם לא תסתרכו דברים מסובכים זה חשוב מאוד 99% מהזמן אתם לא תסתחו דברים מסובכים בהלפר metodס מתי זה כן נהיה מסובך הפעם פעמים יחות שראיתי שזה נהיה מסובך זה כשאתם מתחילים לכתוב דומיין specific langו לקונפיגורציה של הטest לפעמים צריך את זה כבר מתחיל להיות מסובך.

[\[07:55\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=475s) זאת אומרת אתם כותבים איזשהו DSL שבו אתם אומרים אני רוצה אובייקט שנראה ככה ועם כל הדברים האלה ושמה וואלה כבר אתם מתחילים לכתוב הרבה comון cדde ושם צריך כי אחרת אתם מקמים אוי שמגונפג לא נכון וכל הטestים שלכם מתכתחילה הם כבר לא נכונים אבל לבדוק את זה זה זאת אומרת להבין שזאת הבעיה אז מאוד קשה בהתחלה עוד שאלות אוקיי עוד דברים חשובים שקורים כל הזמן בטestטים כדי לסמו מוך עליהם אני מוודא שאין לי לוגיקה

[\[08:28\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=508s) בexpected values. זאת אומרת תמיד ב expectect values אני מנסה לוודא שאני אף פעם לא מייצר אותו בצורה דינמית כי אם אני מייצר את הxpectד val בצורה דינamמית רוב הסיכויים שאני גם חוזר על production קודם זאת אומרת אם אני מצפה לקבל user + פסיק + פwסיכויים שבprפודקt קודש לי user + פסיק + password ואז אם יש לי באג נגיד שחסר לי ספייס אני משחזר את הבאג הזה בטestטים שלי ואני לעולם לא אמצא אותו הטestטים שלי יעברו זאת אומרת תמיד עדיף לי וectד ‏val בit testing לא בintegration testit testing

[\[09:03\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=543s) לקבל hard coded vales expected לקבל את הס כמו שאמור להיות לקבל את ה כמו שאמור להיות וככה להגיד וואלה לא אכפת לי איך משהו מיוצר אכפת לי שהוא נראה ככה בסוף או שהוא מכיל משהו שנראה ככה בסוף ואז מחר האלגוריתם יכול להיות אחרת לגמרי או שאני אגלה הרבה יותר מהר את הבאגש אז אם אתם רואים פלוסים או כל דבר שמיוצר דינמיק בעסרט שלכם בect value תראו אם אתם יכולים לעשות הרקוד את רוב הסיכויים שעדיף שזאת אופציה עדיפה ואם אתם לא יכולים כי אתם כי לא הרבה פעמים אנשים עושים test cases ואז הם מחשבים את הPected value מהtest cas אבל מה שפשוט עושים זה פשוט שולכים גם את הPectate value בtest cas או שעושים result שווה אנחנו בטest

[\[09:55\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=595s) זה כמעט אף פעם לא לא הדרך הטובה ביותר לעשות את זה ביטר וואלה תעשו מה שאתם רוצים יש לי את ההפייפס שעובד ועליו זה השלט שלי ואחרי זה אני יכול לבדוק עליו עוד מיליון דברים שאלות אוקיי כדי לסמוך על הטestטים שלי אני מוודא שתמיד הטestטים שלי הם אותם testים אז אני לא משתמש בדברים שמשתנים time now אני לא משתמש בו בטestטים שלי אני אני תמיד משתמש באיזשהו הרדקודיט והסיבה היא שכל פעם שאני אריץ את זה אני רוצה שזה יהיה בדיוק אותו טס אותו טestט כל דברים כל הדברים שקשורים מטקם

[\[10:30\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=630s) וכולי זה דברים שאני מעדיף לעשות הרדקוד אני לא משתמש בפרדים אני לוקח את הלוגיקה שרד אמור להריץ ואני אבדוק אותה כunity of work 1 הנה דוגמה לטest זה מנדנר [NerdDinner](https://osherove.com/blog/2009/3/20/test-review-1-nerddinner.html "Test Review #1 - NerdDinner (osherove.com)") זה אחד הפרויקטים לדוגמה שמייקרוסופט הוציא הראשונים של שימוש ASP.NET MVC

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

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

[\[12:32\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=752s) בעיה 92 >> כן >> וגם הט הוא גם כן בעייתי time now זה אומר שהטest הזה משתנה כל הזמן כל הקנactפ טוב קודם כל תתחילו מהשם תשימו לב should be valid when all properties correct what the fuck does that mean all properties האם אלה כל הpties correctקט בהם מהקורקט בטלפון הזה שיש בו את הקווים כמות הקטרס מה מה קורה מה קורק בhosted by

[\[13:04\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=784s) שהוא שהוא קיס אין שום דרך לדעת מה קורה בלטוד ולונדיטוד אתה גם לא תדע מה קרוב לזה להיות לא וליד >> נכון והשאלה אם יש טestטים הפוכים לזה התשובה היא לא יש טestט אחד שגם שם זה נראה בערך רחוק מזה יש לך איזה משהו ואחד מהם לא קורה אמ אז is true is valid אז מה בעצם הייתם עושים עם הטest הזה לדעתכם?

[\[13:35\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=815s) מפרקים אותו. מפרקים אותוכמה טestטים >> עברו כל propפרטי לפחות טestט אחד או שניים נכון >> 1 2 3 4 5 6 7 תשעה טestטים שונים לפחות >> מה אבל בספר שזה גם לא בודק את זה ככה זה בודק בטח טלפון או מייל כל אחד זה פדיקה שנהכל >> ספציפית זה בגלל שאם זה mVC אז הבדיקה היא באמת סוג מסוים של בדיקה כלומר valid זה משהו שהוא חלק מMVC כן אז הדיקה כאן מלכתחילה היא לא אני לא חושב שהיא נכונה בקונטקסט הלי צריכה לבדוק את העניין של הולידטורים עצמם נגיד require validat compare validat

[\[14:17\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=857s) זאת אומרת במקום לבדוק את זה אבל תחשבו שזה סוג שלגרשט אח שכל הליידור בגדול test לכל ולידור או אני הרבה יותר הייתי מעדיף לא אכפת לי מה זה ולידור ומה זה ומחר יהיה לי מגנון אחר לעשות ולידציה זה שהalידור עובד זה לא אומר שיד אתה מסכים איתי זה implementationil ולכן מה שהייתי מעדיף זה שכמשתמש אני אבדוק משהו עם אריזל שאכפת לי ממנו כמשתמש אז כמשתמש אני רוצה שיהיה לי טסט שאומר אני מייצר דינר שבו הכל ולידי מלבד

[\[14:54\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=894s) אחד ואני רוצה לראות שזה אינולד ואז הכל ולידי כולל האחד הזה ואז זה וליד וככה לכל אחד מהדברים האלה עכשיו איך עושים איך מייצרים טestט כזה איך מייצרים טestט שבו יש לי תשעה סוגי ולידציה ואני כל פעם רוצה לוודא שכל השאר הם ולידים יכול להיות שפה ליצור את כל הולידים זה מאוד קל אבל לפעמים ליצור את כל הלי val מאוד מסובך ואז לכתוב את הטest נהיה מאוד מסובך אחת הטכניקות שאני אוהב זה להשתמש בקס שהוא testable ולעשות לכל validation functionנש איזשהוטל מפוד שמחזיר בוליה

[\[15:30\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=930s) ואז בtestable אני פשוט עושה פגים מה כל אחד מחזיר מלבד אחד שאני לא מממש תחשבו על זה שיהיה לי is title valse שזה protected virtual is desption valestable שבו אני אומר תראה בנתן שdcription ו כולם מחזיריםט י אתה משתמש בליטור האמיתי או שהוא מחזירפse האם is valid באמת מחזירפse זאת אומרת אני בודק את האלגוריתם שמשתמש בכל הalidation

[\[16:02\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=962s) יש לי הרבה דרכים צריכים לבדוק את זה אבל הרבה צריכים להשתמש בזה האם הולידטור זה אמיתיים או בלי וזה כבר החלטה שלי אבל מבחינת ההפרדה הפרדת רשויות פה הרבה פעמים האקסטרctט לאoverיט מה שעשינו פעם קודמת עובד מאוד יפה והטest הוא גם מאוד קרי אני מייצר איזשהו testable דינר ואני אומר זה הולך להיות פס זהפס זהפס אה והדבר הזה אני הולך לבדוק אותו ופתאום זה ממש נראה קל וקרי והרבה פעמים בלגסיק עוד מגיעים למצבים כן יש במצב הזה לא יותר פשוט נגיד ניקח את אותו קוד שיש לנו כאן ולניח שאני כן יודע מה זה סיטואציה שהיא אמורה לעבור נניח את כל דבר ולידי אז זה לא דוגמה שאולי כן יהיה לך מן לעשות כאן פשוט מולטיפליי הסרט פשוט כל פעם לערוך שדה לעשות ואז אני יודע בסופו של דבר אם זה ולילי או לא ולילי ויתי זה ביחידת קוד אחד יש לי קריאה אוקיי מה אתם חושבים

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

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

[\[18:20\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=1100s) על הפרט של המודל זאת אומרתק contנטרctפ בודק לtitט יכול לבדוק nonנג number או משהו כזה >> אז בעצם מה שאתם רואים זה שהטest הזה דווקא בסדר הוא במקרה זה לא בסדר כי הוא לא עונה על השאלה אם היו מוסיפים לו עוד הסרטים ומנסים להכשיל אותו אז הוא היה תחשוב על זה שבעצם הוא תשעה הסרטים בבת אחת הפרטיזם כולם >> כן אבל זה אני אומר נגיד הדבר הזה אני יודע שזה דבר שהוא תקן שהוא עובד הייתי אולי גם נותן לשמות שיהיה ברור שזה עובד ואז הייתי מוסיף עוד הסרטים שמכשילים את זה שדה שדה

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

[\[19:31\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=1171s) של איך שפ אמור להראות בכלל קשור לזה שאני בודק שהזיד איך שהוא מתנהגיד הוא יחזיר טר עם כל השדות שלו מחזירים טר וזה הוא בלטין בפור >> כן הוא בלטין של הפרק אתה לא אתה לא כתבת >> אבל איזיד כבר נבד מבחינת מייקרוסופט כי הוא כבר בודק את כל הפרט >> לא אבל אתה לא יודע איזה ועלות הם מופלים זה פשוט יעשה בודק האם אחרי הזונ קרה המסטרפן שלקשפ number >> קרה מה זה שאם אחרי is valid האם קרה נקרא פונקציה של שבודקת ולידציה של טלפון ושל של 20 >> אה אתה בודק שהפונקציות נקראו של זה הנחת נוס של הפריורק אתה לא צריך לבדוק את זה אני חושב שקלח אין צורך לבדוק את הפריור במק זאת אומרת אם e valid פונקציה שאתם כתבתם exrct over יכול להיות שפתאום יש פה הרבה היגיון אם valונקציה של הפריורק אז יכול להיות שזה יותר קרי לעשות set לכל לכל לכל propפרerטי אבל עדיין אני פוחד שהייתה לי בעיה

[\[20:27\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=1227s) שאם הסרט הראשון יחר אז כל האחרים מתחתיו לא רצים כי זה לא סתם propפרerטי לאותו אובייקט כל propפרerטy הוא feature תחשבו על זה שכל propפרerטy feature שאתם יכולים לעבוד עליו ביום נפרד אוקיי זאת אומרת אם אם פיצ'ר אחד נכשל פיצ'רים אחרים יכולים להמשיך לעבור זה לא אותו דבר כמו אם ה אם הבדיקה של הפונבר נכשלה אז כבר לא אכפת לך מכל הבדיקות האחרות כל ולידטור הוא פי בפני עצמו

[\[20:59\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=1259s) במקרה הזה אני חושב חושב שלא בטוח שהייתי עושה את כל הסרטים באותו טestט כי יכול להיות שהולידורים האלה משתמשים באיזשהו common cde שאכפת לי מם יכול להיות שהם לא אבל זה פיצ'רים נפרדים גם דרך אגב לגבי אולי הסנריוז אני לא בטוח >> בתרחיש הזה אפקטיבי זה נראה לי הגיוני כי האובייקט הזה הוא אובייקט קטן ו >> אבל זה לא האובייקט שנפדק זה הולידציות על גבי האובייקט וכל אחת מהולידציות היא פיצ'ר נפרד זה לא האובייקט עצמו נכון אתה לא בודק את זבלית

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

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

[\[22:36\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=1356s) >> אז אמרתי אם הולידטור הוא cumם ולידור שהחלטתי לוגיקה משלו אז הייתי צריך לבדוק את הלוגיקה של הולידטור רק על הולידטור >> אבל אם אתה אתה רוצה לדעת שלכל שדה כאן יש ולידטור אז איך תעשה את זה תעשה עכשיו תשעה ולידטורים דבר ש אם הייתי עושה הייתי עושה תשעה סרטים הייתי עושה יותר כי לעבור כל הסרט אתה בודק גם עם מצב שהוא לא נכון. היה כאן נגיד 20 משהו בסגנון. השאלה היא מה התרחיש שיש לך של הצלחה וכישלון?

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

[\[23:44\]](https://www.youtube.com/watch?v=50LeVOHrplA&t=1424s) זאת אומרת הסרטים מכילים אולי את המסג הנכון והסנריו הנכון. זאת אומרת נגיד לפחות המinמimמum valid vales פה צריכים להיות ולא magic vales. כן אני עדיין לא הייתי מפריד את זה מכיוון שהעלות שלכתוב וואלה עוד אוקיי עוד שלוש שורות קוד ולידטור זאת האמת שטויות. זה לא שזה לא שאתה הולך להדפיס את הדבר הזה או משהו כזה. נראה שבעיקר הוצאה הסופית שיש הבדל בין להגיד דינר לא ולידי לבין להגיד אדרס עכשיו הוא לא ולידי או אדס לבדוק הייתי רוצה לדעת שאם מחר מישהו בא וסאבי תיקן את הרגס של הפונ number אז הטest של הפונ number נכשל לא דינד נכשל

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

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

## Related

- [Test Driven Validation Logic with Extract & Override](https://osherove.com/blog/2012/5/16/test-driven-validation-logic-with-extract-override.html) · osherove.com

    Takes apart the NerdDinner validation test the group debates and rebuilds it test-first, one rule at a time.

- [Logic in asserts: Creating dynamic expected values](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7#sigil_toc_id_142) · The Art of Unit Testing, 3rd ed., ch. 7

    Logic in asserts: dynamic expected values, the reason the lesson wants expected values hard-coded.

- [Two different ways to create bad logic in unit tests](https://osherove.com/blog/2010/8/14/two-different-ways-to-create-bad-logic-in-unit-tests.html) · osherove.com

    Explains production logic repeated in tests, the risk of copying a production bug into the test.

- [Magic values and naming variables](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9#sigil_toc_id_169) · The Art of Unit Testing, 3rd ed., ch. 9

    Magic values and naming variables, as with the unexplained 37 in the Unity tests.

- [Test Review #2 – ASP.NET MVC Unit Tests](https://osherove.com/blog/2009/3/21/test-review-2-aspnet-mvc-unit-tests.html) · osherove.com

    Roy's review of ASP.NET MVC unit tests, the source of the Moq fake HTTP context helper shown here.

### Also linked in this lesson

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

- [Building a test API for your application](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec6), ch. 7
- [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4
- [Current isolation frameworks for .NET](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec5), ch. 5
- [Dynamically creating a fake object](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec2), ch. 5

#### osherove.com

- [Test Review #1 - NerdDinner](https://osherove.com/blog/2009/3/20/test-review-1-nerddinner.html)
- [Multiple mocks, asserts, and hidden results](https://osherove.com/blog/2011/2/9/multiple-mocks-asserts-and-hidden-results.html)
- [The future of Isolation frameworks, and how Moq isn't it (for now)](https://osherove.com/blog/2012/6/27/the-future-of-isolation-frameworks-and-how-moq-isnt-it-for-n.html)

[Previous lesson Unit Testing Best Practices](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/unit-testing-best-practices/) [Next lesson Maintainability Practices](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/maintainability-practices/)


---

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