Чи є рамки тестування для чисельної розробки програмного забезпечення

Я виявив, що багато мого програмування з обчислювальної науки мають вимоги до тестування, які не охоплюються стандартними рамками тестування:

1. Тестування на час обчислення

   • Щоб алгоритми не ставали повільнішими. Я міг би зробити щось на кшталт, assureSmallerEqual(RuntimeWrapper(algorithm),53)але я хотів би, щоб поріг у 53 секунди постійно знижувався, коли я працюю над алгоритмом, тобто щось подібнеassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. Тестування продуктивності

   • Щоб переконатися, що алгоритм, який раніше знаходив гарне наближення до аналітичного рішення, все ще знайде рішення, яке є принаймні настільки ж хорошим чи кращим. Знову ж таки, це могло б бути емульовано стандартним тестом на інтеграцію, але я хотів би, щоб допуск постійно зменшувався, коли алгоритм стає все кращим та кращим. Подумайте про заміну assureAlmostEqual(foo(),1,places=3)наassureAlmostEqual(foo(),1,places='previousbest')

3. Тестування фізичних вимог

   • Щоб переконатися, що алгоритмам раптом не потрібно більше пам’яті / місця на жорсткому диску. Дуже схожий на 1.

4. Тестування абстрактних вимог

   • Щоб переконатися, що алгоритму, який спрацював з квадратичним наближенням, раптом не потрібні кубічні наближення, або що алгоритму, який спрацював добре з кроком часу 0,1, раптом не потрібно 0,01 для стабільності. Знову ж таки, вони могли б бути імітовані стандартними тестами інтеграції, але мета - пам’ятати, який найменший параметр вимоги був, що досяг певної мети, тому для цього потрібно було б багато ручного оновлення. Наприклад, якщо foo(10)раніше не було винятків, я б хотів, щоб рамка переконалася, що вона foo(10)все ще працює, а також спробувати, якщо foo(9)зараз працює (у такому випадку всі майбутні тести забезпечать, що foo(9)все ще працює).

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

PS

Подібне назване запитання /programming/34982863/framework-for-regression-testing-of-numerical-code не є дублікатом, оскільки описує функціональність, яку легше досягти за допомогою стандартних рамок тестування регресії.

Питання Стратегії для тестування одиниць і тестових розробок задають стратегії, а не рамки, які допомагають реалізувати їх (а стратегії, про які він запитує / які надаються у відповідях, на мій погляд, відрізняються від описаних тут).

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

2. Я вважаю, що це неоднозначне і небажане з точки зору тестування програмного забезпечення з тих же причин 1 , ви втрачаєте обґрунтування пропуску чи відмови для тестування програмного забезпечення.

3. Це досить часто, дозвольте описати одне рішення. Це не зовсім завдання тестування рамки, але ви можете використовувати окремий інструмент, як описано в питанні Unix SE Обмежити використання пам'яті для одного процесу Linux . Один із стандартних інструментів, який слід спробувати спочатку, - це ulimitкоманда введення bash, яка дозволяє запустити процес і переконатися, що він виходить з ладу, якщо він намагається, наприклад, виділити занадто багато пам'яті. Отже, якщо ви запускаєте runtestsскрипт з обмеженням пам’яті, він вийде з ладу, і тестова рамка повинна бути в змозі обробити це як звичайний тест-збій.

4. Більшість фреймворків тестування не думають одиниці тестує цей шлях на всіх . Тестовий набір запускається (наприклад, перед введенням коду для управління або перед розгортанням), і результатом є "так" або "ні", що вказує на функціонування. Рамки тестування не вважають його частиною своєї роботи, наприклад, відстежувати прогрес функції, і це не те, що тестування зазвичай є. Що ви тут би зробили - це написати два тести expect_succeeds(foo(10)); expect_fails(foo(9)). Кожен раз проводяться обидва тести, і успіхи та очікувані невдачі проходять. Коли ви реалізуєте, foo(9)і це успішно, тест очікування-відмови зараз виходить з ладу, тому ви перезаписуєтесьexpect_succeeds(foo(9)), і це абсолютно стандартна особливість усіх фреймворків. Але ви повинні бути чіткими щодо того, на яку поведінку ви розраховуєте, бо в іншому випадку це дуже суперечить основним ідеям тестування програмного забезпечення.

$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$, і (b) більше немає сенсу порівнювати код з тим, яким він був раніше, усі коди та тести тепер незмінні та однозначні. Це по духу схоже на те, як можна працювати з переписуваннями системи.