unit-testing ב-VC6...?

[אוֹריארד]

unit-testing ב-VC6...?../images/Emo26.gif

[נסיון שני] אני מחפש סביבת בדיקה (של unit-test) שמתלבשת על VC6 (ל-C ו-CPP)... מישהו מכיר משהו מומלץ? (עבדתי ב-Java עם JUnit בסביבת Eclipse, ונורא חסר כלי-בדיקה בסגנון - מישהו מכיר משהו מומלץ?...) שמעתי שיש CppUnit ו-CUnit, מישהו מכיר?...

 

[vinney]

מה זאת אומרת "סביבת בדיקות"?

למה אתה מתכוון? מה זה אמור לעשות?

 

[אוֹריארד]

זה קצת כמו אורגזמה...../images/Emo26.gif

אם אתה לא בטוח מה זה - סימן שלא היה לך את זה...

זה סט של class-ים שמאפשרת לך לרשת מ-class-ים בסיסים וליצור unit-test לקוד שלך. (קישור לזה של Java. ועוד קישור.) היתרון הוא שהסביבה מעמידה לרשותך מתודות לבדיקה (מין הרחבות של ASSERT) - אבל בניגוד ל-ASSERT היא גם נותנת לך סביבה שיודעת להציג לך בדיוק איזה בדיקות עברו ואיזה לא. כשאתה עובד בסביבת Eclipse למשל - ליד הכפתור שמריץ לך את האפליקציה, יש לך כפתור שמריץ את כל "תוכנית" הבדיקות. אתה מקבל חלון בדומה לתמונה המצורפת - וככה אתה יכול להיות בטוח שהתוספות שלך לא הרסו שום דבר, ושכל הקוד שלך עדיין עושה את מה שרצית. אז ב-Java יש סביבת-בדיקות (testing framework) מאוד מושקעת. עכשיו אני מחפש משהו דומה ל-C ול-CPP...

 

[vinney]

הא....

טוב

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

 

[annefan]

מאיפה הבאת את זה??

לגבי מעטפת גרפית תסתכל כאן (לא עבדתי עם זה, רק שיחקתי בזה לפני שנה+). >>> שברגע שאתה עוטף את הקוד שלך ב"סביבת בדיקות", איכות הבדיקות עצמן נפגעת<<< Would you care to elaborate about that?

 

[selalerer]

../images/Emo32.gif אוי, שרשורפלצת בדרך.

 

[annefan]

למה עוף?

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

 

[selalerer]

מה עוף? מה אתה עושה אותי רעב עכשיו.

 

[Zack DA]

../images/Emo6.gif

 

[אוֹריארד]

../images/Emo45.gif../images/Emo45.gifאכן...

ואכן הזכרתי את CppUnit ואת CUnit - אני מחפש מישהו שעבד איתן ויכול לתת תובנות... ויני - נראה לי באמת שדי פספסת את העניין... לא מדובר כאן באפליקציה נפרדת שרק מבצעת את הבדיקות (למרות שגם כאלה אני מכיר - וגם לגביהן אני לא מסכים איתך - WinRunner, QuickTest, TestDirector). במקרה של חבילות ה-xUnit מדובר במין Design-Pattern של unit-test. ואם תקרא את הקישור של ה-JUnit שהבאתי - תראה שהוא גם מאוד פשוט וגם מאוד יעיל. הקטע של ה-GUI הוא מינורי כאן - הוא פשוט נותן לך איזה חיווי אדום/ירוק שבמבט אחד אומר לך "אתה בסדר. לא דפקת שום-דבר. בינתיים." או משהו כזה. [ואני לא רואה שום סיבה ש-GUI כזה לא ימומש ב-WIN32 למשל. כמו שכתבתי - אני עובד עם VC6]

 

[vinney]

תשמע... תראה...

מנקודת מבט של מתכנת אתה צודק. מנסיון - אתה טועה ובגדול. אין שום ערך לבדיקה שלא בוצעה על הקוד ה"נקי". נכון שUNITEST עושים עם קודי עזר למיניהם שמוציאים לפני הוצאת גרסה, אבל יש הבדל בין MACRO שממש את ASSERT והופך להיות ריק בקוד ייצור, לבין קוד שלם שמתלבש לך על התוכנה ועושה דברים שאתה לא יודע עליהם, ולא משנה איזה DESIGN PATTERN מגבה אותו. אני ראיתי הרבה מאוד רכיבים שעברו UT מצוין, אבל אחרי שהוצא מהם הקוד לצורך הUT, נכשלו באותן הבדיקות עצמן שהUT בדק. יכול להיות שמדובר במתכנת חרא (סביר להניח) אבל כל אחד חושב שהוא טוב. מנסיון של 4+ שנים בעבודת הQA אני אומר לך שהבדיקה שתעשה ככה - לא מספקת. אתה צריך לתכנן בדיקות שתבצע על הקוד הנקי, בלי שום קוד עזר, ושיתנו לך את האישרור הסופי של כל מה שעשית, ולא בהכרח באותו עומק כמו הבדיקות שאתה עושה עם הכלים האלה, אבל גם לא לוותר על החלק הזה. אם הרכיב שלך נכלל במערכת יותר גדולה - כנראה שמישהו אחר יעשה את זה בין כה וכה בבדיקות אינטגרציה וEND TO END, אבל אתה תראה רע מאוד כשימצאו אצלך באגים

 

[אוֹריארד]

