Код машинного обучения поблочного тестирования

«тогда я на самом деле не проверяю все, что может пойти не так».

Правильно.

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

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

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

Выбирайте свои тесты с умом.

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

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

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

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

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

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

TEST_ALMOST_EQ(result, 4.0);

Выше TEST_ALMOST_EQ может убедиться, что result находится между 3,9 и 4,1 (например).

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

x = 0;
for (100 times) {
  x += result_probabilistic_test();
}

avg = x/100;
TEST_RANGE(avg, 10.0, 15.0);

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

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

НТН.

Как правило, для статистических показателей вы должны добавить эпсилон для своего ответа. И.Е. среднеквадратичная разница ваших точек будет < 0,01 или что-то подобное. Другой вариант - запускать несколько раз, и если он выходит «слишком часто», у вас есть проблема.

1. Получить соответствующий набор тестовых данных (может быть подмножество того, что вы обычно используете)
2. Рассчитать некоторую метрику для этого набора данных (например, точность)
3. Запишите полученное значение ( перекрестная проверка)
4. Это должно дать представление о том, что нужно установить пороговое значение для

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

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