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 :) )

[nixel2007]

Если у @EvilBeaver и @pumbaEO возражений нет, то назначайте на меня. Плюс сделаю пример для 1bdd. Для тестраннера нужна будет помощь, не работал с ним никогда.

[artbear]

Для тестраннера нужна будет помощь, не работал с ним никогда.

@nixel2007 Спрашивай. Помогу.

[EvilBeaver]

@nixel2007, ЯННП, но если сделаешь, то так и будет ))

[nixel2007]

Реализовано в #10

[artbear]

Запускаю 'opm test', получаю ошибки

$ opm help test
test - Выполнить тестирование проекта
Параметры:
 <ПараметрыЗадачи> - Коллекция параметров, передаваемых задаче тестирования

$ opm test
Не задано имя пакета

$ opm test opm
Не задано имя пакета

Что не так?

ЗЫ пишу в закрытом ишузе, вдруг я туплю и все просто :)

[nixel2007]

Скинь содержимое packagedef в текущем каталоге.

[artbear]

я понял свою проблему: я тестировал в неверном каталоге, а opm мне сообщал странную инфу об ошибке. Зачем мне описание ошибки "Не задано имя пакета", если намного понятнее "Не задан файл описания библиотеки packadef" @nixel2007 Сможешь дополнить?

[nixel2007]

я не уверен, что файл описания пакета вообще обязателен в данном случае, т.к. у нас есть значение каталога задач по умолчанию - tasks от CWD. Надо вот именно этот момент поправить, тогда тебе будет выдаваться сообщение, что не обнаружен файл tasks/test.os. так лучше будет?

[artbear]

Да, ИМХО устроит

[artbear]

но для opm run файл описания пакета нужен. А для одинакового поведения лучше, чтобы в обоих случаях (run & test) файл описания требовался.

[nixel2007]

но для opm run файл описания пакета нужен.

почему ты так считаешь? там та же схема - получить каталог с тасками, постараться найти таску с таким именем.

[artbear]

До твоего вопроса я считал, что данные о задачах мы берем из файла описаний, но теперь понимаю, что достаточно взять имя таска из opm run ИмяТаска и проверить наличие файла tasks\ИмяТаска.os

Так что вопрос снят

[artbear]

Хотя еще нужно документировать поведение - из opm help run или opm help test этого не видно :(