Есть несколько стратегий, которые вы можете использовать для решения каждой из ваших проблем.Я начну с самого важного, Юнит-тестирование не должно использоваться для проверки фактов вне домена вашего приложения .Это означает, что вы не будете проводить модульное тестирование сторонней библиотеки GUI и не будете использовать ее для проверки того, что математическая теория верна .Вы не проверяете, что 5 + 5 на самом деле равно 10, вам нужно только доказать, что ваша реализация сложения дает некоторые правильные результаты.
Таким образом, вы обычно не используете модульное тестирование, чтобы показать, что ваша нейронная сеть сходится, как ожидалось.Такое поведение, как известно, работает.Вам нужно только доказать, что ваш код реализует ограничения и поведения, необходимые для применения внешней теории нейронных сетей.
Все это сводится к тому, что вы проверяете правильные вещи.Убедитесь, что вы тестируете только юниты.
Следующая стратегия, особенно используемая для более высоких уровней абстракции в вашем приложении, заключается в замене слоев ниже, чем тестируемый юнит, специальными версиями, которые демонстрируют известное поведение .Это примерно идея пробного тестирования.Например, при тестировании чего-либо, взаимодействующего с базой данных, обычно не требуется, чтобы тестируемый код взаимодействовал с реальной базой данных.С одной стороны, базы данных сохраняют состояние, и вы не хотите, чтобы при модульном тестировании тесты были атомарными и независимыми.Другая проблема заключается в том, что внешняя база данных может привести к сбою теста по причинам, не зависящим от тестируемого модуля.
Решение состоит в том, чтобы внедрить ложный слой базы данных, который отвечает тому же API, что и реальная база данных, но предоставляет подготовленные ответы под контролем самого модульного теста.
Продолжая это на примере нейронной сети, предположим, что мы хотим протестировать алгоритм обратной поддержки.Модульный тест может внедрить фиктивную сеть, которая обеспечивает выходные данные, которые отличаются от обучающих данных определенными способами, и модульный тест проверяет, что код обратной поддержки корректно изменяет правильные веса.Таким образом мы можем устранить чувствительность тестов к поведению сети, изолируя, таким образом, только проверяемый код обратной поддержки.
Специально для тестирования кода, обращенного к пользователю, обычным процессом является интеграция тестирование, при котором для взаимодействия с приложением используются специальные знания конкретного пользовательского интерфейса (Qt или html или любой другой).В основном это происходит путем стимулирования событий пользовательского интерфейса, связанных с определенной функцией, а затем проверки того, что события распространяются на соответствующие изменения в уровне модели