LINUX.ORG.RU

Написание тестов для научного кода

 ,


0

5

Есть код для научных вычислений, вычислительные модули на C и обертка на Python.

Хочу покрыть ключевые функции автоматическими тестами, чтобы быть уверенным, что они не сломались в процессе разработки. Время работы одной функции может доходить до нескольких часов, поэтому тестировать нужно с умом.

Посоветуйсте, пожалуйста, хороший (но краткий) материал чтобы вникнуть в методологию тестирования. Мне нужно не сделать абы как, а понять как это делается правильно. Готов потратить 1-2 дня.

★★★★★

Мне нужно не сделать абы как, а понять как это делается правильно

Готов потратить 1-2 дня.

🤦

mersinvald ★★★★★
()

Время работы одной функции может доходить до нескольких часов

А что, меньше чем на терабайте данных функция запускаться отказывается?

morse ★★★★★
()

Ищите в google по словам unit test , то есть например python unit test tutorial.

Partisan ★★★★★
()
Ответ на: комментарий от morse

Меньше килобайта данных на вход у модели :)

При самых скромных запросах к точности вычислений и заменив некоторые элементы модели упрощенными аналогами можно дойти до 5-10 минут, но не менее (очень медленная сходимость метода).

aquadon ★★★★★
() автор топика
Ответ на: комментарий от aquadon

Подгадай такие входные данные, чтобы сходилось быстрее.

Тебе ж не результат надо получить, а убедиться что метод возвращает ожидаемый результат.

Юнит тестирование тем и отличается от интеграционного, что не принимает в расчет задачи предметной области. Для юнит тестирования тебе совершенно не надо передавать данные, имеющие смысл в контексте физических задач.

morse ★★★★★
()

Разбей эти функции еще на меньшие, которые быстрее выполняются, их и тестируй. Потом добавь большой интеграционный тест высокого уровня с определенными входными и выходными параметрами, не тестируй конкретные значения, всегда проверяй только, что результат в пределах допустимого.

cocucka ★★★★☆
()

Время работы одной функции может доходить до нескольких часов, поэтому тестировать нужно с умом.

Тут сначала распилить код придется, а потом уже тестировать.

Octagon
()

Ключевые слова: interface, mock, fake, stub, integration, unit, benchmark, test case, fixture, black box, white box, fuzzy. Думаю ради науки за пару дней можно разобраться, тыж не из тех неудачников которые годами данные техники осиливают.

pon4ik ★★★★★
()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от Octagon

К слову, когда я работал над «научным кодом», который писали непрограммисты, там проще было сразу тестировать end-to-end, потому что код был одним огромным куском read-only.

Octagon
()

Разве «наука» не подразумевает, что сперва есть тесты, а только потом всякие теории и гипотезы в виде функций в твоем случае? Или у тебя не «наука», а подгоняешь тесты под уже существующую теорию?

anonymous
()
Ответ на: комментарий от anonymous

чтобы быть уверенным, что они не сломались в процессе разработки

Чем читаешь? ТС просит не с данными для тестов помочь, а с оформлением тестов на корректность кода.

Siborgium ★★★★★
()
Ответ на: комментарий от Siborgium

ТС просит не с данными для тестов помочь

«Чем читаешь?» Где я писал про «данные»? Я писал, что тесты уже должны быть. Если тестам нужны данные, то данные тоже уже должны быть. (Тут конечно, есть проблема курицы и яйца, но эта проблема есть и в самой «науке».)

а с оформлением тестов на корректность кода.

«Чем читаешь?» ТС хочет получить «эквивалентные» функции. «Эквивалетность» определяется тем, что функции проходят тесты.

anonymous
()

На эту тему статьи пишут, а ты хочешь чтобы тут на ЛОРе в паре постов все объяснили?

Если есть время и желание, можно напрячь citeseer на тему «тестинг сциентифик софтваре». А если нет времени - судя по «1-2 дня» - это так, то можно просто взять юнит-тест фреймворк, доступный для твоего ЯП, и тестировать при помощи него данные функции. Вообще никто не запрещает использовать юнит-тест фреймворк в извращенной форме, т.е. для не вполне «юнит» тестов, даже переступать через границу В/В (одновременно терстировать логику порграммы и читать/писать файлы, говнотестинг-стайл).

Самая главная проблрема в том, что код может быть неудобен для написания автоматических тестов и все надо переписывать с нуля, с возможной потерей в рантайм производительности и читабельности кода. Ведь разработка технических систем и проведение численного эксперимента - это задачи разного рода, с разными требованиями.

seiken ★★★★★
()

Есть код для научных вычислений

Офигенно детальное описание проблемы.

yvv ★★☆
()

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

yvv ★★☆
()

а мне вот не понятно

что нужно сделать. Если вычислительные модули на С есть и их тоже нужно тестировать, то это не про автоматические тесты. Это скорее про перепроверку решения научной задачи. Там вряд ли получится хоть какая автоматизация, да и за 2 дня никак не разобраться (иначе она не очень научная).

Если модули на С тестировать не нужно и их результату мы доверяем, то значит нужно тестировать интерфейсы и питон. Тогда не важно сколько и как точно что считается, подсовывай фейковую вычислительную функцию.

sshestov ★★
()

Нормальный тест пишется столько же времени, сколько и сам софт.

peregrine ★★★★★
()

Почитай силлабус к iSTQB Foundation, поймёшь что тестирование, это не penis canus.

anonymous
()
Ответ на: комментарий от Liz812

++

кто за семестр не сдаст отчет о тестах, зачет получит только за Хабаровск (или, если не слишком нужный предмет - за Владивосток)!

OnlyAsk
()
Ответ на: комментарий от Liz812

упаси бог брать студентов, тут минимум аспирант нужен.

ZERG ★★★★★
()
Ответ на: комментарий от mersinvald

так везде принято, только в нормальных местах студенты что-то с этого имеют.

ZERG ★★★★★
()

посмотри, как в gsl тесты написаны.

ZERG ★★★★★
()

многочасовые вычисления обычно итеративны, для таких случаев - стоит отдельно протестировать один шаг (в принципе, хоть assert-ами, см. python -O), а вот если качество решений упало - это больше «вручную» определять всё равно, хотя иногда вариант - сделать детерминированный режим

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.