streamalism.org

1. הקדמה

ה- JUnit 5 שיצא לאחרונה הוא הגרסה הבאה של מסגרת הבדיקות הידועה עבור Java. גרסה זו כוללת מספר תכונות הממוקדות במיוחד לפונקציונליות שהוצגה ב- Java 8 - זה נבנה בעיקר סביב השימוש בביטויי למבדה.

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

2. בדיקות JUnit 5 פשוטות

במיטבו הפשוט ביותר, מבחן JUnit 5 שנכתב בקוטלין עובד בדיוק כצפוי. אנו כותבים שיעור בחינה, מציינים את שיטות הבדיקה שלנו עם ה- @מִבְחָן ביאור, כתוב את הקוד שלנו ובצע את ההצהרות:

class CalculatorTest {calculator calculator = Calculator () @Test fun whenAdding1and3_thenAnswerIs4 () {Assertions.assertEquals (4, calculator.add (1, 3))}}

הכל כאן פשוט עובד מחוץ לקופסה. אנחנו יכולים לעשות שימוש בתקן @Test, @BeforeAll, @BeforeEach, @AfterEach, ו @אחרי הכל ביאורים. אנחנו יכולים גם לקיים אינטראקציה עם שדות בכיתת הבדיקה בדיוק כמו ב- Java.

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

לפני שנמשיך הלאה, בוא נשנה את שם הבדיקה והשתמש בה במזהים אקטיקים בקוטלין:

@Test fun `הוספת 1 ו- 3 צריכה להיות שווה ל- 4 '() {Assertions.assertEquals (4, calculator.add (1, 3))}

עכשיו זה הרבה יותר קריא! ב- Kotlin אנו יכולים להכריז על כל המשתנים והפונקציות באמצעות backticks, אך לא מומלץ לעשות זאת למקרי שימוש רגילים.

3. קביעות מתקדמות

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

3.1. קביעת חריגים

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

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

כיף @Test `חלוקה באפס צריכה לזרוק את DivideByZeroException` () {val exception = Assertions.assertThrows (DivideByZeroException :: class.java) {calculator.divide (5, 0)} Assertions.assertEquals (5, exception.numerator)}

קוד זה עובד בדיוק כמו המקביל ל- Java אך קל יותר לקריאהמכיוון שאיננו צריכים להעביר למבדה בתוך הסוגריים שבהם אנו מכנים טוען זורק פוּנקצִיָה.

3.2. קביעות מרובות

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

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

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

נכון לעכשיו, אין תמיכה בהטלה אוטומטית של למבדה לממשק פונקציונלי, ולכן עלינו לעשות זאת ביד:

כיף `הריבוע של המספר צריך להיות שווה למספר זה המוכפל בפני עצמו" () {Assertions.assertAll (Executable {Assertions.assertEquals (1, calculator.square (1))}, Executable {Assertions.assertEquals (4, calculator .square (2))}, הפעלה {Assertions.assertEquals (9, calculator.square (3))}}}

3.3. ספקים לבדיקות אמת ושקר

מדי פעם, אנו רוצים לבדוק שחלק מהשיחות מחזירות א נָכוֹן אוֹ שֶׁקֶר ערך. היסטורית היינו מחשבים ערך זה וקוראים לטעון נכון אוֹ לטעון שקר כראוי. JUnit 5 מאפשר לספק במקום למבדה שמחזיר את הערך הנבדק.

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

