Unit-test...

[אוֹריארד]

Unit-test...../images/Emo26.gif

שאלה של פיסטון: כשכותבים Unit-test ל-class נניח, איך בודקים מתודות private?... יש לי class קצת מורכב - שהייתי רוצה לבדוק אותו מעבר ל-interface, האופציות שיש לי הן: 1) להכניס מתודות בדיקה לתוך ה-class (מה שינפח אותו מאוד - כי חלק מהבדיקה כוללות נתונים שהן hard-coded בתוך מתודות הבדיקה) 2) להוציא את המתודות שאני רוצה לבדוק ל-public - שזה די מבאס לקלקל ככה את ה-class המקורי 3) אולי יש דרך להשתמש ב-friend? אבל אז ה-class "יכיר" את מי שבודק אותו...

בקיצור - יש למישהו רעיון?... מה עושים בד"כ?...

 

[REDMF]

Inner Class

אני משתמש המון בUNITTEST של PRIVATE METHODS בעזרת INNER CLASS. זה משיג מספר יתרונות: 1. אפשרות של בדיקה של מתודות פנימיות 2. הבדיקות הולכות בייחד עם הקוד כך שאין סיכוי שהן תאבדנה סנכרון עם הקוד. עובד בשבילי נהדר. מאד מומלץ

 

[אוֹריארד]

חוץ מבעיה קטנה -

אם ה-class של ה-unit-test הוא בגודל 15MB, זה ייכנס לך גם ל-release...

(וזה מה שקורה במקרה שלי).

 

[REDMF]

אני מציע איזון

אני מאד מקווה שאין לך CLASS בודד של 15MB (אם כן אז וווווו....) אבל תשלב, תשים את מה שבודק את הPRIVATE כ INNERCLASS והשאר בחוץ למרות שבכל מקרה, לי ממש לא אכפת להוציא את הUNITTESTS שלי ביחד עם הקוד, אבל זה כנראה עניין של דעה.

 

[אוֹריארד]

כן... אני מניח שזו אופציה...../images/Emo26.gif

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

) 2) יש לי class של 15MB לצרכי בדיקה בלבד, אני צריך לסמלץ קבלת מסה של נתונים ואין לי דרך אחרת לעשות את זה (אי-אפשר בקובץ - כי אין file-system בכלל...) אז זה חייב להיות hard-coded. 3) במקרה הזה, להוציא unit-test עם הקוד זה בעייתי משתי סיבות: קודם כל - הגודל כאמור... זו מערכת embedded עם זיכרון מוגבל, ולהוציא מאות מגות על unit-test זה לא סביר. דבר שני, זה אומר שב-release יהיה לי קוד "לא נגיש"... כלומר, שאין שום דרך משום קלט להגיע אליו... וגם זה לא כל-כך בריא שיישב במערכת מבצעית אצל הלקוח... (אז אפשר להסתיר עם IFDEF וכל זה, אבל נו... שויין...) 4) תודה בכל מקרה על הטיפים והמאמצים!...

 

[REDMF]

הערה אחת

בקשר לסעיף 1 לתשובתך, אני לא רואה איך זה שיש לי PUBLIC INNER CLASS אשר ניגש למטודות הPRIVATE של האבא חושף את הPRIVATE של האבא. למעשה לINNERCLASS הזה צריך להיות מטודות של TEST_THIS וTEST_THAT הן הדבר היחידי שיהיה חשוף. אני לא רואה כאן צורך בFRIEND למעשה כל מה שיש כאן זה פונקציות בדיקה חשופות שאם זה אין לי בעיה - כל מה שהן עושות זה ASSERT. אם כל השאר אני מסכים במאה אחוז אם הסתייגות אחת יש אפשרות שאני לא ממשה אוהב אבל אפשרית היא להשתמש בדגלי הDEBUG כך שקטע קוד מתקמפל בBUILD DEBUG ונשאר בחוץ בכל השאר. הייתי עוטף את הINNER CLASS של הTEST בIF שכזה ואז זה לא היה מתקמפל לקוד RELEASE.

 

[אוֹריארד]

../images/Emo45.gif אכן... סבבה - תודה!...

 

[rauchy]

internal classes

( מצחיק, באתי לפורום כדי לשאול על הנושא, ובדיוק ראיתי שיש על זה שרשור ) אני מפתח פרויקט ב-c# עם nunit. יש לי פרויקט BusinessLogic, ופרויקט BusinessLogicTests שבודק את BusinessLogic. כעיקרון אני יוצר כל class חדש כ-internal, אלא אם כן הוא צריך לצאת החוצה. העיקרון הזה מתנגש לי עם הפרדת הבדיקות לפרויקט BusinessLogicTests, משום שכך אינני מסוגל לבדוק את ה-internal classes. בנוסף, כמו שצוין בתחילת השרשור, בדיקת class בצורה חיצונית ( לא כ-inner class, שזה גם מכוער ) גורם לי לכער את הקוד ע"י שימוש ב-reflection ב-test שלי במקרה הפשוט או חשיפת private-ים בתור public-ים במקרה הגרוע. מישהו מכיר מאמרים בנושא שמירת design נכון ו-test driven development? תודה רבה, ראוכי.