Краще мати або

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

?

Приклад: Ви пишете тестовий набір для тестування функціональності контролера у програмі MVC. Контролер вимагає даних програми з бази даних як вхідних даних під час тесту. Для цього є два варіанти:

• Ви вказуєте, який рядок (и) з тестової бази даних обраний як вхідний (наприклад, 10-й та 412-й рядки)
• Ви використовуєте генератор випадкових чисел для псевдовипадкового вибору даних із бази даних (два ряди, вибрані генератором випадкових чисел)

Перший - детермінований: кожен запуск тесту для одного і того ж перегляду коду повинен давати однаковий результат. Другий недетермінований: кожен запуск тестового набору має можливість дати різний результат. Однак випадково вибрані дані можуть бути кращим представленням випадків крайових даних. Це може імітувати користувача, який краще годує наших контролерів непередбачуваними даними?

Які причини обрати одне над іншим?

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

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

РЕДАКТУВАННЯ: Використання генератора випадкових чисел для вибору деяких тестових даних - це ІМХО іноді ознака занадто ледачого збору добрих даних тесту. Замість того, щоб кидати 100 000 випадково вибраних тестових значень і сподіватися, що цього буде достатньо, щоб випадково виявити всі серйозні помилки, краще скористайтеся своїм мозком, виберіть від 10 до 20 «цікавих» випадків і використовуйте їх для тестового набору. Це призведе не тільки до кращої якості ваших тестів, але і до значно вищої продуктивності набору.

І детерміновані, і недетерміновані мають місце

Я поділив би їх так:

Одиничні тести.

Вони повинні мати детерміновані, повторювані тести з точно такими ж даними кожного разу. Одиничні тести супроводжують конкретні, відокремлені розділи коду і повинні перевірити їх у детермінованому порядку.

Функціональні та вхідні стрес-тести.

Вони можуть використовувати недетермінований підхід із наступними застереженнями:

• цей факт чітко окреслений і заперечений
• вибрані випадкові значення записуються в журнал і їх можна повторно спробувати вручну

І те й інше.

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

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

• Порожній список
• Список лише з одним елементом
• Список із тим самим елементом
• Список з декількома унікальними елементами
• Список з декількома елементами, деякі з яких є дублікатами
• Список з NaN, INT_MINіINT_MAX
• Список, який уже частково відсортований
• Список з 1000000000 елементів

І це лише функція сортування! Звичайно, ви можете стверджувати, що деякі з них непотрібні, або що деякі з них можна виключити за допомогою неофіційних міркувань. Але ми інженери, і ми бачили, як неофіційні міркування спалахують перед нами. Ми знаємо, що ми не досить розумні, щоб повністю зрозуміти побудовані системи або повністю зберегти складність в голові. Ось чому ми в першу чергу пишемо тести. Додавання недетермінованого тестування просто говорить про те, що ми не можемо бути достатньо розумними, щоб знати всі хороші тести апріорі. Закинувши напів випадкові дані у свою функцію, ви набагато більше шансів знайти кращий випадок, який ви пропустили.

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

• Використовуйте недетерміновані тести, щоб знайти помилки у своєму коді.
• Використовуйте детерміновані тести для перевірки виправлень у своєму коді.

Зауважте, що це означає, що багато твердих порад щодо одиничних тестів не обов'язково стосуються недетермінованих тестів. Наприклад, що вони повинні бути швидкими. Тести властивостей низького рівня повинні бути швидкими, але недетермінований тест на зразок "імітувати користувача випадковим чином натисканням кнопок на вашому веб-сайті та переконайтеся, що ви ніколи не отримуєте помилку 500", повинен сприяти всебічності над швидкістю. Просто проведіть такий тест, який виконується незалежно від процесу збирання, щоб це не сповільнило розвиток. Наприклад, запустіть його на власному приватному екрані.

Ви насправді не хочете детермінованих проти недетермінованих.

Те, що ви можете хотіти, це "завжди одне і те ж" проти "не завжди те саме".

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

Але після виявлення помилки, все, що вам потрібно зробити, - це запустити тест з однаковим номером збірки, і він відтворюється.