Agile Israel

lowering the adoption barrier for unit testing: doctest in python

ISerializable - Roy Osherove's Blog : Agile — Wed, 03 Dec 2008 22:18:03 GMT

One area that I didn’t know about was brought to me by an attendee in one of the conferences I was in. It’s a simple idea, really: write the tests for a method as part of the method’s documentation. but make them executable. In python, they have something Read More......(read more)

Isolation frameworks – lessons from the wild

ISerializable - Roy Osherove's Blog : Agile — Wed, 03 Dec 2008 20:20:04 GMT

I’m in the process of teaching another TDD master class in Oslo this week, and in the past two days we went over the major Isolation frameworks in .NET (I refuse to say Mocking frameworks anymore. the “Mock” work is too overloaded as it is). We covered Read More......(read more)

Isolation Syntax for VB.NET - Your comments please

ISerializable - Roy Osherove's Blog : Agile — Wed, 26 Nov 2008 10:15:14 GMT

I'm working on adding a VB.NET Friendly syntax for Typemock Isolator. If you're into VB, I'd love your input on the usability of this API and how to make it better. We'll start going through several basic scenarios that you can do using Read More......(read more)

Announcing Isolator for Sharepoint with a free full license for bloggers

ISerializable - Roy Osherove's Blog : Agile — Mon, 24 Nov 2008 19:49:19 GMT

Time for a freebie! We’re announcing today about a new product: Isolator for sharepoint – which allows unit testing sharepoint code without needing sharepoint installed. “Huh?” It is almost the same as Typemock Isolator, but will only work on APIs that Read More......(read more)

היכולת לצאת משטח הנינוחות

Danko — Thu, 20 Nov 2008 18:15:00 GMT

