Примеры: Повышаем качество кода при помощи Unit Test

 

New article Повышаем качество кода при помощи Unit Test has been published:

Даже в простых программах зачастую находятся ошибки, которые кажутся невероятными. "Как я такое написал?" - первое, что приходит в голову, когда мы обнаруживаем такую ошибку. Второй вопрос - "Как этого избежать?" - приходит гораздо реже. Нельзя написать 100%-ный безошибочный код, особенно в больших проектах, но можно использовать технологии для их своевременного обнаружения. Статья рассказывает о том, как можно повысить качество MQL4 кода, применяя распространенную методику модульного тестирования (Unit Testing).

Author: Андрей

 
Аффтар - молодец. Жаль конечно, что нельзя в МТ иметь такие же полноценные юниттесты, как в жабе или дельфи.
 

Гладко было на бумаге, да забыли про авраги )))

Идея системного подхода к тестированию функций хороша, но в отличие от приведенных примеров, в практике програмирования на MQL чаще всего имеем дело не с указанными вами типами входных параметров, а с тайм-сериями Close[х] и т.д. И пускай даже эти тайм-серии не указаны ввиде явных параметров функции, мы все равно считаем их основными входными данными, обработав которые принимаем решение о торговле.

От критики к конструктивному предложению : такого четко оформленного пока нет ))

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

Очень надеюсь, что придумаем метод тестирования. При наличии такового метода качество кода вырастет на порядки.

 
Klinch:

Гладко было на бумаге, да забыли про авраги )))

Идея системного подхода к тестированию функций хороша, но в отличие от приведенных примеров, в практике програмирования на MQL чаще всего имеем дело не с указанными вами типами входных параметров, а с тайм-сериями Close[х] и т.д. И пускай даже эти тайм-серии не указаны ввиде явных параметров функции, мы все равно считаем их основными входными данными, обработав которые принимаем решение о торговле.


С точки зрения MQL4, таймсерии - это такие же массивы как и любые другие. Поэтому можно выделить отдельные функции для работы с тайм сериями, и передавать им тайм серии в качестве параметров. Так даже будет лучше с точки зрения изолированности кода. Например, если нужна функция которая определяет было ли пробитие уровня L на последних N барах, то можно определить её как:

bool IsExcess (double h[], double L, int N);

А затем вызвать, передав функции массив High.

if (IsExсess(High, 1.5000, 10)){
   //Что-нибудь делаем
}
Тогда UnitTest для этой функции может использовать любой произвольный массив. Тестовый массив может загружаться из CSV файла если данных нужно много. Можно сделать такой файл один раз и потом использовать во всех тестах.
 
Evklid:Тогда UnitTest для этой функции может использовать любой произвольный массив. Тестовый массив может загружаться из CSV файла если данных нужно много. Можно сделать такой файл один раз и потом использовать во всех тестах.

Согласен с вашим предложением использовать тайм-серии в виде явных параметров функции.

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

В отличие от вопроса как тестировать, более важным считаю вопрос что тестировать. В статье говорилось "Остаётся открытым один вопрос: как выбрать набор тестовых параметров для тестируемой функции? Безусловно, в идеальном случае нужно использовать все возможные значения, но почти всегда это невозможно или трудоёмко. На тему выбора тестовых значений можно написать отдельную статью. Здесь же я постараюсь дать какие-то общие рекомендации: ..."

Не соглашусь с автором в том что использовать все возможные значения является идеальным вариантом )) Мои скудные знания мат. анализа подсказывают мне, что исследовать достаточно функцию в точках экстремума, но т.к. разрабатываемые нами функции в общем случае не являются линейными, то встает вопрос создания мат. аппарата схожего с применяемым для линейных функций. Из этого следует, что необходимо научиться брать производную из таких функций как "if", "while" и т.д. с целью определения точек экстремума этих функций.

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

 

Маленькое замечание по поводу отладки кода. Функции print и особенно alert, мне показалось, работают по настроению. Мне стало намного проще определять величины переменных, процесс выполнения функций (короче - отладочные данные), когда вспомнил о возможности записи в файл. Оказалось, что организовать легко читаемый отчет о работе эксперта несложно даже такому ленивому как я. Пожалуй, запись в файл - единственная надежно выполняемая функция. У меня, по крайней мере. Подробности вряд ли кому нужны, все очень просто.

 

Возможно, не в тему, точнее, не совсем в тему. Точнее, совсем не в тему.

Существует весьма благоприятный тестер (небесплатно, правда):

http://www.forextester.ru/

Он позволяет практически идентичный прокат любого материала на бывших ситуациях с любой скоростью, оч хорошая машина. Но огромный недостаток: он не работает с MQL4. Он позволяет писать стратегии, но на дельфи или си++.

Т.е. это для тестирования стратегий от руки или экспертов в целом, с выдачей полной статистической картины.

Тестер, встроенный в метатрейдер, рядом не валялся.

Пардон, но может кому интересно...

Я все хочу попросить автора тестера приделать MQL4, да боюсь, что мне тогда будет не по карману...

 
vlad_cum:

Маленькое замечание по поводу отладки кода. Функции print и особенно alert, мне показалось, работают по настроению. Мне стало намного проще определять величины переменных, процесс выполнения функций (короче - отладочные данные), когда вспомнил о возможности записи в файл. Оказалось, что организовать легко читаемый отчет о работе эксперта несложно даже такому ленивому как я. Пожалуй, запись в файл - единственная надежно выполняемая функция. У меня, по крайней мере. Подробности вряд ли кому нужны, все очень просто.


Согласен иногда функции принт и алерт не пишут в журнал нужных логов