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

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

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

he icon   en icon

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

תכונות הטסט: קריאות

נכתב על ידי 
שישי, 18 יולי 2014 09:54
דרגו כתבה זו
(1 הצבעה)

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

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

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

טסטים אפקטיביים מקצרים את התהליך הזה. מה שמייחד אותם היא הקריאות.

זהו הפוסט השני מתוך סדרת התכונות כפי שתוארו בפוסט "מי בודק את הבדיקות". הפוסט מתורגם מהבלוג שלי: http://www.gilzilberfeld.com/2014/07/test-attribute-2-readability.html

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

 

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

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

לדוגמא:

@Test

public void divideCounterBy5Is25() { ...

אפשר להבין מהשם מה הטסט בודק (תסריט של חלוקה של Counter), הפרטים של המקרה (חלוקה ב-5), והתוצאה המצופה (25).

אם השם נשמע כמו משפט –מעולה. שמות טובים מגיעים מתיאור וורבאלי.

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

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

Test@

public void divideCounterBy0Throws() { ...

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

 

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

הנה כמה טיפים כדי להפוך קוד של בדיקה לקריא יותר:

  • טסטים צריכים להיות קצרים. כ 10-15 שורות.
  • אם האתחול (setup) ארוך, יש להוציא אותו לפונקציות פנימיות, וגם להן לתת שם קריא.
  • הימנעו משימוש באתחול שרץ לפני כל טסט, כמו פונקציות @before ב JUnit. עדיף להשתמש בקריאות ישירות לפונקציות מתוך הטסט. כשמסתכלים על הטסט, אתחול וניקוי אמורים להיות חלקים רציפים ממנו. אחרת, נצטרך לחפש בקוד, וגם להניח הנחות (לא בהכרח נכונות). גם לדבג טסטים כאלה זה לא כיף גדול, מכיוון שנכנסים לתוך הטסט עם קונטקסט "מפתיע".
  • הימנעו משימוש ב base test class. קד משותף הנמצא בהן מחביא מידע רלוונטי להבנת התסריטים.
  • הבליטו את ה assert, תנאי המעבר של הטסט.
  • וודאו שהשם והגוף תואמים.
  • ניתוח לוקח הזמן, והדרך הגרועה (והאיטית) לעשות אותו היא לדבג. טסטים (וגם קוד) צריכים להיות קריאים מספיק כדי שלא נצטרך לעשות זאת.

 

אנחנו לא אובייקטיבים. אנו חושבים שהקוד והבדיקות שלנו כל כך טובים, שכולם יבינו אותם.

בדרך כלל אנחנו טועים.

התשובה לבעיה בעולם האג'ילי היא פידבק.

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

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

 

הפוסט הבא: מהירות.

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

שונה לאחרונה ב שישי, 18 יולי 2014 10:08

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

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

  • Fifteen Free Tools to Help With Testing

    Fifteen Free Tools to Help With Testing There are a great many articles, blog posts, and presentations that discuss automation frameworks and strategies.  But even the most robust automation framework won't eliminate the need to do exploratory testing.  There will always be situations where we need to generate a large amount of text to test a text field or where we need to encode a string in HTML to test for cross-site scripting.  In this week's post, I share fifteen of my favorite free tools that make testing faster and easier.  Text Tools:1. Letter Count:  This tool will count the characters or words in a block of text.  I use it for creating strings with a specific character count when I test text fields.2. Lorem Ipsum Generator: I use this tool when I need to generate large amounts of text for text fields where a user will be able to enter several paragraphs of text.3. Convert Case: This tool comes in handy when I'm testing with Postman and my assertions are expecting the exact casing for string comparison.  Convert Case will set all the characters in a string to lower case, upper case, sentence case, alternating case, and more.JSON Tools:4. Pretty Print: JSON objects need indentation to be easily readable.  This tool will take care of all of the indentation and spacing for you.  This is especially helpful when you receive flattened JSON in a response and you want to be able to read through it.5. Online JSON Viewer: This tool will flatten your JSON for you by removing[…]

    15.12.2018 | 2:14 קרא עוד...
  • Hacking Password Reset Functionality

    Hacking Password Reset Functionality So I have recently returned from 3 months travelling around Colombia and Central America and I am ready to get back to work! One thing that stayed with me during my travels is the amount of time technology would generally appear in conversations from Bitcoin to GPS systems – this gave me further motivation to expand my career in this varied and extremely interesting field. I recently got an email from Pluralsight with an invitation to use the platform for their free weekend, so I thought it would be a good opportunity to take some security classes. Especially considering one of my 2019 goals is to complete the CEH qualification. The course I decided to do focused on web hacking password reset functionality. Please continue reading to learn more about the various ways password reset functionality is vulnerable to attacks. There are generally 3 different ways to reset user password on websites: Password reset links (by far the most common) Generating a new Password which is sent (in plaintext) to the users email Question and Answer style A typical password reset link could look like this: https://example.com/reset.php?token=12345ab6 or it could look like this, using two parameters -> user ID and token https://example.com/reset.php?userId=12345&token=12345ab6 The userId parameter is unnecessary in the second example, as each token should be unique to the user, making the userId parameter arbitrary. A vulnerability which can be easily fixed is that the link should only be valid for a certain amount of time (enough time for the[…]

    15.12.2018 | 1:20 קרא עוד...
  • I Represent the User! And We All Do

    As a tester, I try to represent the interests of users. Saying the user, in the singular, feels like a trap to me. There are usually lots of users, and they tend to have diverse and sometimes competing interests. I’d like to represent and highlight the interests of users that might have been forgotten or overlooked. There’s another trap, though. As Cem Kaner has pointed out, it’s worth remembering that practically everyone else on the team represents the interests of end users in some sense. “End users want this product in a timely way at a reasonable price, so let’s get things happening on schedule and on budget,” say the project managers. “End users like lots of features,” say the marketers. “End users want this specific feature right away,” say the sales people. “End users want this feature optimized like I’m making it now,” say the programmers. I’d be careful about claiming that I represent the end user—and especially insinuating that I’m the only one who does—when lots of other people can credibly make that claim. Meanwhile, I aspire to test and find problems that threaten the value of the product for anyone who matters. That includes anyone who might have an interest in the success of the product, like managers and developers, of course. It also includes anyone whose interests might have been forgotten or neglected. Technical support people, customer service representatives, and documentors spring to mind as examples. There are others. Can you think of them? People who[…]

    15.12.2018 | 11:33 קרא עוד...

טיפים

לרשימה המלאה >>