Unit-testing Singletons

[atarsh]

אנחנו משתדלים חזק ללוות פרויקטים ב-unit testing, ולצורך העניין אנחנו עובדים עם FlexUnit, אבל נראה לי שהבעיה שלי משותפת לכל הפריימוורקים של הבדיקות ל-AS3.
מתודות private - אי אפשר לבדוק. סבבה, זה גורם לנו להעביר חלק גדול מהן להיות protected, ואני חיה עם זה בשלום.
כדי לבדוק מתודות protected אני הופכת את ה-test case, יענו מחלקת הבדיקות, למחלקה שמרחיבה את המחלקה הנבדקת.
עד כאן הכל טוב ויפה.
ליצירת סינגלטונים אני משתמשת במחלקה פנימית כפרמטר לקונסטרקטור כדי למנוע אינסטנסיאציה (סחתין על המילה) מחוץ למחלקה.
עובד יופי בתור סינגלטון, אבל זה אומר גם שאי אפשר להרחיב אותו - ולענייננו, אי אפשר לבדוק מתודות פנימיות.
אפשר כמובן להפוך הכל ל-public, אבל עם זה אני, איך להגיד, לא חיה בשלום. אז אני מחפשת אחד מהבאים:
א. דרך לבדוק מתודות protected של סינגלטון כמתואר לעיל
או
ב. דרך יעילה אחרת ליצירת סינגלטונים
עם עדיפות לאפשרות א' - לא בא לי לשנות קוד קיים.

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

[shvilam]

יש לרעיון אולי די מופרך לא יודע עם הוא יכול לעבוד
תכתיב פונקציה כזואתי

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using actionscript3 Syntax Highlighting

public function expose(funcName:String,unitTestKey:Class):Function
{
     return this["funcName"];
}
 

Parsed in 0.028 seconds, using GeSHi 1.0.8.4

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

[atarsh]

על הסינגלטון? זה הורג את האנקפסולציה כמו להפוך הכל לפאבליק.

[shvilam]

כן אבל את ה key יש רק לקוד שקשור ל unit test אז גם שמרת על האיקפסולציה
אומנם מכוער אבל יכול לעבוד
יש לי גם טעות בקוד שם ה unitTestKey הtype שלו צריך להיות מסוג אחר לא class
לא יודע על מה חשבתי שכתבתי class

[atarsh]

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

[shvilam]

לא אמרתי שאני אוהב את זה
אבל אני חושב שזה באופן יחסי מעט לכלוך
היתי ממשיך לחפש

[atarsh]

ממשיכה
הצעות נוספות?

[Flashmattic]

unit testing על סינגלטונים זה דבר לא נעים.
מעבר למה שציינת, הרעיון שטסט אחד משפיע על סינגלטון וההשפעה ניכרת גם בטסט השני, זה לא לעניין. מי רוצה לאתחל סינגלטונים כל פעם מחדש?
זו, אגב, הסיבה שגרסה הישנה של קיינגורם ופריימוורק כמו pureMVC שנסמכו בגדול על סינגלטונים נכשלו...
אני ממליץ על פרייוורק שיודע לעשות IoC, או "הזרקה" במילים אחרות. Parsley הנהדרת או Swiz שממש עתה יצאה עם גרסת מייג'ור רשמית.
הפריימוורקים הללו נותנים את האפשרות לצור קונטקסטים של הזרקה יחודיים לצריכה מסויימת. היריעה קצרה, אבל אומר שאפשר להחליט שעבור הטסטים מזריקים אימפלמנטציה מסויימת של אינטרפייס, כאשר בבדיקות הוא לא יוזרק כסינגלטון אלא כאינסטנס חדש כל פעם.

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

[atarsh]

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

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

[shvilam]

אני יכול להצתרף ואולי גם להויסף למתי
אנחנו גם עושים שימוש בframework מהסוג שדיבר עליו מתי
אבל מתי לא הזכיר אותו הוא ניקרא robotleg
http://www.robotlegs.org/

[איתן אבגיל]

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

אני את שלי אמרתי, עטר. אני יודע שזה לא נשמע לך אבל fuck the protected. אם הפונקציות הללו משנים משהו בתוך ה members של המחלקה - אז אפשר להפריד בין ההשפעה על ה members לבין הלוגיקה של הפונקציה ולפבלק אותה (לפבלק - כל השמורות זכויותת אא). יש לנו בקוד לא מעט פונקציות שלא נמצאות לגמרי בטהרת ה OOP. לא אסון לאומי.
מצד שני - אם את משנה קוד בשביל unit testing זה מריח רע.

