Стратегії для тестування одиниць та тестових розробок

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

Як правило, ви не знаєте точної відповіді на задану складну проблему апріорі, тож як можна написати тест?
Ступінь паралелізму змінюється; Нещодавно я стикався з помилкою, коли використання MPI-завдань як кратного 3 не вдалося, але множина 2 працювала. Крім того, загальні рамки тестування не виглядають дуже зручними для MPI через саму природу MPI - вам доведеться повторно виконати тестовий бінарний файл, щоб змінити кількість завдань.
Наукові коди часто мають багато щільно з'єднаних, взаємозалежних та взаємозамінних частин. Ми всі бачили застарілий код і знаємо, як заманливо відмовитися від хорошого дизайну та використовувати глобальні змінні.
Часто числовий метод може бути "експериментом", або кодер не повністю розуміє, як він працює, і намагається його зрозуміти, тому передбачити результати неможливо.

Деякі приклади тестів, які я пишу для наукового коду:

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

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

testing

— Аврелій
джерело

Не могли б ви пояснити, що ви маєте на увазі під тестами інтерполяції?

— Дмитро Кабанов

Відповіді:

Спосіб виготовлених розчинів .

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

Збереження відповіді. Відтворення розв'язків з розумом та нормою.

— Білл Барт
джерело

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

— Аврелій

2 \times 2 \times 2

$2\times 2\times 2$

Багато літератури, яку я бачив про MMS, - це в основному глобальні рішення, наприклад, для проблем із КФР, виготовлене рішення може бути аналізом на крилах. Коли цей тест провалюється, ви, в кращому випадку, звузили винуватця до 5000 рядків коду, тому для TDD це зовсім марно - у вас немає поняття, звідки відбувається фактичний збій. Я погоджуюся, що проблема 2x2x2 надзвичайно цінна, і я особисто їх дуже багато використовую. Але досить часто зустрічаються проблеми, які виникають лише з більшими системами; Нещодавно я фактично виявив помилку компілятора ifort, яка виявлялася лише у великих проблемах.

— Аврелій

@Aurelius: Тут немає аргументів. У вас повинен бути ряд тестів і виконувати їх усі часто.

— Білл Барт

@ Aurelius За номіналом MMS - це не одиничний тест, а функціональний або прийнятний тест (тобто для всієї системи). Однак коди часто мають окремі етапи (або їх можна розділити). наприклад, адвекція, тиск, в'язкість. Потім можна було протестувати лише один із цих етапів ("одиницю"). Аналогічно, код можна перевірити і без BC, а потім з одним. Друг зробив докторську ступінь з одиничного тестування, і він вважав найбільшу користь, якщо це змусило вас розбити свою програму на одиниці, так що вона може бути перевірена одиницею ... можливо, це більше застосовано тут, ніж здається спочатку (і іншими способами, яких я не знаю).

— гіперпалій

Білл вже перерахував кілька методів, які вирішують ваші проблеми.

Звертаючись до своєї третьої точки, ні, немає підстав для введення сильної зв'язку між частинами. Якраз навпаки: якщо ваші функції чи класи мають чітко визначені інтерфейси, буде набагато простіше обмінятись, наприклад, лінійним розв'язувачем на інший, або за часом крокової схемою. Просто опирайтеся цьому, і тоді ви зможете протестувати ці компоненти окремо. Ми робили це з угодами.II протягом десятиліть.

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

— Гвідо Канщат
джерело

Щоб додати відповідь Гідо, досвід, з якого він говорить, кодується в ~ 3000 тестів, які ми проводимо на deal.II після кожної зміни: dealii.org/developer/development/… . На питання, що робити, якщо ви не знаєте точної відповіді: все одно напишіть тест і дозвольте йому порівняти відповідь сьогодні з відповіддю вчора (або коли ви писали тест). Спосіб виявити зміни у виведенні коду є цінним, навіть якщо ви не знаєте, чи зробили вони відповідь неправильною чи виправили раніше неправильну відповідь.

— Вольфганг Бангерт

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

http://cyber.ua.edu/files/2014/12/u0015_0000001_0001551.pdf

— круги
джерело

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

— Годрік Сеєр

Посилання мертва. Ви мали на увазі: Nanthaamornphong, A. "Ефективність методів тестування та рефакторингу в галузі обчислювальної та інженерної розробки програмного забезпечення". Доктор наук, ун-т. Алабама (2014).

— AlQuemist