test driven development

[yooey]

test driven development

היי,

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

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

תודה רבה!

 

[nocgod]

בחברה הקודמת שעבדתי בה בדיקות יחידה היו נדירות

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

אני חושב שפיתוח נכון של רכיבים מנותקים עוזר מאוד לפיתוח בדיקות בקלות. כל מה שהייתי צריך לעשות כדי לבדוק יחידות היה לעשות mock לdependencies שלהם באמצעות ספריית mock (השתמשתי ב moq). סט הבדיקות הראשון היה זוועתי, אבל סט הבדיקות השני כבר הלך הרבה יותר מהר וקל, השלישי היה צ'יק צ'ק כי כבר למדתי איך לעשות את הדברים מהם (כל מה שקשור ל data arrangement זה מחלה)

אגב קראתי איפשהו פעם: TDD is like teen sex: everybody talks about it, only few really do it
אין לי ספר להציע לך, רק ללכלך ידיים לדעתי.

 

[hadooper]

אני חושב שזה מסוג הדברים שכבר הפכו לסטנדרט

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

 

[hadooper]

...

אגב, גם תקשורת בין node-ים שונים זה דבר שבהחלט קל בימינו לסמלץ עם טסטים אוטומטיים. ישנם שמעדיפים לכתוב בעצמם תשתית או (מיני-)ספריית סימולטור, שלאחר מכן עושים בה שימוש בטסטים השונים. או להשתמש במשהו מוכן... למשל לפריימוורק akka יש testkit מודול שמכיל כלי סימולציה לתקשורת בין actor-ים.

 

[ytoledano]

זה מהדברים שמחכים שמישהו ירים את הכפפה

לגבי unit testing, אין קשר בין האם כתבו טסטים עד היום להאם יכתבו טסטים מהיום. הרי כל רכיב חדש הכי קטן שנכתב, יכול להכתב עם unit testing וב TDD או בלי. הזמן פיתוח לא אמור להיות שונה דרסטית אם עושים את זה כמו שצריך.
&nbsp
לגבי רכיבים קיימים, שתי האופציות שאני בד"כ בוחר מבינהן הן:
1. לחכות עד שמשנים שם משהו ואז להוסיף unit test ואת השינוי לעשות TDD
2. לזהות במערכת כמה נקודות שבהן ניתן לכסות הרבה קוד ע"י מעט קלט ובדיקה של מעט פלט ואז לכתוב טסט יותר מקיף. הטסט מזרים קלט ובודק פלט. אפילו אם זו בדיקה שטחית, מהר מסיגים הרבה code coverage. זה לא unit test אבל אפשר לממש את זה הרבה פעמים עם תשתית unit testing כמו Google Test או JUnit.
&nbsp
רוב הסיכויים שבמקום שאתה עובד בו שמעו על טסטים פשוט עושים מה שתמיד עשו. מה שאומר שאם תממש כמה טסטים לא יסתכלו על זה כאל בזבוז זמן. זו הדרך הכי טובה לשכנע אנשים להשתפר.

 

[zaske]

המצב אצלנו וכמה עצות

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

מצב הטסטים בקוד "הישן" יחסית, הוא לא משהו, המצב בקוד של השנים האחרונות - משמעותית יותר טוב, יש מודעות, ועובדים לפי TDD.
אתה תראה שדווקא בגלל אתגרים כמו "אני לא יכול לבדוק את זה", הקוד שלך יכול להפוך לקריא יותר ומודולרי יותר.
אתה גם צריך לחשוב מה אתה באמת בודק -
דוגמא -
אם מישהו כתב שירות שעוטף שימוש ב Google Analytics , ויש לזה טסט משלו, אתה לא צריך לחזור שוב על זה בבדיקה שלך.
מבחינתך תעבוד מול mock , ובכל בדיקה תבדוק איך הקוד שלך אמור להתנהג אם mock מסויים מתנהג בצורה מסויימת. או למשל תוודא שאיזו מתודה נקראית ב flow .

כלומר - כדאי להשתמש ב mocking frameworks - אני עובד בעבודה עם Mockito של Java ועם Jasmine ב javascript .

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

את רכיבי התקשורת תבדוק בנפרד, וכן הלאה.

בנוסף כמובן צריך לבדוק בדיקות שהן integration tests שהכל באמת מנגן.

 

[hadooper]

mocking frameworks נועדו בין היתר גם בשביל..

לקצר את הזמן שבו הטסטים רצים... כדי שהbuild-ים האוטומטיים שרצים ב jenkins (או מערכת CI אחרת כלשהי), לא יקחו זמן רב מדי.
&nbsp
זה קריטי במקומות גדולים שיש בהם הרבה מפתחים שעובדים על פרוייקטים משותפים ואז מישהו שמצ'קן משהו יכול לעקב כתוצאה מכך לעקב את כל היתר (אם כל טסט שרץ עכשיו צריך לגשת ל H2 או ל embedded node של elasticsearch).
&nbsp
אבל במקומות קטנים עם מעט מפתחים, זה פחות קריטי, לפחות לטעמי... וזה אגב מזכיר לי שעד כה לא יצא לי כמעט להשתמש באף ספריית מוקינג, אלא אולי רק בספריית סימולציה ממוקדת-דומיין שמישהו אחר בצוות כבר כתב בעצמו שדואגת לכל בין היתר לכל עניין המוקינג.

 

[zaske]

מצ'קן? מי עובד עם visual source safe

מה אתה ילד?
אם כבר מפשפש מלשון git push

 

[hadooper]

האמת היא שאני לא מחבב את העיברותים הללו

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

 

[yooey]

חברים, תודה רבה על כל התגובות!

העליתם הרבה אופציות מעניינות, תודה