LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

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

,תכונות הטסט - מהירות

נכתב על ידי 
שני, 21 יולי 2014 13:48
דרגו כתבה זו
(1 הצבעה)

אחד הסיפורים שאני אוהב לחזור עליהם (שוב ושוב) הוא חווית ה TDD הראשונה שלי. לפני שנים רבות, סיימתי לקרוא את הספר המופלא של קנט בק "Test Driven Development by Example". הייתי בטוח ש TDD הוא התשובה לכל מכאוביי.

באותו זמן עבדתי על רכיב תקשורת, ואמרתי לעצמי: למה לא לנסות את הדבר החדש הזה על עצמי?

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

הטסט הראשון שכתבתי, שלח הודעה ובדק שהגיעה.

משהו כזה:

אנחנו מדברים על מהירות. אם טסט כזה רץ כ-3 שניות, כמה זמן ייקח להריץ 100 כאלה?

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

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

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

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

עד שאשים לב שאני מבזבז שעתיים בכל יום על תיקון טסטים, שזה בערך 25% מזמני שאני משקיע בטסטים – השקעה שאני לא רואה את התוצאה שלה. בנקודה זו אני מפסיק להריץ את הטסטים. ומיד אחר כך לכתוב נוספים.

אני קורא לזה "The Death Spiral of Doom". רבים וטובים נופלים בה. רבים לא מנסים לטפס שוב.

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

פידבק מהיר הוא חובה!

טסטים חייבים לרוץ מהר. אנחנו מדברים על מאות ואלפים ברמה של שניות. אם לא, אנחנו צריכים לטפל בבעיה.

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

מה אפשר לעשות?

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

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

הפוסט הזה הוא חלק מסדרת "תכונות הטסט". בפעם הבאה: דיוק.

הכותב מעביר הדרכות וליווי בנושאי בדיקות ואג'ייל – המעוניינים יכולים לפנות דרך האתר:http://www.gilzilberfeld.com/p/contact.html

 

Test Speed

שונה לאחרונה ב שלישי, 29 יולי 2014 10:37

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • Humidifier For Home Heater

    Humidifier For Home Heater humidifier for home heater humidifier for sq ft. . . . . . . . . . . . . . .

    25.05.2019 | 11:08 קרא עוד...
  • ATA Meetup #22 - Bangalore - Amazing experience

    ATA Meetup #22 - Bangalore - Amazing experience Reached super earlyThe session was supposed to start at 9 AM and I reached by 7.45 AM. I did not want to be late. Due to weekend's minimalistic traffic and super driver, I surprised myself and I thought I can just enter and wait in the hall. The security asked me the contact person name and I told him that there is a meetup by Agile Testing Alliance - did not help. I called up Aditya Garg and somehow the security got convinced that I can at least pass the main barricade and sit on the makeshift park seats.It was nice to experience fresh air, have fruits and dive into an interesting book called "The Practicing Mind" by Thomas M. Sterner. The Practicing Mind I remembered the discussions with Shrini Kulkarni about consciousness, mind, awareness as I read the book. Around 8.40 AM, Thrivikram and Venkata P from HCL welcomed and escorted me to the induction hall where we had the meetup. The conversation between them and the security folks was an interesting one making me think of the process adherence vs value addition. Learning for me: Know the contact person in advance and keep them informed about surprises in plan. HCL ServicesThe first session was by HCL management represented by Prashantha M who highlighted the various services offered by HCL, the case studies and the learning. There were few really good questions by the audience who wanted to know more details about the insights shared to them.My tip: Knowing[…]

    25.05.2019 | 11:55 קרא עוד...
  • Performance testing (benchmarking) Java code with JMH

    Performance testing (benchmarking) Java code with JMH Contents:1) Introduction2) Is it easy?3) Common pitfalls4) Setup5) How to configure JMH?6) Configuration options7) Configuration - predefining state8) Demo9) Results10) Further reading1. IntroductionAs test engineers when we approach performance testing we usually only think about final end-to-end application verification with tools such as JMeter, Locust or Gatling. We know that such tests should run on a separate environment with conditions resembling production as close as possible. Unfortunately in some cases (especially with monolithic architecture) dedicated performance testing environment is hard to get. What to do in such cases? Should we test on common test environment? Or should we test on production? Or maybe we should change our approach to performance testing?  Each option has advantages and disadvantages.Today I'd like to describe low-level performance testing (often called benchmarking) of Java code. It does not require a separate environment. It can be executed directly from your IDE (although that's not recommended) or from the command line. Measuring the performance of critical pieces of code is essential for everyone who creates applications, frameworks, and tools. Testers are co-creators so it's also our responsibility. 2) Is it easy?Benchmarking correctly is hard. There are multiple optimizations implemented on the JVM/OS/hardware side which make it challenging. In order to measure right, you need to understand how to avoid those optimizations because they may not happen in the real production system. Thankfully, there is a tool which helps you mitigate those issues called JMH (Java Microbenchmark Harness). It was created for building, running, and analyzing nano/micro/milli/macro benchmarks written in Java[…]

    25.05.2019 | 8:10 קרא עוד...

טיפים

  • בדוק מוקדם ככול הניתן
    בדוק מוקדם ככול הניתן "בדוק מוקדם ככול הניתן" – אחת המטרות של הבדיקות הינה לספק כמה שיותר משוב ומידע לגבי איכות המערכת מנקודות מבט שונות (פונקציונליות ולא פונקציונליות כמו עמידה בעומסים ושאר יכולות). לעיתים בודקים נוטים בטעות לחשוב כי הדרך…
    קרא עוד...
  • בודק - השאר ממוקד מטרה
    בודק - השאר ממוקד מטרה בודק - "השאר ממוקד מטרה / Keep Your Eye on the Ball - The End Goal " – כבודקים בעלי יכולת מיקוד וירידה לפרטים, לעיתים אנו מאבדים את התמונה הכוללת וצוללים יתר על המידה בבדיקת נושאים…
    קרא עוד...
לרשימה המלאה >>