נעים מאוד להכיר! ובקשר ל UNIT TEST

[ori26]

נעים מאוד להכיר! ובקשר ל UNIT TEST

היום כבר הגישה הגורפת (בעיקר באקדמיה - המקדימה את זמנה ביחס לתעשיה לרוב) היא לגבי תיכנות מודולרי וסגור - כלומר, הSPEC נכתב בשפות פורמליות (Z, SPC וכו) ולכן בדיקות הפונקציות והמודלים סגורות וחד משמעיות, כמו כן אני מכירה מספר כילים ל COVERAGE TEST שנעשים ע"י המתכנתים בלבד (ולא ע"י איש הבדיקות). (פשוט לא ידעתי אם זה מעניין אותכם...

דרך אגב, שם נוסף ל SMOKE TEST הוא SANITY TEST. איזה כיף שהקימו את הפורום הזה!

 

[erandd]

תודה על הברכה ובקשר לדברייך

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

 

[0rib]

הערכה שלי: 20 שנה לפחות

לא נראה לי שבעשרים השנים הקרובות יהיה שימוש מעשי בשיטות פורמאליות, למעט בתחומי נישה. זה לא ששיטות פורמאליות הן לא טובות - פשוט, עברנו את השלב שבו טכנולוגיות ושיטות עבודה נבחרות בזכות מה שיש להן להציע, ואנחנו נמצאים בשלב שבו הדברים נבחרים בעיקר בזכות מי שמציע אותם. Multi Threading, לדוגמא, גורם ברוב המקרים לבעיות חמורות בהרבה מאלה שהוא בא לפתור, ולמרות זאת פופולרי ואין סיכוי שיעלם בקרוב. Object Oriented Programming, לדוגמא, נחשב לפתרון אולטימטיבי, עד כדי כך ש- Java לא מאפשרת אף סגנון אחר, וזאת למרות שיש תחומים שהוא מסבך בצורה משמעותית (ומי שמכיר OODBMS שיכול להתחרות במה ש- RDBMS-ים של היום מציעים, מוזמן לחלוק על דעתי). ישנה משפחה של שפות תכנות לא כל כך מפורסמות - APL, J, K, Glee, שתוכניות יוצאות בהן בין פי 10 לפי 100 מכל שפה "קונבנציונאלית" כמו C או Java - ובד"כ רצות מהר יותר. אבל איך שהוא זה לא מעניין אף אחד. ויש עוד אינספור דוגמאות. מה שלא "באופנה" מוגבל לנישות. ועבודה יותר מדויקת (כמו שנדרש ב- Z notation, לדוגמא), לא תכנס לאופנה מעצמה. למי שמתעניין - ספר הסבר על Z notation מצורף לינק.

 

[erandd]

אתר מעולה על UNIT TEST

כאן