Чи погана практика примусово виконувати наказ про виконання одиничних тестів?

Я пишу тести для проекту, який складається з декількох підмодулів. Кожен тестовий випадок, який я написав, працює незалежно один від одного, і я очищаю всі дані між тестами.

Хоча тести виконуються незалежно, я розглядаю можливість виконання наказу про виконання, оскільки для деяких випадків потрібно більше ніж один підмодуль. Наприклад, підмодуль генерує дані, а інший виконує запити на дані. Якщо підмодуль, що генерує дані, містить помилку, тест для підмодуля запиту також буде відмовити, навіть якщо сам підмодуль працює нормально.

Я не можу працювати з фіктивними даними, оскільки основна функціональність, яку я тестую, - це підключення до віддаленого сервера чорної скриньки, який отримує дані лише з першого підмодуля.

У цьому випадку, чи нормально виконувати наказ про виконання тестів чи це погана практика? Я відчуваю, що в цій установці запах, але я не можу знайти кращого шляху.

редагувати: питання в тому, як структурувати тести, коли один тест - це налаштування іншого тесту? оскільки "попередній" тест не є налаштуванням, а тестує код, який виконує налаштування.

Я не можу працювати з фіктивними даними, оскільки основна функціональність, яку я тестую, - це підключення до віддаленого сервера чорної скриньки, який отримує дані лише з першого підмодуля.

Це ключова частина для мене. Можна говорити про «тестові одиниці» та про те, що вони «працюють незалежно один від одного», але всі вони звучать так, ніби вони залежать від цього віддаленого сервера та залежать від «першого підмодуля». Тож все звучить щільно поєднано і залежить від зовнішнього стану. Таким чином, ви фактично пишете інтеграційні тести. Здійснення цих тестів у визначеному порядку цілком нормально, оскільки вони сильно залежать від зовнішніх факторів. Впорядкований тестовий пробіг з можливістю дострокового виходу з тестового запуску, якщо все піде не так, цілком прийнятний для інтеграційних тестів.

Але також варто по-новому поглянути на структуру вашого додатка. Можливість висміювати перший підмодуль та зовнішній сервер, тоді потенційно дозволить вам написати справжні одиничні тести для всіх інших підмодулів.

Так, це погана практика.

Як правило, тест одиниці призначений для тестування однієї одиниці коду (наприклад, однієї функції на основі відомого стану).

Коли ви хочете перевірити ланцюжок подій, які можуть трапитися в дикій природі, вам потрібен інший стиль тесту, наприклад тест на інтеграцію. Це ще більше вірно, якщо ви залежите від послуги третьої сторони.

Для тестування таких тестів потрібно розробити спосіб введення манекенових даних, наприклад, реалізувати інтерфейс служби передачі даних, який відображає запит в Інтернеті, але повертає відомі дані з локального файлу даних манекена.

Запропонований вами наказ про виконання має сенс лише у тому випадку, якщо ви також скасуєте тестовий запуск після першого відмови.

Відмова від тестового запуску під час першого відмови означає, що кожен тестовий запуск може виявити лише одну проблему, і він не може знайти нові проблеми, поки не будуть усунені всі попередні проблеми. Якщо перший запуск тесту виявить проблему, яка потребує місяця, щоб виправити, то протягом цього місяця фактично ніякі тести не виконуватимуться.

Якщо ви не скасуєте тестовий запуск під час першої відмови, тоді примусовий наказ про виконання нічого не купує, тому що кожен невдалий тест потрібно перевірити в будь-якому випадку. Навіть якщо тільки підтвердити, що тест на підмодулі запиту не вдається через той збій, який також був визначений у підмодулі, що генерує дані.

Найкраща порада, яку я можу дати, - написати тести таким чином, щоб було легко визначити, коли невдача в залежності викликає тест.

Запах, на який ви посилаєтесь, - це застосування неправильних наборів обмежень та правил до ваших тестів.

Блок тестів часто плутають з "автоматизованим тестуванням" або "автоматизованим тестуванням програмістом".

Тести одиниць повинні бути невеликими, незалежними та швидкими.

Деякі люди неправильно читають це як "автоматизовані тести, написані програмістом, повинні бути невеликими незалежними та швидкими" . Але це просто означає, що якщо ваші тести не малі, незалежні і швидкі, вони не є одиничними тестами, і тому деякі правила для тестів для модулів не повинні, не можуть або не повинні застосовуватися до ваших тестів. Тривіальний приклад: ви повинні запускати свої Тести одиниць після кожної збірки, чого ви не повинні робити для автоматичних тестів, які не є швидкими.

Хоча ваші тести не є модульними тестами, означають, що ви можете пропустити одне правило і вам дозволяється мати певну взаємозалежність між тестами, ви також з’ясували, що є й інші правила, які, можливо, ви пропустили і вам потрібно буде знову ввести - щось для сфери іншого питання .

Як зазначалося вище, те, що ви працюєте, здається інтеграційним тестом, проте ви заявляєте, що:

Наприклад, підмодуль генерує дані, а інший виконує запити на дані. Якщо підмодуль, що генерує дані, містить помилку, тест для підмодуля запиту також буде відмовити, навіть якщо сам підмодуль працює нормально.

І це може бути хорошим місцем для початку рефакторингу. Модуль, який виконує запити на дані, не повинен залежати від конкретної реалізації першого (генеруючого даних) модуля. Натомість було б краще ввести інтерфейс, що містить методи, щоб дістатись до цих даних, і це може бути вилучено для тестування запитів.

напр

Якщо у вас є:

class Queries {

    int GetTheNumber() {
        var dataModule = new Submodule1();
        var data = dataModule.GetData();
        return ... run some query on data
    }
}

Натомість віддайте перевагу:

interface DataModule {
    Data GetData();
}


class Queries {

    IDataModule _dataModule;

    ctor(IDataModule dataModule) {
       _dataModule = dataModule;
    }

    int GetTheNumber() {
        var data = _dataModule.GetData();
        return ... run some query on data
    }
}

Це знімає залежність від запитів на вашому джерелі даних і дозволяє налаштувати легко повторювані тестові одиниці для конкретних сценаріїв.

В інших відповідях йдеться про те, що замовлення тестів є поганим (що є правдою більшу частину часу), але є одна вагома причина для виконання порядку на виконання тесту: переконайтеся, що ваші повільні тести (тобто інтеграційні тести) запускаються після ваших швидших тестів (тестів які не покладаються на інші зовнішні ресурси). Це гарантує швидше виконання більшої кількості тестів, що може прискорити цикл зворотного зв’язку.