native_api_1c
native_api_1c copied to clipboard
Sebekerga
Tracking. Integration testing
Тесты в макросе, которые просто собирают проект, хорошо проверяют работу непосредственно макроса, но этого недостаточно для проверки корректной работы готовой копмоненты. Это уже понятно, из-за того, сколько вышло ошибок со строками. Есть, как я вижу, два варианта:
- Тестировать с помощью OneScript, который поддерживает Native API;
- Сооружать какое-то тестирование с помощью непосредственно 1С.
Мне кажется, пока что лучше 1), т.к. кроме очевидной простоты реализации в сравнении со 2м вариантом, так же проще с точки лицензирования. Потому что тестировать под "коммунити" лицензией будет больно.
Попробовал 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? Просто я пока не особо представляю, как это будет выглядеть