(התפרסם בדיילי מיילי היום http://www.pc.co.il/_DailyMaily/ItemClean.asp?ArticleID=23152&Vol=794&SearchParam=&CategoryID=72)

היכולת לצאת משטח הנינוחות

דני (דנקו) קובץ', ממייסדי AgileSparks

כדי לבצע שינוי בחיים, עלינו קודם כל להבין מה מצבנו האמיתי, מה יהיה המצב המקווה בסוף התהליך, והבנה שהתהליך עצמו יזעזע את שטח הנינוחות שלנו (Comfort Zone). הדבר נכון גם במעבר לשיטת ניהול פרויקטים חדשה, ולשיטה האג'ילית בפרט, בה יש דגש חזק על המימד האנושי (להבדיל, למשל, ממעבר לכלי CRM חדש).

האנשים והחברה (ובייחוד ההנהלה) צריכים קודם להבין מה המצב האמיתי של הארגון, ללא ה-"שקרים הלבנים" שנפוצים בארגון, לבדוק כמה פעמים הארגון עומד בהבטחותיו ללוחות הזמנים, כמה זמן מוקצה להשקעה בעובדים, כמה זמן "מושקע" בישיבות ועוד. לאחר מכן, צריך להבין האם המצב סביר או דורש שינוי, כי זהו הדלק שייתן לארגון כוח בהמשך. לאחר מכן, על הארגון לבחון איזו שיטה עדיפה על ידי בדיקה האם השיטה החדשה תיתן מענה אמיתי לבעיות הקריטיות שנמצאו.

הדבר החשוב ביותר, הוא להבין שבשעת המעבר הארגון סופג זעזוע בשיטת הניהול שלו ועליו לרכוש מיומנויות חדשות בכל מיני תחומים. הדוגמה החביבה עלי היא ילד חדש במשפחה. על כל המשפחה להבין את המציאות החדשה ולפתח את המיומנויות החדשות הנגזרות מהמצב החדש (הלבשה בבוקר, שכן שעת התחלת בית הספר לאחות הגדולה לא השתנתה, מקלחות וארוחת ערב בלילה, פניות לכלל הילדים, שכן שיעורי הבית ממשיכים להגיע ואפילו מתגברים וכו').

במעבר לסקראם, שבו הדגש הוא על עבודת הצוות וגיבושו לצוות מיומן ומגובש מוכוון משימות (יחידת עילית), הצוות חווה קושי רב בתחילה וללא שום דיבידנד מיידי. זהו הזמן שבו צריך לשלוף את הרשימה שתיארה את המצב הקודם ואת הרשימה של המצב המקווה של סוף התהליך ולהיעזר בסבלנות ובמשמעת (הדיבידנדים בדרך!).

מכיוון שכל שינוי מייצר את הנוגדן הטבעי האנושי: פחד, אנשים נוטים לעטוף אותו בכל מיני תירוצים שונים ומשונים שמתארים מדוע ההטמעה נידונה מראש לכישלון. קצרה יריעה מלהכיל את כל הרשימה, אז הנה אוסף התירוצים הנפוצים ביותר שאנחנו שומעים:

- "בתיאוריה זה נהדר אבל פרקטית זה לא עובד". בתרגום: "המצב כל כך סבוך בארגון שאין לי מושג מאיפה להתחיל את התהליך שנראה לי שמאוד יעזור לארגון". בכל ההטמעות שאני הייתי חשוף אליהן, אם זה בארץ או בעולם, אם שאני השתתפתי או שתוקשר לי על ידי מדריכים מוסמכים (של האיגוד הבינלאומי) אחרים, הארגון התייעל באופן משמעותי.

- "אצל אחרים זה בטוח יעבוד אבל אצלנו זה לא יעבוד". בדומה לראשון, קיימת הבנה שהשיטה יעילה ואפילו עובדת פרקטית, אבל הכרת האנשים והמתודולוגיות המיושמות בארגון ימנעו מכך לקרות כי אין לארגון היכולת להשתנות אפילו בשם היעילות.

- "אצלנו הצוותים מבוזרים, לכן זה לא יעבוד". קיימת נטייה לחשוב שאם נבצע מיקור חוץ למדינה בה המשכורות נמוכות משמעותית, נוכל לחסוך הרבה כסף. אמת הדבר שעיקר ההוצאות בענף ההיי-טק הוא משכורות העובדים אולם בדרך כלל נוטים לשכוח את הבדלי התרבות, הזמן והתקשורת הקלוקלת. לפעמים מקצינים את הדבר על ידי הוצאת תת צוות (QA, למשל) מעבר לים וציפייה שהצוות כולו יתפקד בצורה יעילה. לסקראם אין פתרונות קסם והדבר יוקצן ביתר שאת לכל אלה שממענים לראות זאת אבל המטמיע (בייחוד אם הוא מדריך סקראם מוסמך מטעם האיגוד הבינלאומי שמביא איתו את הניסיון והידע של האיגוד) ידע לתת כלים למענה מיידי ויעיל כמו גם ארוך טווח לשיפור המצב.

- "אין סיכוי בעולם שנצליח להוציא גרסה כל 3 שבועות" – לפעמים הארגון חולה בתסמונת הסטודנט ("דחה את הבעיה בתקווה שהיא תיעלם"). זה מתבטא בהרבה מאוד דברים, בין השאר בחוסר יכולת לקמפל את כל הפרויקט. כשאני שואל לפשר הדבר, אני מקבל תשובות הזויות ותמוהות, כמו "אנחנו לא יכולים לקמפל כרגע, לקמפל לוקח שבועיים וחבל על הזמן" וכד'. בסקראם אנחנו מקמפלים את כל הפרוייקט כל יום (ואפילו עם כל שינוי קוד מאושר). נכון, בתחילה זה לוקח זמן, אבל מהר מאוד מגיעים למצב הזה ואז קורים דברים נפלאים. אם קיימת בעיה, היא מיד (עד יום) מתגלה. דומה הדבר לעבודת תחזוק בית. אם לא תתחזק אותו בצורה קבועה, כשיגיעו אורחים תצטרף לעבוד שעות. ראיתי פרויקטים מסובכים מאוד ומורכבים מאוד. כולם לבסוף הגיעו למצב שהם מתקמפלים תוך לילה (ולפעמים זה לא פשוט!) ואז הם לא הבינו איך הם עבדו לפני זה.

- "10% מההטמעות נכשלות – למה להתחיל אם יש סיכוי להיכשל?". הפחד מכישלון הוא לפעמים המגן הכי טוב...

- "אנחנו חברה של מאות אנשים ולכן אג'ייל לא יוכל להתאים לנו". אחת הטעויות הנפוצות היא שסקראם מתאים רק לחברות קטנות או לצוותים קטנים. כמובן שהדבר לא נכון. סקראם מתאים לחברות גדולות כקטנות, אפילו בארץ יש חברות גדולות של מאות אנשים שעוברות לסקראם. ראיתי כבר חברות גדולות שעברו הטמעה מוצלחת וחברות קטנות שההטמעה נכשלה. סקראם אינו תלוי בגודל החברה אלא במחויבות ההנהלה לשינוי.

- "אנחנו עובדים בפרויקטים קבועי תכולה (Fixed Price Project) ולכן אג'ייל לא יעבוד". אם זה היה נכון, היה לוקח לסקראם חצי שנה להיעלם. סקראם מתאים לסוגי פרויקטים מגוונים כמו גם לפרויקטים קבועי תכולה. ההבדל הוא שבסקראם ניתן לדעת כמעט מיד האם צריך להוסיף זמן ו/או אנשים ולא צריך לחכות כמעט לסוף הגרסה כדי להפתיע את הלקוח בחוסר המוכנות של החברה בזמן המוסכם. אחת הבעיות השכיחות בעולם הפיתוח הוא שמנהלים משחקים בלהיות אלוהים והם חושבים שהם יכולים לקבוע הם את התכולה, הן את הזמן ואת את כמות האנשים שצריך. המציאות טופחת על פניהם פעם אחר פעם שכן אי אפשר לקבוע את שלושת הדברים הנ"ל אלא רק שניים מהם בכל זמן נתון, כשהשלישי נגזר. כמו כן פיתוח תוכנה הינו שילוב של יצירתיות ותקשורת ולכן יש להתמודד איתו בהתאם כאשר נדרשים למתן לוחות זמנים. בעזרת סקראם ניתן לרכוש את המיומנות הזו אבל אי אפשר לעשות קסמים. אם צוות של שלושה אנשים יכול לשתות 100 כוסות מים ב-20 דקות, לא יעזור המנהל המוכשר ביותר שיבוא ויגיד שאותו צוות צריך לשתות 100 כוסות ב-5 דקות רק בגלל שהובטח הדבר ללקוח.

ונסיים באוסף התירוצים שמצחיקים אותי יותר מהמכל שכן לא רק שהם אינם קשורים לסקראם, אלא הפתרון נראה מובן מאליו אבל אף אחד לא מטפל בהם והם בבחינת גזרה משמיים. הנה הדוגמאות המובילות. למעט השמטת פרטים מזהים כמו שם החברה, הציטוטים מדוייקים:

- "אצלנו המסמכים היו ותמיד יהיו מסובכים, מורכבים ובלתי ברורים שאין סיכוי להטמיע אג'ייל".

- "למנהל המוצר אסור לדבר ישירות מול הצוותים כי הם לא אנשים שלו ופעם אחרונה שזה קרה, היה בירור עם סמנכ"ל הפיתוח".

- "אני חייב לשקר למנהל המוצר לגבי לוחות הזמנים. הוא יודע את זה והוא מקצץ את ההערכות שאני נותן לו. אתה מציע להגיד לו את האמת וזה לא ילך".

- "אין לנו אפשרות לתעדף את פרטי הגרסה - אצלנו הכול חשוב".

- "ברור לי שהאנשים לא יספיקו את כל התכולה אבל אני חייב לשקר להם אחרת הם לא יספיקו אפילו חצי ממה שאנחנו רוצים".

- "לעולם לא נוכל להוציא גרסה כל שלושה שבועות כי רק על ישיבות אנחנו מבזבזים יומיים כל שבוע".

- "ההטמעה תיכשל כי להנהלה לא איכפת איך אנחנו עובדים העיקר שנעמוד בלוחות הזמנים והתכולה (הבלתי הגיוניים) שהם התחייבו בשמנו".

- "אצלנו המנהלים צריכים לדעת כל דבר קטן לכן לעבוד באג'ייל שהאחריות ניתנת לצוות לא תעבוד כשיטה".

- "נוח לי עם זה שלא כל אחד יודע מה אני עושה, עכשיו אתה מציע שכולם ידעו על מה אני עובד ומה קצב ההתקדמות שלי?".

- "לעבוד באג'ייל זה לעבוד בצוות ואין טעם לעבוד אצלנו בצוותים כי כל אחד בצוות יודע דבר אחר ואף אחד לא יכול להחליף אותו או לעזור לו וככה זה ישאר".

והדוגמה ההזויה ביותר:

- "אנחנו אמנם לא עומדים בלוחות הזמנים, באיכות ובתכולה אבל לאף אחד לא איכפת אז פשוט אין לנו טעם לעבור לאג'ייל או לכל שיטה חדשה אחרת".

Broad Support, indeed

Rhino Mocks — Thu, 13 Nov 2008 22:44:34 GMT

How do you test a system that self optimize itself?

Test Driven Development — Thu, 06 Nov 2008 15:36:51 GMT

I have a system in which one of the core parts is required to work in a non deterministic fashion. In particular, some part of the system is behaving randomly (by design). Here is a small description: 90% of the time, we select only items that are above Read More......(read more)

Isolator Feature Focus: Faking Collections

ISerializable - Roy Osherove's Blog : Agile — Sun, 02 Nov 2008 12:57:32 GMT

Another cool feature in Isolator is the ability to fake values that will be returned from custom collections (anything that inherits from IEnumerable as long as it is not in mscorlib - for example - sharepoint lists). With the new version you can now Read More......(read more)

Isolator Feature Focus: Duck Typing and Isolate.Swap

ISerializable - Roy Osherove's Blog : Agile — Sun, 02 Nov 2008 12:25:00 GMT

Typemock Isolator 5.1.1 has been released, and this release brings with it some awesome (seriously) features that are unique fro any other framework I've seen. a good overview of features can be found here . The Isolator Swap feature allows swapping Read More......(read more)

Left Brain Storming

Oren Ellenbogen's Blog - Agile — Fri, 31 Oct 2008 13:14:30 GMT

We're doing a lot of thinking these days about which features will give us the best ROI, trying to prioritize existing features and asking ourselves "did we miss something? is there a new feature out there we left behind?". It's not Read More......(read more)

SharpMock 0.1 ?

ISerializable - Roy Osherove's Blog : Agile — Sun, 12 Oct 2008 21:57:51 GMT

James, I would love to see you take the idea of “SharpMock” to the next level . If not anything else, it would be an interesting challenge to write about. James took PostSharp and started looking at the possibility of intercepting static method calls Read More......(read more)

Isolator feature focus – Advanced Debugger Support for fakes

ISerializable - Roy Osherove's Blog : Agile — Sat, 11 Oct 2008 21:15:36 GMT

Two features that Typemock Isolator has make the debugging experience with it very different than any other isolation framework: 1) Highlight fake method during debugging When stepping into a method that is being faked by the test, the method will Read More......(read more)

Art Of Unit Testing – Book done, Wiki ready

ISerializable - Roy Osherove's Blog : Agile — Sat, 11 Oct 2008 20:46:03 GMT

I’m happy to report that my book has finally hit the “last review” stone, which means all chapters are done and the book should be in book stores around jan-feb 2009 . If you’d like to read the E-Book version right now(PDF) you can purchase that for a Read More......(read more)

תפקידו של מנהל המוצר בעולם האג'ילי - הכל מסתכם בתשואה

Danko — Sat, 11 Oct 2008 13:37:00 GMT

אחד התפקידים המרכזיים בעולם ה Agile, ואולי החשוב ביותר מכולם, הוא מנהל המוצר (PRODUCT OWNER – PO), שהינו האדם הוא הישות (הצוות) שאחראי למוצר ועיקר המשקל והאמון של התהליך נשענים עליו. איגוד ה Scrum Alliance הכיר בחשיבות תפקיד ה PO, והגדיר הסמכה וקורס ייחודיים לתפקיד – Certified Scrum Product Owner.

אם אתם חושבים כרגע לעצמכם: "מה ההבדל, ה PO אחראי על המוצר גם בשיטה הקלאסית", אתגרו את עצמכם עם המשך תוכן הכתבה ושאלו את עצמכם, האם באמת זה מה שקורה בארגון שלכם.

ניתן לפצל את תפקידו של ה PO לפעילויות הבאות:

הגדרת תוכן המוצר

מנהל המוצר אחראי לתוכן שלו. הוא יודע מה נכון לשלב בגרסא הבאה, ולא פחות חשוב, מה לא לשלב בגרסא. משפט נפוץ אצל מנהלי גרסא מהדור הקודם: "הכול חשוב ואין טעם להוציא את הגרסא עם פחות!". מצער למדי שכל פעם מחדש, המציאות טופחת על פניהם כרעם ביום בהיר ועם הגעת יום שחרור הגרסא היא לא כוללת את כל התוכן ה"נדרש" וזאת למרות שהצוותים עבדו במלוא המרץ ואז, הפלא ופלא, הגרסא יוצאת עם תכולה מקוצצת...

אחריות על התשואה אל מול ההשקעה (Return On Investment)

מנהל המוצר אחראי על המוצר כולו ולכן גם על כך שהוא יהיה רווחי. מנהל מוצר שלא נמדד על התשואה, הינו מנהל מוצר שפועל על פי דעתו הפרטית והרגשית. "מה שאתה לא יכול למדוד, אתה לא יכול לנהל" אמר פיטר דרוקר, אבי הניהול המודרני, והכלל הפשוט הזה עובד להפליא גם כאן. על מנהל המוצר להימדד על פי החזר ההשקעה של המוצר, רק כך הוא ידע מה עדיף להכניס לגרסא, מה כדאי להחסיר, את התיזמון למכלול הגרסאות, קריאת השוק בצורה נכונה ועוד.

תיעדוף נכון של הפריטים שמהווים את הגרסא כולה

על מנהל המוצר להבין את המוצר לעומקו כמו גם את רצון השוק. רק מנהל מוצר שידע את התיעדוף הנכון של הפריטים המהווים את הגרסא כולה, יוכל לייצר גרסא רווחית. חלוקת הגרסא לפרטים, מחצינה סיכונים ותלויות כמו גם גורמת להבנה יותר טובה של המוצר. תיעדוף נכון יגרום לצוות לעבוד על הדברים החשובים יותר קודם. זהו יתרון עצום שכן בעולם ה Agile, הצוות משחרר גרסא כל פרק זמן קצר והחשיבות של "הדברים החשובים תחילה" גורמת לגרסא להיות תמיד המעודכנת ביותר. נוסף על כך, בעידן של כמות שינויים עצומה במהלך גרסא, עדיף להתעמת עם הדברים החשובים ולא לדחות אותם לסוף (תסמונת הסטודנט) כשאין זמן וכולם לחוצים (ואז מעגלים פינות על ידי ויתור על איכות) או "נזכרים" שהחלק הכי חשוב בגרסא עוד לא טופל.

החלטה על תאריך שחרור הגרסא

רק מנהל המוצר (מכוון שהוא נמדד עליו) יכול להבין מתי האיזון בין דרישות השוק לגרסא חדשה לבין התוכן הקיים של הגרסא. כזכור, בעולם ה Agile כל פרק זמן קצר הצוות מוציא גרסא פוטנציאלית (Potentially Shippable Release) ולכן מנהל המוצר מודע בכל רגע נתון (איטרציה) מה כבר קיים בגרסא ומה לא (ואין הכוונה למה "אמור" להיות בגרסא אחרי שיתחילו קומפילציה, אחרי שבוע יסיימו ואז הQA יתחיל. בעולם ה Agile, גרסא מוכנה היא גרסא שעברה כבר את כל השלבים הללו והצוות מבצע זאת תוך כדי האיטרציה כך שבסוף האיטרציה המוצר כבר עובד לאחר בדיקה). לאור כל זאת, מנהל המוצר הוא היישות היחידה שיודעת על התאריך הנכון להוצאת הגרסא.

התאמה, כוונון ותיעדוף של הפיצ'רים עבור כל איטרציה

בתיאוריה הכל אמור לעבוד אבל המציאות היא הרבה יותר חזקה. פיצ'רים שהוגדרו כחשובים ביותר הופכים לפחות חשובים עקב דרישות שוק החדשות, מתחרים עם פתרונות חדשים ועוד. בנוסף, פיצ'רים שהוגדרו היטב בהתחלת איטרציה נראים אחרת לגמרי כאשר הם מיושמים ("זה בדיוק מה שביקשתי אבל כשאני רואה את זה משתלב עם הGUI החדש אני רוצה לשנות את הסדר/הצבע/תוכן"). כאן מתבטא תפקידו של מנהל המוצר ביתר שאת. עליו להיות מוכוון מטרה ועם זאת גמיש מחשבתית לשנות אותם תוך כדי תנועה.

אישור או דחיית פריטי הגרסא

מנהל המוצר הוא היישות הסופית שיכולה לדחות או לאשר פריטי גרסא מוכנים. בהתחלת איטרציה הצוות ביחד עם מנהל המוצר מסכימים לא רק על מה יוצג ויוכנס לגרסא שתצא באיטרציה הבאה אלא גם על הגדרת "עשוי" עבור כל אחד מהפרטים (Definition of Done). האיטרציה מתחילה והצוות מתחיל לעבוד. להבדיל ממתודולוגיות פיתוח קלאסיות, הצוות, בעולם ה Agile, מורכב מאוסף האנשים היעיל והרלוונטי ביותר לאור המשימות הנדרשות לאיטרציה. דוגמא לצוות Agile יכולה להיות 4 אנשי פיתוח, איש DBA, שני אנשי QA ואיש GUI.

מנהל המוצר יכול להיות אדם אחד שזהו תפקידו בארגון, או צוות של אנשים אשר כל אחד מהם אחראי על חלק אחד בפרוייקט וביחד הם אחראים על הפרוייקט כולו. כך או כך, חשוב והכרחי שהם יוכלו לתעדף נכונה את פרטי הפרוייקט כלפי הצוות. בכל רגע נתון, ובייחוד לפני כל תחילת איטרציה, הצוות צריך לדעת לא רק מה תוכן הגרסא אלא גם את התיעדוף של כל אחד מהפרטים שכן אין הוא מסוגל לבצע את כולם, ולכן הצורה היעילה ביותר היא לעבוד על פי התיעדוף שמשתנה מאיטרציה לאיטרציה. מנהל מוצר שלא עושה זאת, שמחצין לצוות ש"הכל חשוב באותה מידה" וממאן לתעדף, גורם לחוסר יעילות משווע. אם הצוותים בעולם ה Agile משולים ליחידות עילית הנעות בשטח (הפרויקט), מנהל המוצר הוא הגוף המספק את המטרות. יחידות עילית ללא מטרות מוגדרות ומתועדפות, יעשה ככל יכולתו (הרבה) אבל ללא הכוונה, דבר שיגרום להפסד. על מנהל המוצר לספק את כל הנזכר לעיל ורק אז יחידות העילית תוכלנה למצות את הפוטנציל שלהן שכן כל ה"חגיגה" הזו היא בשביל מנהל המוצר שאחראי לתשואה המקסימלית של המוצר ולהצלחת החברה.

המאמר יתפרסם בדיילי מיילי בשבוע הבא וכמו כן באתר של החברה

Recursive Mocking

Rhino Mocks — Fri, 10 Oct 2008 11:40:45 GMT

This now works :-) The challenge is still open, I intentionally stopped before completing the feature, and there is a failing test in the RecusriveMocks fixture that you can start from. And just to give you an idea about what I am talking about, please Read More......(read more)

