Всім привіт! Сьогодні є бажання торкнутися теми автоматизації тестування, а саме – корисних інструментів для написання автотестів на ☕️ Java.
Кожен автотест має щось перевіряти і зазвичай ці перевірки покладають на так звані бібліотеки Assert’ів.
Одною з найпотужніших та найпопулярніших бібліотек Assert’ів для Java є бібліотека 👍 AssertJ (https://assertj.github.io/doc/), про яку далі й піде мова.
1️⃣ Дана бібліотека має окремі модулі для перевірок різних типів даних.
Так, окрім core модуля для JDK типів (String, Iterable, Stream, Path, File, Map, тощо), також є окремі модулі для перевірок однойменних типів.
Наприклад, модуль Guava (для Multimap, Optional, тощо), 🕰 модуль Joda Time (для DateTime та LocalDateTime), 💪 модуль Neo4J (так-так, це для об’єктів найрозповсюдженішої графової БД: Path, Node, Relationship, тощо ), модуль DB (для об’єктів реляційних БД: Table, Row, Column, тощо) і навіть модуль Swing (для валідації графічного інтерфейсу Swing).
2️⃣ AssertJ має вбудовану підтримку механізму Soft assertions, це коли треба в одному тесті зробити декілька перевірок для того, щоб мати якомога більш повну картину про нашу аплікацію. Так, усі знають, що в ідеалі один тест має робити лише одну перевірку, але на практиці це не завжди зручно. Також бібліотека дозволяє об’єднати декілька перевірок в один ⛓ ланцюг, так званий chain перевірок.
3️⃣ Дуже зручною бібліотеку AssertJ робить її можливість порівнювати об’єкти різних типів за вказаними полями. Підчас тестування API це дозволяє швидко та зручно порівнювати, наприклад, EntityCreateModel (модель даних для створення якоїсь сутності через POST запит) з її EntityOutputModel (модель даних, яка відповідає створеній сутності, що отримується через GET запит).
4️⃣ Ще одною цікавою можливістю бібліотеки є припущення (assumptions), які дозволяють створювати умовні тести; у разі виконання припущення, тест виконується нормально, а у випадку невиконання – тест відміняється та помічається як проігнорований. Зазвичай припущення використовують, коли не має сенсу продовжувати виконання поточного тестового методу, наприклад, коли необхідність виконання тесту визначається певною ОС / певним середовищем.
👌Після переходу на AssertJ у нашому проекті зменшилася кодова база, адже ми видалили увесь код, що робив всілякі специфічні перевірки разом із стандартними Assert’ами JUnit та зіставленнями бібліотеки Hamcrest. Сам перехід на AssertJ не зайняв у нас багато часу. До того ж, в офіційній документації є міграційні скрипти та регулярні вирази, що дозволяють пришвидшити процесс переходу.
Тож, ті, хто ще не познайомився з даною бібліотекою, не гайте час та починайте знайомство прямо зараз.
Впевнений, що ⭐️ AssertJ буде вам до смаку та допоможе у вирішенні багатьох ваших задач.
Було б цікаво дізнатись про ваш особистий досвід застосування AssertJ та інших бібліотек Assert’ів для java. Напишіть нам про це в коментах.