Sebekerga / native_api_1c

Crate for simple implementation of Component for Native API 1C:Enterprise written in rust
https://crates.io/crates/native_api_1c
62 stars 13 forks source link

Tracking. Integration testing #9

Open Sebekerga opened 11 months ago

Sebekerga commented 11 months ago

Тесты в макросе, которые просто собирают проект, хорошо проверяют работу непосредственно макроса, но этого недостаточно для проверки корректной работы готовой копмоненты. Это уже понятно, из-за того, сколько вышло ошибок со строками. Есть, как я вижу, два варианта: 1) Тестировать с помощью OneScript, который поддерживает Native API; 2) Сооружать какое-то тестирование с помощью непосредственно 1С.

Мне кажется, пока что лучше 1), т.к. кроме очевидной простоты реализации в сравнении со 2м вариантом, так же проще с точки лицензирования. Потому что тестировать под "коммунити" лицензией будет больно.

Sebekerga commented 11 months ago

Попробовал OneScript. К сожалению, поведение 1С 8.3.19.1467 значительно отличается от ванскрипта. Это возможно обойти, изменив генерацию метода GetClassObject, однако работа out парамтетров всё же таким образом не получится тестировать. Думаю, что будет норм начать работу с OneScript как есть - код всё равно не будет отличаться от реализации тестирования

Toveal commented 11 months ago

А если сделать обвязку на Rust? Мы знаем по докам its какие типы и что ждёт 1С на выходе, знаем порядок вызова функций Допустим чтобы проверить строки просто конвертим из utf-8 в utf-16 и делаем assert_eq и т.п. Только вместо макросов assert_eq используется другой макрос для работы с типами 1С

Конечно в реализации сложнее чем 1С или OneScript, но зато можно просто бросить в [dev-dependencies] крейт и писать интеграционные тесты используя крейт

Sebekerga commented 11 months ago

С точки зрения времени и усилий, не проще ли либо подождать фикса в OneScript, либо на крайний форкнуть их проект и доделать под наши задачи?

Toveal commented 11 months ago

С одной точки зрения да, вы правы. Но с другой, 1С и OneScript не знают о методах и свойствах компоненты, что даёт первый минус. Второй минус - пересборка проекта в случае если что-то меняется Я делал компоненту на 10 методов и 6 свойств. Потом она несколько раз менялась. Тестил корректность получаемых данных через пустую конфу 1С. После того как что-то менялось (а менялось много) много времени уходило на дописывание кода 1С Поэтому я выдвинул свое предложение о написании обёртки на Rust т.к. достаточно будет запустить cargo test и он всё проверит. Можно начать использовать OneScript для теста и параллельно запустить разработку обёртки на Rust, как вариант

Sebekerga commented 11 months ago

Просто для уточнения: я имею в виду интеграционное тестирование библиотеки как таковой, а не инструмент для тестирование любого решения, написанного с помощью этой библиотеки.

@Toveal Вы сможете накидать пример, как это будет выглядеть, будь оно написано на Rust? Просто я пока не особо представляю, как это будет выглядеть