Request for comments: Changing the way dynamic mocks behave in Rhino Mocks

Rhino Mocks — Fri, 10 Oct 2008 10:42:00 GMT

I have just committed a change to the way Rhino Mocks handles expectations for dynamic mocks and stubs. Previously, the meaning of this statement was "expect Foo() to be called once and return 1 when it does": Expect.Call( bar.Foo ).Return(1 Read More......(read more)

Rhino Mocks 3.5 Gems - Explicit Property Setting Expectations

Rhino Mocks — Thu, 09 Oct 2008 07:48:52 GMT

This post is derived from the Rhino Mocks 3.5 documentation . Setting expectations for property set was always very simple, and slightly confusing with Rhino Mocks. Here is how you do it: view.Username = " the user name "; The problem is that Read More......(read more)

Rhino Mocks Challenge: Implement This Feature

Rhino Mocks — Tue, 07 Oct 2008 22:41:21 GMT

Okay, let us see if this approach works... Here is a description of a feature that I would like to have in Rhino Mocks (modeled after a new feature in Type Mock). I don't consider this a complicated feature, and I would like to get more involvement Read More......(read more)

Rhino Mocks 3.5 RTM

Rhino Mocks — Sat, 04 Oct 2008 22:49:12 GMT

Today I decided that I had enough time to get bugs for the 3.5 RC, so I fixed all the remaining bugs, updated the Rhino Mocks 3.5 Documentation , and put the binaries out the site . For this release, I actually have 4 binary packages. One for .NET 3.5 Read More......(read more)

Isolator feature focus: Recursive Fakes

ISerializable - Roy Osherove's Blog : Agile — Sat, 04 Oct 2008 22:17:05 GMT

Here’s another feature Typemock Isolator has that no one else currently has: the ability to return fake objects from properties recursively (without the use of an auto mocking container for such a feat). this saved a lot of reperitive test code of creating Read More......(read more)

BDD: Behavior vs. Spec Frameworks

ISerializable - Roy Osherove's Blog : Agile — Sat, 04 Oct 2008 21:49:01 GMT

In my search to understand a little more about BDD and BDD frameworks, one gem that I gleaned is that there is an important distinction between “Spec” and “Behavior” frameworks. “Spec” is intended for the unit level granularity (like unit tests) and Read More......(read more)

Agile Testing tools List

ISerializable - Roy Osherove's Blog : Agile — Fri, 03 Oct 2008 21:55:32 GMT

Working on an appendix for my book , with a list of tools and frameworks you should care about. Tell me if I missed anything: · Mock Frameworks o Moq o Rhino Mocks o Typemock Isolator o NMock o NUnit.Mocks · Test Frameworks o MS Test o NUnit o MbUnit Read More......(read more)

Isolator feature focus: Live objects in unit tests

ISerializable - Roy Osherove's Blog : Agile — Thu, 02 Oct 2008 05:37:06 GMT

Here is one feature that sets Typemock Isolator apart from all the other frameworks, that has nothing to do with legacy code: Live Objects. This feature allows you to just “new” up an instance of an object, if you can, and then fake method results on Read More......(read more)

Unit Testing decoupled from TDD as well== Adoption

ISerializable - Roy Osherove's Blog : Agile — Wed, 01 Oct 2008 13:27:22 GMT

The discussion on the future of unit testing for the masses has shifted from the standard “if they are too stupid to learn it, we don’t want them” to “TDD without good design will make really bad tests”. and this is a good thing. it’s a good thing because Read More......(read more)

Meta tests

Test Driven Development — Wed, 01 Oct 2008 07:14:30 GMT

I found this test fixture hilarious. [TestFixture] public class ValidateNamingConventions { private System.Type[] types; [SetUp] public void Setup() { types = typeof (ISearchFactory).Assembly.GetExportedTypes(); } [Test] public void InterfacesStartsWithI Read More......(read more)