'תכנות מונחה טסטים' מישהו מכיר?

[שימיגם]

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

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

 

[פרוגיוזרית]

רק לדייק את המינוח:

Test-driven development - Wikipedia

en.wikipedia.org

במקום לירות את החץ ואז לצייר את המטרה, מציירים את המטרה ומנסים לירות אליה את החץ.
לא התנסיתי, אבל שמעתי על זה בעבר.

 

[java]

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

 

[trew]

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

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

 

[שימיגם]

לא עולה לגיט אם הוא לא מימש את היעוד שלו

^זה משפט לפני האחרון
צריך גם לבדוק שיהיה ייעוד?
אני הבנתי שחלק מהכיף / מהקסם זה רק שהוא עובר טסטים והייעוד נהיה ממילא
כלומר - זה כאב ראש של כותב הטסטים
לא?

 

[trew]

^זה משפט לפני האחרון
צריך גם לבדוק שיהיה ייעוד?
אני הבנתי שחלק מהכיף / מהקסם זה רק שהוא עובר טסטים והייעוד נהיה ממילא
כלומר - זה כאב ראש של כותב הטסטים
לא?

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

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

למי שלא מכיר BDD הבדיקות נראות כך

 

[רפ]

אצלנו עובדים בbiq - built in quality, מה שאומר שהמפתח כותב את כל הטסטים לקוד שלו.
ניסו בעבר לגרום לנו לעבוד בצורה דומה לtdd, שבה מתכננים טסטים מראש ולפי זה מממשים את המשימות.
כולנו התנגדנו בתוקף לאחר שני נסיונות כושלים.

 

[גזעי]

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

 

[רפ]

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

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

 

[java]

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

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

 

[trew]

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

נכון אבל זה לא המקרה בכל המקומות לצער כולנו
בכל אופן מדובר רק על Unit test

 

[java]

Unit test

יצא לי כמה פעמים לכתוב e2e tests
(Cypress)

 

[פרוגיוזרית]

אצלנו גם, כל מה שאני כותבת אני בודקת. מה שאפשר בUT, ומה שלא בE2E

 

[5127109]

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

 

[5127109]

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

מדוע כל כך חשוב להכשל במבחן?

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

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

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

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

 

[שימיגם]

נראה לי שב nest יש סקריפט של בדיקה שנקרא e2e
לא השתמשתי, אבל נראה לי שזה סתם בדיקה אוטמאטית שהאפליקציה עובדת

 

[רפ]

יצא לי כמה פעמים לכתוב e2e tests
(Cypress)

אצלנו גם, כל מה שאני כותבת אני בודקת. מה שאפשר בUT, ומה שלא בE2E

אז אצלנו המפתחים כותבים את כל סוגי הטסטים:
Unit Tests
E2E
UI Test - Cypress with mocks
API Tests
DB Tests

 

[chaya63]

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

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

למי שלא מכיר BDD הבדיקות נראות כך

צפה בקובץ המצורף 752121​

רק בשביל לעשות סדר...

TDD זה בעצם test driven development והמשמעות של זה היא שקודם כל כותבים טסט ואח"כ כותבים קוד אמיתי שמממש את הטסט.
בTDD לעולם לא תכתבו שורת קוד (production code) לפני שיש שורת טסט שנפלה.
זה "להפוך את הראש". במקום לתכנן איך ייראה הקוד וממה הוא בנוי, מתחילים בכלל מהטסטים. כמובן המתכנת הוא זה שכותב את הטסטים ואת הקוד.
הסטפים בד"כ יהיו:
.1 לכתוב טסט (בהינתן X אני מצפה שהתוצאה תהיה Y)
2. להריץ את הטסט - הטסט נופל
3. לכתוב קוד שיגרום לטסט לעבור (מינמום קוד הנדרש לכך)
4. לבדוק אם ניתן לשפר או לשכתב את הקוד, להוציא לפונקציות וכו'
להתחיל מהתחלה...

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

BDD זה behavior driven development
מדובר על כתיבת טסטים של E2E כדוגמת feature files. (כמו ש @trew הביאה כדוגמה) לא דווקא המתכנת אמור לכתוב את הטסט, הוא יכול להיות נכתב ע"י QA מראש, או אפילו איש הפרודקט כחלק מהגדרת הציפיות מהמוצר.
ואז שוב כמו בTDD - הטסט נכתב ראשון, ואחריו כותבים תוכנית שאמורה להתאים בדיוק לתיאור בטסט E2E, שאמור לעבור בהצלחה. כאן אין בהכרח שנוי בצורת העבודה. רק ההגדרה של לחשוב על הFLOW ועל הבדיקה בהתחלה.