Обсуждение статьи "Пользовательские инструменты отладки и профилирования для разработки на MQL5 (Часть III): Регрессионный контроль производительности и торговых правил"

[MetaQuotes]

Опубликована статья Пользовательские инструменты отладки и профилирования для разработки на MQL5 (Часть III): Регрессионный контроль производительности и торговых правил:

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

В Части II были получены два полезных результата: CSV-файл профилировщика и детерминированный отчет о модульных тестах. Это уже дает проекту больше, чем простое отсутствие сообщений на вкладке "Эксперты", но отдельный отчет по-прежнему описывает лишь один прогон. Часть III добавляет недостающий уровень принятия решений, сохраняя при этом контракты из Части II: профилировщик записывает CSV-файл в прежнем формате, средство запуска модульных тестов формирует отчет TestLite в прежнем формате, а чистые функции по-прежнему находятся во вспомогательном модуле торговых расчетов. Барьер регрессионного контроля сравнивает текущие диагностические данные с принятым эталоном и на основе этого сравнения принимает решение.

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

• После изменения индикатора участок кода, выполняющий копирование данных из буфера, становится более ресурсоемким.
• Участок кода, который раньше выполнялся при появлении новых баров, начинает выполняться на каждом тике.
• Правило определения размера лота проходит проверку на EURUSD, но не проходит ее на символе с другим шагом объема.
• После рефакторинга сигнал по ошибке считывает данные текущего формирующегося бара.

Барьер регрессионного контроля отвечает на три практических вопроса.

• Достаточно ли изменились показатели выбранных профилируемых участков, чтобы присвоить статус PASS, WARN, SKIP или FAIL?
• По-прежнему ли успешно проходят тесты чистых функций торговых расчетов из Части II?
• Остаются ли верными допущения о свойствах конкретного символа, используемые в примере советника?

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

Автор: Sahil Bagdi