@Test fun `isEmpty צריך להחזיר true עבור רשימות ריקות '() {val list = listOf () Assertions.assertTrue (list :: isEmpty)}

3.4. ספקים להודעות כשל

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

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

זה יכול לעזור לגרום למבחנים לרוץ מהר יותר ולהפחית את זמני הבנייה. זה עובד בדיוק כמו שראינו קודם:

כיף @ מבחן '3 שווה ל -4' () {Assertions.assertEquals (3, 4) {"שלושה אינם שווים לארבעה"}}

4. בדיקות מבוססות נתונים

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

4.1. שיטות TestFactory

הדרך הקלה ביותר להתמודד עם בדיקות מונעות נתונים היא באמצעות @TestFactory ביאור. זה מחליף את @מִבְחָן ביאור, והשיטה מחזירה אוסף כלשהו של DynamicNode מקרים - נוצרים בדרך כלל על ידי שיחות DynamicTest.dynamicTest.

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

@TestFactory כיף testSquares () = listOf (DynamicTest.dynamicTest ("כשאני מחשב 1 ^ 2 אז אני מקבל 1") {Assertions.assertEquals (1, calculator.square (1))}, DynamicTest.dynamicTest ("כשאני מחשב 2 ^ 2 ואז אני מקבל 4 ") {Assertions.assertEquals (4, calculator.square (2))}, DynamicTest.dynamicTest (" כשאני מחשב 3 ^ 2 אז אני מקבל 9 ") {Assertions.assertEquals (9, מחשבון . ריבוע (3))})

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

@TestFactory כיף testSquares () = listOf (1 עד 1, 2 עד 4, 3 עד 9, 4 עד 16, 5 עד 25) .map {(קלט, צפוי) -> DynamicTest.dynamicTest ("כאשר אני מחשב $ input ^ 2 ואז אני מקבל $ צפוי ") {Assertions.assertEquals (צפוי, calculator.square (קלט))}}

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

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

ריבועי val פרטיים TestData = listOf (1 עד 1, 2 עד 4, 3 עד 9, 4 עד 16, 5 עד 25) 

@TestFactory כיף testSquares () = squaresTestData .map {(קלט, צפוי) -> DynamicTest.dynamicTest ("כשאני מחשבת $ קלט ^ 2 אז אני מקבל $ צפוי") {Assertions.assertEquals (צפוי, calculator.square (קלט) )}}

@TestFactory כיף testSquareRoots () = squaresTestData .map {(צפוי, קלט) -> DynamicTest.dynamicTest ("כשאני מחשב את השורש הריבועי של קלט $ אז אני מקבל $ צפוי") {Assertions.assertEquals (צפוי, calculator.squareRoot ( קלט))}}

4.2. בדיקות פרמטריות

יש הרחבות ניסיוניות ל- JUnit 5 כדי לאפשר דרכים קלות יותר לכתוב בדיקות פרמטריות. אלה נעשים באמצעות @ParameterizedTest ביאור מה- org.junit.jupiter: junit-jupiter-params תלות:

 org.junit.jupiter junit-jupiter-params 5.0.0 

ניתן למצוא את הגרסה האחרונה ב- Maven Central.

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

@ParameterizedTest @MethodSource ("ריבועים") כיף testSquares (קלט: Int, צפוי: Int) {Assertions.assertEquals (צפוי, קלט * קלט)} אובייקט נלווה {@JvmStatic כיכר ריבועים () = listOf (Arguments.of (1, 1), Arguments.of (2, 4))}

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

כל שאר דרכי השימוש במבחנים פרמטרים עובדות זהה בקוטלין כמו ב- Java. @CsvSource יש כאן הערה מיוחדת, מכיוון שאנחנו יכולים להשתמש בזה במקום @MethodSource לקבלת נתוני בדיקות פשוטים לרוב כדי להפוך את הבדיקות שלנו לקריאות יותר:

@ParameterizedTest @CsvSource ("1, 1", "2, 4", "3, 9") כיף testSquares (קלט: Int, צפוי: Int) {Assertions.assertEquals (צפוי, קלט * קלט)}

5. בדיקות מתויגות

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

@ תגיות (תג ("איטי"), תג ("לוגריתמים")) כיף @ מבחן `התחבר לבסיס 2 מתוך 8 צריך להיות שווה ל -3 '() {Assertions.assertEquals (3.0, calculator.log (2, 8) )}

זה נדרש גם ב- Java 7 ונתמך באופן מלא על ידי JUnit 5 כבר.

6. סיכום

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

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

דוגמאות לכל התכונות הללו ניתן למצוא באתר GitHub.