Тест, проверяющий правильность формирования стаканов котировок.
Чего только со стаканом не бывает, если это не тестировать. Покупки выше продаж, уровни с нулевыми объёмами, неправильная сортировка и много ещё чего. Данный тест вот такие вещи смотрит.
Есть в OsEngine функционал, который по одной кнопке останавливает торги по определённой бумаге и закрывает позицию. Штука появилась недавно, не уверен, что ей кто-то пользуется кроме нашего управляющего, однако функционал важен и нужен.
Выглядит это так:
Тест, проверяющий бумаги на площадке. Во время подключения к любой бирже, одно из первых, что происходит – запрос бумаг, торгующихся на ней. Этот класс называется Security.
Так вот, у этого класса есть очень много различных полей. Как обязательных, так и нет. Данный тест направлен на валидацию этих данных.
Подробнее посмотрим на ServerMaster в текущей статье. На его состав и структуру. А самое главное посмотрим на то, где создаются и где хранятся объекты серверов.
Февраль неумолимо приближается. Инструкции по тому, как делать коннекторы скоро будут дописаны.
При этом нам необходимо знать, кто из сообщества какой коннектор делает, чтобы не возникало путаницы, и чтобы у нас одно подключение двое не собирали.
В общем. Пора перегруппироваться.
Напоминаю, что первый коннектор в любом случае — крипта. Да, я знаю, что бюджеты на проф-коннекторы к MOEX есть и Вам хочется начать с них. НО! Это будет противоестественно с точки зрения увеличения сложности задачи.
Подробная статья на тему: https://smart-lab.ru/company/os_engine/blog/964640.php
Если вдруг, Вам не из чего выбирать и своих предпочтений нет, то не беда. Есть замечательный сервис по просмотру объёмов на биржах, который называется CoinMarketCup. Идём по ссылке.
Выбираем любую из ТОП 50.
Вчера мы с Вами начали знакомиться со слоем для тестирования коннекторов в OsEngine. А сегодня будем смотреть, как они реализованы технически.
К слову сказать, созданы тесты на базе обычного робота для OsEngine. А это статья — обзор этого робота.
Каждый торговый сервер в OsEngine имеет внутри себя объект CandleManager, который следит за тем, чтобы серии свечек собирали свечи и отправляли их вверх. Их нужно активировать. За это одновременно отвечает класс IServerPermission и CandleManager, о которых будем сегодня говорить.
Находится Candle Manager вот здесь:
В нескольких предыдущих постах серии мы разговаривали про IServer, свойства и методы, которые в нём есть. Их много и довольно разных. При этом каждое отдельно взятое API что-то поддерживает, а что-то нет. О том, что конкретно коннектор поддерживает, OsEngine должен знать ДО того, как начнёт запрашивать неработающий функционал. Для этого ServerPermission и существует.
Например, данные могут быть только свечные, или может не быть 15 минутных свечек. Или API может вообще не поддерживать скачку глубоких исторических данных. Или API не поддерживает какие-то торговые операции: нет Market ордеров, не работает перестановка цены ордера.
Cлой автотестов для коннекторов переживает в OsEngine уже ВТОРОЕ пришествие. Увеличившись с первой версии в 10 раз. Про что и будет данная мини-серия статей внутри серии «Коннекторы к OsEngine». АЖ НА 20 Постов. Так надо…
А данный пост о том, зачем такой большой слой тестирования и введение в тему.
Так вышло, что ядро OsEngine тестируется почти без остановки с разных сторон одновременно. И тестером, и оптимизатором и роботами в реальных боях. В какой-то момент дошло до того, что команда в офисе узнаёт о багах, если таковые есть, после их пуша в ядро через 10 – 20 минут.
Выглядит это так:
Рис. 1. Модули, тестирующие слои, поддерживающие работу роботов.
Поэтому само ядро OsEngine стабильно.
Проблемы в другом месте… В коннекторах. Чем мы с Вами и будем весь 2024 год заниматься.
Это самая важная часть создания коннекторов. «Наговнить немного кода, чтобы как-то что-то заработало» — дело нехитрое. Однако при таком подходе пользователи будут не довольны, т.к. коннектор будет работать плохо. Поэтому надо делать хорошо, чтобы коннектор начал проходить автоматические тесты. И для этого придётся попотеть.
Сегодня рассмотрим интерфейс с названием IServer, через который осуществляется доступ к коннекторам в OsEngine. Посмотрим, что у него там есть внутри.
IServer – интерфейс для доступа к реализациям серверов почти во всём проекте. Нужен для того, чтобы унифицировать методы и свойства, нужные для роботов и OsData.