[shvilam]

כחול שהזמן עובר אני אוהב את הרעיון שלי יותר
כזה אני מתאהב ברעיונית של עצמי רק ביגלל שאני הצעתי אותם

[atarsh]

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

[atarsh]

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

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using actionscript3 Syntax Highlighting

package com.kaltura.kmc.business {
        /**
         * This class is a basic singleton implementation.
         * @author Eitan
         *
         */
        public class MySingleton {
               
                /**
                 * Singleton instance
                 */
                private static var _instance:MySingleton;

        CONFIG::realBuild {
                /**
                 * @param enforcer      singleton garantee
                 */
                public function MySingleton(enforcer:Enforcer) {

                }
               
                /**
                 * Singleton means of retreiving an instance of the
                 * <code>MySingleton</code> class.
                 */
                public static function getInstance():MySingleton{
                        if (_instance == null) {
                                _instance = new MySingleton(new Enforcer());
                        }
                        return _instance;
                }
        }
       
        CONFIG::unitTestingBuild {
               
                public function MySingleton() {

                }
               
                /**
                 * Singleton means of retreiving an instance of the
                 * <code>MySingleton</code> class.
                 */
                public static function getInstance():MySingleton{
                        if (_instance == null) {
                                _instance = new MySingleton();
                        }
                        return _instance;
                }
        }

        }
}

class Enforcer {

}

Parsed in 0.032 seconds, using GeSHi 1.0.8.4

ב-additional compiler arguments עבור הפרויקט האמיתי הוספתי:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using actionscript3 Syntax Highlighting

 -define=CONFIG::unitTestingBuild,false -define=CONFIG::realBuild,true

Parsed in 0.028 seconds, using GeSHi 1.0.8.4

עבור פרויקט הבדיקות:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using actionscript3 Syntax Highlighting

 -define=CONFIG::unitTestingBuild,true -define=CONFIG::realBuild,false

Parsed in 0.029 seconds, using GeSHi 1.0.8.4

בגדול, אם הייתי מצליחה להשתמש רק במשתנה אחד (if-then-else) הייתי שמחה יותר, אבל נו..

[LeoBeer]

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

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

[atarsh]

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

ולא דובר על בדיקות בזמן ריצה מול שרת, לא יודעת איך קיבלת את הרושם הזה. מדובר על unit testing לגמרי, בדיקה של קטעי קוד בלתי תלויים.

[LeoBeer]

בפשטות, המטרה של UNIT TESTING היא לעשות ואלידציה של API מסויים, מתודות שהן PRIVATE הן לא חלק משום API.

[Flashmattic]

באופן הישיר, הן לא חשופות כ API, אבל בצורה העקיפה, ה private הן אבני היסוד של ה API.
כאשר אנחנו בודקים API, אנחנו למעשה בודקים את התקינות של ה private methods שלנו.
(שמתם לב שממש התשתדלתי לא לכתוב privates? אה, אופס).

[LeoBeer]

אכן, ולכן מיותר וגם לא נכון לבדוק אותן ישירות. בגדול, מה שהוא PUBLIC או PROTECTED הוא סוג של חוזה בין מי שכתב את הקלאס לבין שעומד להרחיב או להשתמש בה. UNIT TESTING אמורות לאשר את החוזה הזה ולוודא שהקלאס עומדת בו.

[atarsh]

אבל... מי אמר שunit testing הן לבדיקת API?
אם נשאיר את "תקרית הסביח" בצד רגע, תרשו לי לצטט מויקיפדיה:

In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application.

שום API לא נכנס כאן. יחידות קוד. סה טו.

[LeoBeer]

אני ממליץ לקרוא קצת על TDD ואת המשמעות של UNIT TESTING בהקשר הזה. כמו כן, יש לא מעט דיונים ברשת בנושא שמסבירים בעיקר מדוע זה רעיון רע. אבל תימצאי גם כאלה שמצדדים במיקרים מסויימים בבדיקה של מתודות PRIVATE

Testing Private Methods Yes or No?
http://blog.developers.ba/post/2009/04/12/Unit-testing-private-methods-yes-or-no.aspx

[atarsh]

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

[LeoBeer]

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

[mot]

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

[atarsh]

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

[mot]

אתם כותבים טסטים שבודקים את כל סוגי הקלטים האפשריים למתודות שאתם בודקים?
אתם כותבים טסטים למחלקה כשמסיימים לכתוב אותה? או אחרי שמסיימים קצת יותר עבודה?

[pulse11]

מה בדיוק העניין של לבדוק פונקציות פנימיות?

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

[atarsh]

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