Чому ви також повинні застосовувати чисті кодові процеси для тестування коду; Девбрідж
Чому вам також слід застосовувати чисті кодові процеси для тестування коду
Більшість розробників докладають багато зусиль для створення хорошої структури коду. Це означає послідовне іменування класів і методів, послідовне розміщення їх у потрібних пакетах, правильне групування та прийняття належних процесів.
Подібні правила чистого коду також повинні застосовуватися і до тестового коду, але цю категорію часто нехтують.
В результаті розробники часто мають різні думки щодо написання тестів. Різні думки - це не завжди погано, але якщо ви хочете додати порядок до своєї тестової бази, ця стаття може допомогти.
У цій статті я розгляну деякі вказівки, яких ми дотримуємось, щоб забезпечити упорядкованість тестового коду під час роботи над проектами Java. Ці вказівки не завжди можуть працювати для вашого конкретного проекту або команди, але їх все-таки варто врахувати, починаючи наступний проект.
Розділювальні тести
Класифікація
Перш ніж розділяти тести, нам потрібно визначити різні категорії. Теоретично це повинно бути просто: існують модульні тести, інтеграційні тести та наскрізні тести. Все, що вам потрібно зробити, це розділити їх. Однак є сірі ділянки. Деякі інтеграційні тести можна згрупувати з модульними тестами, а деякі модульні тести можуть використовувати зовнішню залежність, але все ще мають позначення модульних тестів.
У тестовому блозі Google є стаття про те, як відкинути стандартні імена для тестів та ввести «малі», «середні» та «великі» тести. Ми не йдемо до цих крайнощів, але швидкість тесту є хорошим показником того, як його слід класифікувати. Ви можете вирішити, наскільки суворим ви хочете бути. Зазвичай ми розділяємо тести наступним чином:
Розлука
Тести модулів та інтеграції складаються разом та розділяються іменуванням. Класи модульних тестів закінчуються на * Test.java; інтеграційні тести закінчуються на * IT.java. Це дозволяє розподіляти утиліти для тестування між інтеграцією та модульними тестами, але оскільки інтеграційні тести повільніші, їх незручно запускати повторно. JUnit 5 підтримуватиме теги та відкриватиме нові можливості в майбутньому. Наразі, якщо ви використовуєте JUnit 4, існують інші способи запуску тестів.
За замовчуванням плагін Maven Failsafe розпізнає **/ІТ * .java, **/* IT.java, і **/* ITCase.java (або можна налаштувати на). Вам просто потрібно увімкнути цей плагін, додавши його до pom.xml і запустивши команду "mvn підтвердити." IntelliJ не підтримує тестове розділення поза коробкою, але його можна легко налаштувати, створивши дві конфігурації запуску:
Усі налаштування за замовчуванням - лише шаблони відрізняються. Їх можна налаштувати на більшу кількість випадків, але в більшості випадків ці прості шаблони регулярних виразів повинні працювати:
Зазвичай системні тести не потребують доступу до вихідного коду програми. Вони написані так, як система буде споживатися іншими системами. Наприклад, якщо це послуга REST, то ці тести надсилатимуть запити HTTP для затвердження відповідей. Їх слід розмістити в окремому кореневому коді джерела або - ще краще - в окремому проекті. Тому для їх окремого запуску не потрібна додаткова робота.
Зберігання коду
Навіть коли ваша команда вирішує добре висвітлити тестування, не завжди легко дотримуватися цієї мети. У міру просування проектів або зростання команди важлива логіка може виявитись тестами (потрібно швидко виправити, закінчується спринт, а функції все ще не закінчені тощо).
Щоб код був добре перевіреним, найголовніше - це спільне розуміння в команді. Якщо члени команди не хочуть писати тести або не бачать користі від їх використання, жодна порада чи стратегія не допоможуть.
Зберігання тестів у чистоті
Це може здатися очевидним, але розробники часто намагаються рефакторифікувати виробничий код і забувають, що ті самі правила чистого коду застосовуються і до тестового коду. Якщо тестовий код безлад, тоді зміни для класу чи функції не перевірятимуться - ніхто не захоче торкатися коду. Для таких тестів розробники зазвичай змінюють виробничий код, а потім намагаються виправити невдалі тести, змінюючи твердження, щоб очікувати нової поведінки.
Одного разу мені довелося оновити якусь логіку клієнта веб-служби, я виявив дивну логіку і подумав, що, роблячи це виглядати «правильно», я вдосконалюю код. Виявилося, що веб-сервіс глючив. Це працювало лише з цими дивними значеннями, але оскільки в тесті це не було зрозуміло, я вважав, що це помилка - і в тесті, і в виробничому коді.
Завжди виконує тести
Бувають випадки, коли вам може знадобитися тимчасово ігнорувати деякі тести. Це рідко, але буває. Якщо ви занадто довго ігноруєте тест, ділова логіка може змінитися настільки, що простіше просто видалити тест і забути його.