---
title: "Introduction"
url: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/introduction.md"
canonical: "https://courses.osherove.com/courses/tdd-in-net-in-hebrew/introduction/"
tags: []
author: "Roy Osherove"
description: "Lesson 1 of 22 in TDD in .NET in Hebrew (Day1 - Unit Testing and TDD 101), 33:07. 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/"
---

# Introduction

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

Lesson 1 of 22

Duration: 33:07 [Watch on YouTube](https://www.youtube.com/watch?v=gtRXDuLj8uc) Spoken in Hebrew

## In this lesson

Roy Osherove lays out the three days ([unit testing](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)") basics, [mock objects](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)"), [legacy code](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)")) and separates unit testing, how to write tests, from [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)"), when to write them. He asks why teams with many tests still give up on them: [tests that check nothing](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7 "Tests that don’t assert anything (The Art of Unit Testing, 3rd ed., ch. 7)"), tests that cost too much to maintain, and unreadable [test names](https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html "Naming standards for unit tests (osherove.com)"). He defines a unit as a [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)") that starts at a public method and ends in a return value or exception, a [state change](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec7 "Testing results that are system state changes instead of return values (The Art of Unit Testing, 2nd ed., ch. 2)"), or a [call to a third party](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_19 "Exit point types (The Art of Unit Testing, 3rd ed., ch. 1)") such as a logger.

## Transcript

4,713 words

