opm test

[nixel2007]

Допустим, в файле манифеста моего приложения/библиотеки есть секция:
Описание.ТестируетсяСПомощью("testrunner")
Или
Описание.ТестируетсяСПомощью("1bdd")

Когда Я выполняю команду opm test
Тогда opm автоматически прогоняет все тесты с помощью указанного фреймворка

Когда Я выполняю команду opm build
Тогда opm автоматически прогоняет все тесты с помощью указанного фреймворка
И Пакет собирается только если все тесты прошли

[pumbaEO]

1. Но зачем? В теории у каждого проекта свой запускатель тестов, то что сейчас запускаем прям для всех разом из oscript-library имхо пережиток прошлого.
2. Тесты в теории вообще не должны попадать в продуктив, а тут мы в манифесте описываем про какие-то тесты.
3. Вот в pytets от python есть замечательная фича, если надо рекурсивно пройтись по подпроектам с тестами, то он смотрит на test_run.py и если находит его, то выполняет как тест, а там уже unittest или еще что другое запускается, без разницы.

[nixel2007]

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

1. Согласен. В том же node.js ты просто описываешь команду, которую надо выполнить. Я говорю именно про отдельные тесты для каждого пакета. Интеграционные не рассматриваю.
2. Тесты не обязательно включать в конечный архив-результат сборки. За это отвечает отдельная функция в манифесте, где ты явно описываешь, какие файлы должны быть включены в пакет.
3. Идея хорошая. Но у нас пока два реальных запускатора тестов. Надо посмотреть, от чего будет больше пользы в плане трудозатраты/результат

[nixel2007]

Эта проблема не стояла бы так остро, если процесс публикации новой версии пакета осуществлялся на стороне клиента: прогнали тесты, подготовили релиз, сделали opm publish. Но пока у нас нет инфраструктуры на это, авторизации, хттпсов всяких и прочее

[dmpas]

чем Описание.ТестируетсяСПомощью("testrunner") отличается от #Использовать testrunner?

есть каталог tests, в нём лежит файлик с волшебным названием run-all.os (anything-other.os). В файлике прописано #Использовать testrunner или #Использовать 1bdd. opm test просто запускает сей файлик.

[nixel2007]

@dmpas я не говорю, что это лучше :) это просто первое, что мне пришло в голову. Вариант с run-all.os мне очень нравится, он расширяем, удобен и не обязывает разработчика вообще использовать какой-либо фреймворк - хоть ассертов накидай, вот тебе и тест.

[EvilBeaver]

Парни, но опм это же менеджер пакетов. Всего лишь. Команда опм тест как-то мне кажется не в кассу

[dmpas]

@EvilBeaver раз уж повелось, что он им не только менеджер, но и сборщик, то касс у него теперь две, как ни крути.

[nixel2007]

@EvilBeaver ты меня когда-нибудь пошлешь с моими аналогиями, но я опять смотрю на ноду и подобные менеджеры)

[nixel2007]

Только npm еще и таск-раннер...) но этого я пока не прошу)

[EvilBeaver]

Да я ж не против. Меня только смущает, что опм должен понимать инфраструктуру тестирования в разных фреймворках. Как это в ноде делается?

[nixel2007]

@EvilBeaver сам npm ничего не знает об инфраструктуре фреймворка. У тебя есть дев-зависимость, которая ставится по аналогии с opm install. В файле манифеста объявлена коллекция scripts {}, в которой ты в явном виде прописываешь свой запускатор тестов, типа такого:
https://github.com/xDrivenDevelopment/vsc-language-1c-bsl/blob/759632b3e4fa418ea32dca40a595d70d07796276/package.json#L29

Когда выполняется команда npm run test или npm t, то выполняется данный скрипт.

@dmpas предлагает чуть другое - положить в каталог test, например, файл index.os. А уже в этом файле сам разработчик библиотеки реализует тесты так, как он хочет. Вот например подключение mocha как фреймворка (но его вызов идёт не здесь, это лишь пример) https://github.com/xDrivenDevelopment/vsc-language-1c-bsl/blob/759632b3e4fa418ea32dca40a595d70d07796276/test/index.ts

[nixel2007]

При этом mocha объявлена в dev-dependencies

[nixel2007]

Добавлю, что Java, а точнее Maven не позволяет собрать пакет (mvn package), если не прошли тесты

[nixel2007]

Соответственно опм мог бы просто вызывать Тестер = ЗагрузитьСценарий(test/index.os); Тестер.Запустить()

А все заботы по правильному вызову 1бдд здравствуйте или тест раннера уже лежат на авторе прикладной библиотеки

[artbear]

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

Добавлю, что к opm нужно будет приложить файлы примеров запуска 1testrunner и 1bdd для упрощения внедрения такой схемы работы. Или генерацию такого файла на лету ( в рамках 1syntax :) )