Open Sebekerga opened 11 months ago
Попробовал OneScript. К сожалению, поведение 1С 8.3.19.1467 значительно отличается от ванскрипта. Это возможно обойти, изменив генерацию метода GetClassObject
, однако работа out парамтетров всё же таким образом не получится тестировать. Думаю, что будет норм начать работу с OneScript как есть - код всё равно не будет отличаться от реализации тестирования
А если сделать обвязку на Rust? Мы знаем по докам its какие типы и что ждёт 1С на выходе, знаем порядок вызова функций Допустим чтобы проверить строки просто конвертим из utf-8 в utf-16 и делаем assert_eq и т.п. Только вместо макросов assert_eq используется другой макрос для работы с типами 1С
Конечно в реализации сложнее чем 1С или OneScript, но зато можно просто бросить в [dev-dependencies] крейт и писать интеграционные тесты используя крейт
С точки зрения времени и усилий, не проще ли либо подождать фикса в OneScript, либо на крайний форкнуть их проект и доделать под наши задачи?
С одной точки зрения да, вы правы. Но с другой, 1С и OneScript не знают о методах и свойствах компоненты, что даёт первый минус. Второй минус - пересборка проекта в случае если что-то меняется Я делал компоненту на 10 методов и 6 свойств. Потом она несколько раз менялась. Тестил корректность получаемых данных через пустую конфу 1С. После того как что-то менялось (а менялось много) много времени уходило на дописывание кода 1С Поэтому я выдвинул свое предложение о написании обёртки на Rust т.к. достаточно будет запустить cargo test и он всё проверит. Можно начать использовать OneScript для теста и параллельно запустить разработку обёртки на Rust, как вариант
Просто для уточнения: я имею в виду интеграционное тестирование библиотеки как таковой, а не инструмент для тестирование любого решения, написанного с помощью этой библиотеки.
@Toveal Вы сможете накидать пример, как это будет выглядеть, будь оно написано на Rust? Просто я пока не особо представляю, как это будет выглядеть
Тесты в макросе, которые просто собирают проект, хорошо проверяют работу непосредственно макроса, но этого недостаточно для проверки корректной работы готовой копмоненты. Это уже понятно, из-за того, сколько вышло ошибок со строками. Есть, как я вижу, два варианта: 1) Тестировать с помощью OneScript, который поддерживает Native API; 2) Сооружать какое-то тестирование с помощью непосредственно 1С.
Мне кажется, пока что лучше 1), т.к. кроме очевидной простоты реализации в сравнении со 2м вариантом, так же проще с точки лицензирования. Потому что тестировать под "коммунити" лицензией будет больно.