[\[00:03\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=3s) כמה אנשים פה יש ניסיון עםסים אוקיי למי יש ניסיון עם obקטס דברים כמוס בערך בסדר כמה אנשים שמעו בכלל testing כמה אנשים חושבים שזה רעיון טוב יופי מצוין כאילו מין שאלה כזאת מוזמינת אבל תכף נדבר אם זה באמת רעיון טוב או לא משה מתכוונים כל הסיידים שאתם תראו פה אפשר להוריד בPDF אחד גדול פשוט תלכו הURL הזה ותורידו את זה. אני נסה לא להרוג עקסים כמה שאפשר.

[\[00:36\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=36s) חוץ מזה מרבית הקורס הזה הוא בכלל לא סליידים אלא מרבית הקורס הוא כל כך קידוד. אז כאן אני אסביר לגבי השלושה ימים היום זה יום שמדבר על unit testingd ברמת הביסיקס בלבד. אנחנו לא נכסה מ objects בכלל אבל המון המון נכסה נושא של מה זה לכתוב testים טובים מבחינתability וust. שלושה דברים שהם חשובים שבעדיהם כל הנושא של יניטestינג בארגולים נכשל כמובן נכסה את כל הרעיון של מה זה יestיננו שמישהו שמעולם לא כתב unitטest בחיים שלו יוכל להתחיל את הקורס הזה אז גם אם בחיים שלכם לא כתבתם שורה של קוד עם משהו כמו [NUnit](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec3 "First steps with NUnit (The Art of Unit Testing, 2nd ed., ch. 2)") או MSTest בסדר גמור והקורס הזה לא מניח שום הנחות את הדיטה שלכם אז אנחנו נצח ברמה מסוימת שמי שכבר יש לו ניסיון בהתחלה יחשוב שזה קצת טיפ טיפה מוכר אבל במהלך זה גם נכסה המון דברים המון prctices גם בטestטים הכי הכי פשוטים אפשר לכתוב אותם בצורה מאוד גבוהה אנחנו נתחיל לחסות את הדברים שגורים לטסestינג להצליח בא הרבה פעמים יוני testing אני לא יודע למה יש חברים שניסו

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

[\[02:15\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=135s) אני אישית עובד בנושא של יונטסing וtvd 10 שנים בערך תשע שנים התחלתי בVB5 וV6 שש עוד אז היו כבר פריורקים ליוטesting וניסיתי אותם וכבר אז כתבתי דברים בצורה מאוד גרועה אבל למדתי בדרך אז I say you don't have to אבל [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)") [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)") הם שני דברים שונים הרבה פעמים אנשו אומרים שהם עושים TDD אבל הם עושים unit testing הם לא עושים test driven and development אז יש פה שני פסטים שונים אנחנו נלמד את שניהם

[\[02:50\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=170s) Unit testing זה האקט של כתיבה של הטestינג איך כותבים אותם וזה הסקיל של איך לכתוב אותם כמו שצריך. TDD זה מתי אתם כותבים את הטestים ואיך אתם משתמשים בהם כדי לדחוף את המוצר. ‏test dream development זה הרבה פעמים מדברים על זה שכותבים את הטestטים לפני הקוד אבל זה אבל אנחנו בהתחלה בחצי הלשון שלהם לא נתמקד בכתיבה של הטסטים לפני הקוד בכלל נתמקד באיך לכתוב אותם אחרי זה נראה איך הכתיבה שלהם בפני הקוד איך היא משפרת ומה היא עוזרת וכולי אבל הרבה פעמים הנושא של tdtd וני testing אנשים מחברים אותם ביחד חשוב שתבינו שאפשר לכתוב testים גם test first והם יהיו מאוד מאוד גרועים אוקיי וגם אפשר לכתוב testים שהם כתובים אחרי הקוד והם יהיו מאוד מאוד טובים לשני סקיל שם שהם לא קשורים חדשים.

[\[03:33\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=213s) יש סקיל אחד נוסף שאני לא מלמד בחוץ הזה וזה דזיין. הרבה אנשים מדברים על TDD ואומרים test driven design מי ששמע. וראינו שהטestטים עוזרים לעצב את הדיזיין של הקוד שלכם ותוך כדי אתם גם יכולים ליצור דיזיין של הקוד שלא חשבתם שבהתחלה יהיה לכם. אז אנחנו נעשה אולי טיפ טיפה מזה אבל אני לא הולך ללמי זignק conceptפט בקורס הזה. נושא של design patterns [solid principles](https://osherove.com/blog/2013/3/6/refactoring-string-calculator-with-solid-principles-in-mind.html "Refactoring String Calculator with SOLID Principles in Mind - Examples Needed (osherove.com)") של איך לתורק oנט כל כצורה שהיא compפונט בשביל זה יש זה סקיל נפרד

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

[\[04:39\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=279s) אז אנחנו הולכים לעשות את השניים הראשונים. לכתוב testing ואז ללמוד לכתוב אותם test first person. 50% מהקורס הזה הם קידוד. זאת אומרת שבחצי השני של היום רוב מה שתעשו זה קידוד. אתם תהיו בעיקר בחברים האלה. אבל בחצי הראשון אני הולך להראות בעיקר איך לכתוב את הטestינג וגם איך נראית הסביבה שלי בתוך סטודיו איך נראית סביבה של מישהו שרוצה לעשות TDD זאת קונפיגורציה אחת של הסביבה אני אראה לכם גם הרבה כלים שחלקכם אוהבים חלקכם לא אוהבים זה גם בסדר אני אראה לכם את הדרך שלי לעשות את זה ואני גם מסביר למה

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

[\[05:46\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=346s) יודע יש פה ליססים לקנות כולם התקינו טרייל אוקיי אנחנו נשתמש בריאפר הרבה כי אני משתמש בו לtvdd אמ לדוגמה אם רוצים להכיר את רישפר זה להכיר את רוב השורטקאטים שלו את כולם להכיר את היכולות שלו ומתי אפשר לעשות מה אז אנחנו נכנס גם לכמה פיצ'רים שלו שעוזרים בתהליך שלv בתהליך של כתיבת הטestטים עוד ניכנס בהמשך היום גם לכלים של continous test שעוזרים לנו להריץ דברים בטd אבל בצורה שהיא כמעט בלתי נראית לעין בלי שני אצטריך לעשות הרבה עבודה

[\[06:21\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=381s) אוקיי אז הקונספט קר קודם כל הקורס הזה נקרא tdd בגלל שכל כל הקידות שאתם תעשו בקורס מלבד השעה אוניה הראשונה או השנייה שלכם היום יהיו test first גם הדברים המסובכים ביותר אתם תנסו לעשות דברים test first ביום השני אנחנו נדבר על [מוק](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4 "Interaction testing using mock objects (The Art of Unit Testing, 2nd ed., ch. 4)") objects וניכנס לטestטים הרבה יותר מסובכים ממה שאנחנו כותבים היום הרבה פעמים אנשים אומרים שהיום הראשון זה היה יום קצת פשוט והכל די בסדר ונו ציפיתי ליותר אז ביום השני יש עלייה ת מדרגה מאוד גבוהה ואז אנשים אומרים או כן בסדר זה מה שרשיתי אבל אי אפשר לעשות את היום השני בלי היום הראשון חשוב שתבינו שהביסיקס האלה הם מאוד חשובים

[\[06:58\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=418s) אז נלמד המון best practices במק וגם את זה נעשה testing ביום השלישי ניכנס ללגס קוד ונראה איך כותבים testingים לקוד קיים כולל רפקטורing וגם מה קורה שאי אפשר לעשות רפקטורים אז אשתמש בקליפ כמו כדי לכתוב טestטים לקוד קיים בלי לשנות אותו כדי שתוכלו לראות שיש אופציות תמיד אפשר אפשר או להשתמש בכלי או לעשות ריפת כל גם בלגסי קוד אפשר לעשות דברים שהם test זאת אומרת אם מצאתם איזשהו בג קודם כל כותבים את הטest שמוכיח שיש בג ואז פותרים את הבג ואז רואים שהטestט עובר אז testן זה לא רק לקוד חדש זה גם בהחלט יכול להיות לקוד קיים או תיקון של קוד קיים יותר נכון

[\[07:40\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=460s) אוקיי אמ כמה צרטים יש פה דרך אגב שלושה שושה צבטים אתם גם יושבים כרגע לפי הצבטים שלכם אחד לשני אנחנו בט לא מתערב >> יש צוות אחד שיושב למעלה או שכולם יושבים פה בחומה הזאת >> אחד שישב למעלה אבל היום לצורך הזה אנחנו כולנו יושב למעלה >> אוקיי אוקיי אז test development הוא prctice אחד שבא מעולם האxtream praming exream prraming אני מניח שובכם כבר שמעתם את של extraming מה שיפה בtd שאפשר לקחת את הrac הזה כמו שהוא ולעשים שים אותו בכל מתודולוגיה הוא לא קשור למתודולוגיה

[\[08:21\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=501s) זה משטיס שהוא בן אדם למחשבות תחשבו על זה ככה אף אחד לא יכול להגיד לכם לכתוב testing כי זה החלטה שלכם כמו שאף אחד לא יכול להגיד לכם לעשות דבג למשהו זה החלטה שלכם איך לעשות איך לכתוב קוד ולכן גם אם אתם יודעים בעולם הוורטרפול הכי גדול שיכול להיות נגיד אמדוקס אתם עדיין יכולים לעשות DVD בגלל שזה החלטה שלכם לכתוב את הטestטים מה קורה אחרי זה האם יש איזשהו בילס ו שמריץ את הטestטים אלה כבר דברים שמשפיעים על הקבוצה על על ההחלטה על ההרגשה איך זה לעבוד בתור קבוצה

[\[08:55\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=535s) אבל בכל ארגון אתם יכולים להיות הבן אדם שמתחיל את הדבר הזה ושמריץ את כל הטestטים שלו לפחות אישית לפני שהוא כותב את כל פעם זה חשוב כי בכל הרבה פעמים יש הרבה התנגדויות לדברים גם אנשים ששמעו על יוניטסing הרבה פעמים חושבים שזה לא מכחות וצריכים להרגיש באמת עוזר ואחד הדרכים לדחוף את זה זה להראות תוצאות אז כדי להבין מה זה TDD צריך כדי להבין מה זהIT testing צריך להבין מה זהIT test זאת ההגדרה של הITEST מויקיפדיה

[\[09:30\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=570s) הגדרה חלקית a test of a small function of cod יש לנו פונקציה is login אוקיי שמקבלת user וורד אז unit test יהיה חתיכת קוד אחרת שמפעילה את החתיכת קוד הזאת אוקיי אמ עכשיו לפני שיכנס להדר שלטסט כמה לדעתכם טסטים אפשר לכתוב לפונקציה הזאת בלי שאנחנו יודעים בכלל את הפונקציונליות שלה מה המספר המינימלי של טestטים אה >> ארבע איזה testing user password not user password

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

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

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

[\[11:53\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=713s) כמה פונקציות עם לוגיקה יש לכם במערכת איןס >> וכמה שאלת מילה אתה רוצה אלים >> אלפים לא לפחות >> לפחות כמה אוקיי אני אני אקל לכם כמה publicקפ functionנקשנס אז אם לא יש לכם במערכת לא ממש אוקיי אז רק מספר יותר מ-500 יותר מ-5,000 מה >> הייתי אומר יותר מ1,000 >> יותר מ-10,000 אז כמה טestטים לפחות צריכים להיות לכם במערכת לדעתכם

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

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

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

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

[\[14:42\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=882s) אז לא בהכרח מוצאים את הבאגים כשיש 10,000 טestטים בקוד וזה מאוד נכון הרבה פעמים אנשים כותבים את הטestטים והם לא כותבים את הטestטים הנכונים או הם בודקים את הדבר הלא נכון דווקא פה הנושא של test dream development לכתוב את הtest לפני הקוד מאוד עוזר כי כשכותבים את הטest לפני הקוד אני לא יודע אם שמה אתם מתחילים מטestט שנכשל ואז גורמים לו לעבור בלי לגעת בטestט ובצורה הזאת בודקים את הטest הוא אמור להיקשל ואז הוא אמור לעבור ואם הוא מתחיל בהתחלה בלי כישלון או שהוא נכשל אבל קמתם את הפרודקשן אבל הוא ממשיך להתקשב ולא עובר יכול להיות שמצאתם באג בטest עצמו וtd זה אחד הפרקטיס היחידים שאני מכיר שבאמת עוזר לך לבדוק את הטestטים שלך ולוודא שהם באמת נכונים בלי לכתוב טestטים לטestטים

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

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

[\[16:41\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1001s) אם אנחנו לא נטפל בעלות הזאת אז הטestטים פשוט יאכלו לנו את את הזמן של הפרודקשן ולא יהיה שווה לעשות אותו. אז אם אנחנו לא עושים טestים שהם מינטינable לא שווה לנו בכלל לעשות טסים. פשוט ככה לא שווה לעשות אותם בגלל שאנחנו שלושות שים להתפתר מהם. אולי שווה לעשות כמה כמה inרation test ככה פה ושם מדי פעם זורקים ואז כותבים מחדש אבל ממש להיכנס לנושא הזה לא שווה כי הזמן שזה יעלה הוא הרבה יותר גבוה הרבה ארגונים נופלים דווקא בדבר הזה

[\[17:12\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1032s) ובפרויקט הראשון שכתבתי אי פעם זה באמת הייתה הבעיה זאת אחת הסיבות שהתחלנו להיפטר מהטestטים ושראינו שהקוד מתחיל להרגיש כמו בטון שכל דבר שאתה מנסה לשנות יש 20 טestטים שאומרים שהוא צריך להראות בצורה מסוימת ועכשיו אי אפשר לשנות את הצורה הזאת ואנחנו נדבר על איך אפשר לפתור את הבעיה הזאת. ועוד דבר שאומרים על testי, יש לך 10,000 טestטים, יותר קל להבין את הקוד. וכשאומרים את זה, מתכוונים לזה שהטestטים סוג של executable specificק שאתה לוקח מתכנת חדש לצוות ואתה אומר לו הנה הקלאס והנה הטestטים, תסתכל על הטestטים ותבין איך הקלאס עובד.

[\[17:50\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1070s) הרבה פעמים גם זה הדבר הזה בכלל לא נכון כי כשאנשים כותבים testים בהתחלה השמות שהם נותנים לטestטים הם test אחד test 1 שט test also שת וכולי לא אכפת להם בכלל מהשמות של הטestטים לא אכפת להם מהרדity של הטesting ואז הדבר הזה לא נכון בכלל אז אנחנו גם נדבר על הרדילטי של הטestטים ועל עד כמה הוא חשוב ואיך לגרום להם להיות יותר יותר רק אם שלושת הדברים האלה נכונים אז באמת קל יותר לפתח עם טesting אם אפילו אחד מהם לא נכון הוא משפיע על כל ה וכל החוויה הזאת נהיית הרבה יותר גרועה

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

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

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

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

[\[20:37\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1237s) מהח של הטסט בודק >> מה >> החלק של הטסט של הפונקציה >> החלק של הקוד שאתה בודק החלק של הפונקציה >> החלק שלו >> כמה שהוא שרוקות בפונקציה אוקיי יש עוד אפשרויות קלאס >> קלאס לפעמים אתה בודק קלאס שלם עם כל הפונקציות שלו נכון אנחנו צריכים כן

[\[21:17\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1277s) יכול להוריד את המחשפה זה בסדר >> זה לא מזל טוב או משהו הדבר הזה כנראה שלא >> יכולים למעלה למה למעלה זרוק אתה למעלה אותה לא >> אוקיי אז יכול להות פונקציה אה פשן x זה יכול להיות קס

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

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

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

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

[\[24:04\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1444s) אוקיי אלה שציפים שלנו זה מבחינת הטestטים אבל איזה סוגי תוצאה יש בקוד >> exceptפtion exceptפtion אוקיי אז אם יש לנו איזשהו יוניט בואו נחליט מה היוט הזה עוד לא נחליט מה זה היוט הזה יכול לזרות exception מה עוד valגם return valtion זה אותו דבר זה גם ס מה עוד שהוא קרה למשהו שהוא קרה למשהו

[\[24:35\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1475s) אוקיי מה זה קרה למשהו לדוגמה לוגר או קלאס אחר אוקיי אדפט ומה עוד יש בדבס >> בדataביס ומה זה אומר מהו >> כן אבל הזה קרה i בסדר זה שינה משהו כן אבל מבחינת היוזר זה שינה משהו

[\[25:07\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1507s) אז עשיתי משהו בעיות זה שינה משהו זה יש איזשהי תוצאה זה יכול להשקיע תהליכים אחרים פה זה יכול להשקיע תהליכים אחרים זה אומר שזה שינה איזשהו סטייט זה לא סתם היה הסטייט של המערכת משתנה המערכת מתנהגת אחרת אלה שלוש שלושה סוגי התוצאה שיכולות להיות על זאת אומרת פעם כשהייתי כותב testים לprvateטפש ואז הטestים שלי היו נכשלים שנית prvate function ידעתי שהטס סטים שלי טועים בגלל שההרגשה שלי הייתה שהמערכת בסופו של דבר עושה את הדבר הנכון אבל לא ידעתי להגדיר מה זה הדבר הנכון הזה היום אני יודע קצת יותר טוב להגדיר מה זה הדבר הנכון מבחינתי unit

[\[25:45\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1545s) זה לא פונקציה unit זה [unit of work](https://www.artofunittesting.com/definition-of-a-unit-test "Definition of a Unit Test (artofunittesting.com)") זה סוג של באמת תהליך אבל זה תהליך שמותחל על ידי המשתמש או מיוצג על ידי איזשהו משתמש ולכן זה חייב להתחיל בפאבליק זה משהו שאפשר לעשות לו אז יוניט מתחיל באיזשהו פאבק והוא נגמר באחת מהתוצאות האלה או שהוא מחזיר valו או ש או שהוא משנה סטייט במערכת ואז הוא הולכת מתנהגת אחרת או שהוא קורא לאיזשהו פטי משהו שהוא לא בשליטתנו לדוגמה לוגר שצוות אחר כתב לדוגמה

[\[26:22\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1582s) קוד בשרפנט שאני לא רוצה לגעת אחד אז יש לי התחלה סט ויש לי איזשהו סוף ואז כל הדברים שפה באמצע לא אכפת לי מהם בכלל לא אכפת לי אם זה פונקציה לא אכפת לי אם זה שלושה קלאסים לא אכפת לי אם זה 17 פרויקטים unit of work יכול להשתנה יכול להיות קטן כמו פונקציה יכול להיות גדול כמו כמה קלאסים

[\[26:53\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1613s) מבחינתנו ההגדרה של unit test אני יכול לכתוב testים לסקופ כשהוא קטן או לסקופ שהוא גדול. הרבה מההחלטות או הרבה מהאומנות שאני רואה בדבר הזה זה ההחלטה באיזה סקופ לכתוב את הטestטים. אבל אני לא אכתוב testingים לדברים שהם prיט כי מבחינתי כל דבר שהוא prיט הוא חלק מunitive work אחר. כל פונקציה שהיא prיבט אצלכם בקוד יש לה סיבה שהיא קיימת. זאת אומרת מישהו קורא לה. אם אף אחד לא קורה לה אפשר למחוק אותה. היא לא צריכה להיות שם. אז הסיבה היחידה שהיא קיימת זה בגלל שמישהו קורא להבסופו של דבר המישהו הזה מותחל על ידי משהו שהוא פאבליק.

[\[27:27\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1647s) לכל פונקציה קיים קיים לפחות סיבה אחת לפעמים היא יכול להות חלק ממile units of work שבגללה היא קיימת אז אני יכול למצוא דרך לבדוק את הפונקציה הזאת על ידי מציאת הUNIT of work הנכון והend resultלט הנכון ואז אני יודע שהכל בדרך עובד עכשיו זה הכוח האמיתי כשמדברים על מיity הרבה פעמים הבעיה של mainity קוראת בגלל שהטestים שלנו מגדירים יותר מדי מה צריך להיות פה בפנים אתה צריך לקרוא לפrivate fun הזאת ואתה צריך לקרוא ל קלאס הזה והקלאס הזה צריך לקבל שלושה פרמטרים ואתה קורא לביס קלאס שלך לא אכפת לי ככל שלא אכפת לי כמו שאני מתייחס לזה כסוג של הקופסה שחורה

[\[28:07\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1687s) ורק אני מתייחס לשלושה אדריז האלה אז הטestים שלי הם הרבה יותר [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)") בגלל שאז אני יכול לשנות פה הכל זמן שהאנדריזל אותו דבר הצestסטים שלי עדיין ימשיכו לעבור והם לא יכסו עליי על זה שגידו משהו שלא אכפת שלא אמור להיות אכפת להם אלו הרבה מהמטility problem היום קורים בגלל שאנשים אנשים עושים מה שנקרא overפication. הם בודקים דברים ש הם לא אמורים לבדוק. ככל שאני חושב על זה היום, צריך להתחיל במשהו שהוא פאבליק ולהיגמר במשהו שהוא publicקly visible.

[\[28:38\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1718s) זאת אומרת משהו שהמשתמש יכול להרגיש. לדוגמה אם אני מכניס לדataביס אז עכשיו הלוגן שלי אמור להצליח, נכון? אני משתמש באותו API או בAPI אחר ועכשיו API אחר מתנהג אחרת. זה בסate change אבל או שאני מקבל value אחר או שאני מקבל אפtion אחר והטestטים הכי מסובכים זה הטestטים שקורים לרדd part אלה הטestטים אלה המקומות שבהם מתחילים להשתמש במק objects ובגדול כשמדברים על testים או על unit testים

[\[29:09\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1749s) אני רוצה לוודא שהטestטים שלי שולטים בIT בצורה מלאה זאת אומרת שאני שהכל א' אני יכול לגרום לו לרוץ כמה שיותר מהר בדרך כלל זה אומר לגרום להכל לקרות בזיכרון אם יש לי איזשהו IO אז צריך שתהיה לי שליטה עליו לדוגמה להחליף אותו באמצעות משהו כדי לעשות פה מה שנקרא כדי להחליף אותו שאני נוכל לקנות את הטסט אבל לפעמים האנדרי resultלט שלי היחיד הוא לא שינוי סטייט ולא החזרת אלא פשוט איזשהו קריה ללוגר איפשהו

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

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

[\[30:45\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1845s) אם אני מדבר על השכבות של אפליקציה הרבה פעמים בעיקר בעולם המייקרוסופט מדברים על זה שיש לך שלוש שלושה סוגי שכבות יש לך את הui יש לך את הBL ויש לך את הl ואז פה למטה יש איזשהו דabיס אוקיי בדרך כלל testים על UI לא שווה לי לעשות מבחינת הCOST versusס אעלות אות לא שווה לי בגלל שUI משתנה כל הזמן ואז הטestטים שלי כל הזמן צריך שנות פשוט אין דרך החוצה מזה כמעט אתה עושה testים על UI

[\[31:19\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1879s) BL בדרך כלל הביזנסיק או הביזר זה המקום שבו עושים את מרבית היוטי דהר בעצם השכבה שמדברת ישירות עם הדביס או אצלכם מבחינתכם זה ישירות עם הקלאוד יש לכם איזשהיא אסטרציה מעל הקלאד זה מה שאתם ראיתם עכשיו הרבה פעמים באפליקציות שבה אם יש דטביס סטנדרטי אני לא בודק את הדataל ואני עושה [פייק](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)") לדataביס בגלל שהרבה פעמים הדביס עצמו מחיל חלקים מהלוגיקה. זאת אומרת המבנה של הדatביס הרבה פעמים הוא סוג של לוגיקה.

[\[31:50\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1910s) טריגרים חלוקה בין טבלאות שהם כיעוד אחת בשנייה. פורנקי זה גם סוג של לוגיקה. ולכן גם אם הייתי בודק את הדבר הזה והייתי עושה לזה פייק אז זה שזה עובד לא אומר שהאפליקציה שלי עובדת. אוקיי? זאת אומרת חצי מהלוגיקה היכולות שנמצאת פה ואני לא בודק אותה בכלל. אז הרבה פעמים באפליקציות סטנדרטיות שיש דabס את הדatר עצמו אני לא כותב לו unit testing אני כותב לו integration testingation testing זה אומר שהunit of work שלי כולל את הדatabס

[\[32:21\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1941s) כולל את הדatab בגלל שאני רוצה לראות שלא רק שאני יכול שזה קורה לו עם הSQLים הנכונים גם לבדוק שמשהו נקרא עם הSQLים הנכונים או עם הQU הנכונים זה גם זה חתיכת mainity CRP אבל אם אני רוצה אבל אם אני באמת רוצה לבדוק את זה אני אני עושה דביס לטestינג ואני בודק כשהמבנה של הדטביס תומך בהכל שאני יכול לעשות אינסרטים ואפדייטים וכל הדברים האלה עכשיו במקרה של clוד אני לא בטוח אני צריך להסתכל על הכל כי cלא זה הכי דפארטי שיכול להיות אתה לא יכול באמת ליצור קלאוד פרטים משלך לוקחלי אצלך שרץ רק אצלך למחשב אתה טועה >> כן >> כן אני טועה או כן אתה יכול >> כן אתה טועה יש סימולציה של קלאד אצלך

[\[33:05\]](https://www.youtube.com/watch?v=gtRXDuLj8uc&t=1985s) >> אם זה סימולציה זה לא קלא דבר

## Related

- [Defining unit testing, step by step](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec1) · The Art of Unit Testing, 2nd ed., ch. 1

    Builds the definition of a unit test step by step in C#, the same definition this lesson starts from.

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

    Explains a unit as a unit of work from entry point to exit points: return value, state change or third-party call, as here.

- [Exit point types](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_19) · The Art of Unit Testing, 3rd ed., ch. 1

    Book section on exit point types, the three kinds of end results the lesson uses to define a unit of work.

- [Unit Testing decoupled from TDD as well== Adoption](https://osherove.com/blog/2008/10/1/unit-testing-decoupled-from-tdd-as-well-adoption.html) · osherove.com

    Argues for treating unit testing separately from TDD, the same split between how and when to write tests made here.

### Also linked in this lesson

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

- [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
- [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
- [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12), ch. 12
- [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-1#sigil_toc_id_27), ch. 1
- [Tests that don’t assert anything](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-7), ch. 7
- [Maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8), ch. 8

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

- [Testing results that are system state changes instead of return values](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec7), ch. 2
- [First steps with NUnit](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-2#ch02lev1sec3), ch. 2
- [Test-driven development](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-1#ch01lev1sec6), ch. 1
- [Interaction testing using mock objects](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4), ch. 4
- [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4

#### osherove.com

- [Naming standards for unit tests](https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html)
- [Refactoring String Calculator with SOLID Principles in Mind - Examples Needed](https://osherove.com/blog/2013/3/6/refactoring-string-calculator-with-solid-principles-in-mind.html)

#### artofunittesting.com

- [Definition of a Unit Test](https://www.artofunittesting.com/definition-of-a-unit-test)

[Next lesson Syntax](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/syntax/)


---

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