Здравствуйте, _hum_, Вы писали:
__>только вот, действительно, я не верю, чтобы в концептуально и алгоритмически сложной системе это было возможно. да и перерасход мысли программиста на создание тестов (а в примере с транспонированием матрицы ваши тесты во много раз по объему и затратам на придумывание превосходят саму реализацию транспонирования) не факт, что окупится.
вот у вас есть длинная спагетя, которая оценивает погоду в данной точке

наркоманский способ тестирования — гонять на исторических данных (наркоманский для тестирования корректности кода)
способ тестирования здорового человека — посмотреть, какие юниты есть. вот, например, юнит считает интеграл. можно написать простейший тест, который считает по элементарному примеру. теперь, оптимизировав ф-ию интегрирования, например, с помощью openmp вам не надо заново запускать на час тест на исторических данных, чтобы проверить 1-1 совпадение или не надо в дебагере по шагам смотреть правильно ли чиселки меняются, вы просто поменяли код интергрирования, прогнали один мгновенно исполняющийся набр тестов по интегрированию самых хитрых, но при этом простых случаев (включающих найденные как баги в предыдущих версиях) и оптимизируете дальше

когда к вам приходит багрепорт, вы не тыкаете с полчаса, его репродюся, а сразу пишете юнит-тест, который дает баг (например, числа сортируются в лексикографическом порядке вместо нормального, сразу пишете тест equal( order("2") < order("12") ), сразу запускаете, он сразу падает, сразу правите код сортировки, запускаете тесты, проверяете, что теперь все работает и ничего старого не поломалось, все, можно релизить

Здравствуйте, _hum_, Вы писали:
__>только вот, действительно, я не верю, чтобы в концептуально и алгоритмически сложной системе это было возможно. да и перерасход мысли программиста на создание тестов (а в примере с транспонированием матрицы ваши тесты во много раз по объему и затратам на придумывание превосходят саму реализацию транспонирования) не факт, что окупится.
вот у вас есть длинная спагетя, которая оценивает погоду в данной точке

наркоманский способ тестирования — гонять на исторических данных (наркоманский для тестирования корректности кода)
способ тестирования здорового человека — посмотреть, какие юниты есть. вот, например, юнит считает интеграл. можно написать простейший тест, который считает по элементарному примеру. теперь, оптимизировав ф-ию интегрирования, например, с помощью openmp вам не надо заново запускать на час тест на исторических данных, чтобы проверить 1-1 совпадение или не надо в дебагере по шагам смотреть правильно ли чиселки меняются, вы просто поменяли код интергрирования, прогнали один мгновенно исполняющийся набр тестов по интегрированию самых хитрых, но при этом простых случаев (включающих найденные как баги в предыдущих версиях) и оптимизируете дальше

когда к вам приходит багрепорт, вы не тыкаете с полчаса, его репродюся, а сразу пишете юнит-тест, который дает баг (например, числа сортируются в лексикографическом порядке вместо нормального, сразу пишете тест equal( order("2") < order("12"), true ), сразу запускаете, он сразу падает, сразу правите код сортировки, запускаете тесты, проверяете, что теперь все работает и ничего старого не поломалось, все, можно релизить