נראה לי שלא הבנת...../images/Emo4.gif../images/Emo26.gif

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

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

 

[vinney]

אני מבן../images/Emo13.gif אתה לא הבנת את הנקודה

הכלים האלה עוזרים ומצוינים אבל ברגע שהם יוצאים, הפרוייקט משתנה, לא משנה איך תשים את זה ותקרא לזה - הבדיקות שעשית עשית על קוד אחר, כמו שאתה עצמך כתבת - עם MAIN אחר, מודול נפרד, ועוד כהנה וכהנה דברים. הדברים שזה יכול לגרום הם בד"כ בעיות בנושא זכרון, ניהול מחסנית, בדיקות IO, וגלישת נתונים - כל זה אתה לא בהכרח תתפוס עם הכלים האלה, כך שאתה לא יכול לסמוך עליהם בצורה עיוורת. אני אומר לך את זה, כי נתקלתי בזה, ונתקלתי גם בבאגים נורא מעצבנים שקראו (לי, כן, גם אני חרא מתכנת) שמשום מה לא עליתי עליהם בUT, לא עלו עליהם בSYSTEM TEST ועלו עליהם רק בACCEPTANCE. למה? כי את הUT וST עשינו על גרסאות DEBUG עם הכלים האלה בדיוק, וכשעברנו לגרסת RELEASE (הורדנו את החלקים האלה), בום - גלישת זכרון. אז תשתמש בזה, אלה כלים חזקים וטובים, אבל לעולם אל תשכח - לבדוק את הקוד שיוצא לייצור צריך בגרסת ייצור|סגדש|, בלי שום תוספות/כלים/מעטפות שלא יהיו אצל הלקוח. לגבי הTESTDIRECTOR, WINRUNNER וQUICKTEST שמישהו פה הזכיר, אז אלה כלים שלא כלולים בתוך האפליקציה עצמה, אלא מאפשרים ביצוע אוטומטי של טסטים במקום ידני, אפליקציה לא משתנה, מה שמשתנה זה שאתה לא צריך לעשות את הכל אתה מול המחשב, אלא להריץ סקריפט שידמה משתמש. כלים מצוינים, אני עובד עם כולם, כחול לבן אגב.

 

[vinney]

יופי, אני עם הדיסלקציה שלי ../images/Emo10.gif

 

[אוֹריארד]

גם וגם וגם וגם...../images/Emo13.gif

שמע... הכלים ל-unit-test כשמם כן-הם... הכלים ל-unit-test... ברור שזה לא מספיק... ברור שצריכים גם בדיקות-קבלה, בדיקות בעומס, בדיקות בסביבה בה תרוץ המערכת ועוד ועוד ועוד... אבל בין כל אלה, ברור גם שאותן בדיקות unit-test הן הכרחיות! כך או כך - מה עם השאלה המקורית שלי?... מישהו מכיר חבילה טובה ל-C ו-CPP בסביבת VC?...

 

[annefan]

אבל נתתי

באמת שנתתי

 

[vinney]

מה זה שונה מהASSERT בעצם?

הASSERT מפיל אותך בדיוק בשורה בה הייתה התקלה, וממילא שגיאה אחת לרוב פוסלת הרבה טסטים אחרים, אז למה לעשות כזה דבר בומבסטי? בגלל הGUI?

 

[annefan]

כמה דברים

א. ASSERT הוא פולשני במובן שהוא עלול לשנות את מה שעושה הקוד שלך. ב. JUNIT היא חלק מהגישה של Test-Driven-Development. כלומר הרגע שיש לך UNIT מסוים (ולא ממש משנה מהו, מחלקה, פונקציה) ברגע שיש לך פרוטוטייפ אתה כותב לו טסטים, לפני שהתחלת לממש אותו. רק אחרי שכתבת את הטסטים (שיכולים להיות positive ו-negative) אתה מתחיל לממש. מה שקורה זה שעל כל פונקציה יכולים להיות בין 5 ל-10 טסטים. תכפיל במספר הפונקציות, מחלקות וכו' ותגיע לעשרות ומאות טסטים. אתה תמיד משנה "רק משהו קטן", ו טסטים מתחילים ליפול לך. כשיש לך את התשתית הזו, אתה רואה בדיוק האם הכל עבר, ואם לא איפה הוא נכשל.

 

[Zack DA]

../images/Emo45.gif מסכים עם הנקודה השניה.

זה מאוד מתקשר לגישה של extreme programming. כתיבה של טסטים לפני המימוש - ו- test-unit בהחלט תואם את המודל הזה.

 

[vinney]

מתודולוגית QA

אומרת, ואת זה בארץ לאט לאט מתחילים לקלוט, שכתיבת טסטים צריכה חהיות על בסיס הREQUIREMENTS, וכך למעשה את הUT אתה אמור לכתוב לא כשיש לך PROTOTYPES, אלא כשאתה מתחיל את הDETAILED DESIGN (להבדיל, PROTOTYPES נוצרים בסוף התהליך הזה). הרי יכול להיות מצב שכל הטסטים שלך יעבדו פיקס, והרכיב עדיין לא יעשה את מה שהוא אמור לעשות, אם לכתוב את הUT לפי ההצעה של ANNEFAN (סליחה על האיות אם טעיתי), אין שום דרך לדעת את הרכיב בכלל עושה את מה שהוא אמור, כל מה שאתה יודע זה שהפונקציות מחשבות 2+2 כשאומרים להם, ולא 2-2.