Closed artbear closed 7 years ago
@nixel2007 @EvilBeaver @dmpas Проблема в запуске через opm test
В этом случае сначала opm грузит системные библиотеки, в т.ч. и 1commands, и только потом загружается библиотека из рабочего каталога.
Часть лога package-loader.os
,
C:\OneScript\lib
- системный каталог пакетов, C:\projects\1commands
- это рабочей каталог разработки
ПриЗагрузкеБиблиотеки C:\OneScript\lib\1commands
класс Команда, файл C:\OneScript\lib\1commands\src\Команда.os
класс КомандныйФайл, файл C:\OneScript\lib\1commands\src\КомандныйФайл.os
ПриЗагрузкеБиблиотеки C:\OneScript\lib\tempfiles модуль ВременныеФайлы, файл C:\OneScript\lib\tempfiles\ВременныеФайлы.os класс МенеджерВременныхФайлов, файл C:\OneScript\lib\tempfiles\ВременныеФайлы.os ПриЗагрузкеБиблиотеки C:\OneScript\lib\fs ОбработатьСтруктуруКаталоговПоСоглашению модуль ФС, файл C:\OneScript\lib\fs\Модули\ФС.os
ПриЗагрузкеБиблиотеки C:\projects\1commands класс Команда, файл C:\projects\1commands\src\Команда.os класс КомандныйФайл, файл C:\projects\1commands\src\КомандныйФайл.os
ПриЗагрузкеБиблиотеки C:\OneScript\lib\1bdd
2 последних библиотеки загружаются, т.к. в test.os прописано
```bsl
#Использовать ".."
#Использовать 1bdd
а так классы уже ранее загружены, повторная загрузка библиотеки ничего не делает, что и приводит к багу.
Если же прогонять тесты без участия opm, напрямую через oscript tasks/test.os
,
то все в порядке и загрузка библиотек идет в обратном, правильном порядке,
как и прописано в файле test.os
лог следующий
ПриЗагрузкеБиблиотеки C:\projects\1commands
класс Команда, файл C:\projects\1commands\src\Команда.os
класс КомандныйФайл, файл C:\projects\1commands\src\КомандныйФайл.os
ПриЗагрузкеБиблиотеки C:\OneScript\lib\logos
ПриЗагрузкеБиблиотеки C:\OneScript\lib\asserts
ПриЗагрузкеБиблиотеки C:\OneScript\lib\tempfiles
ПриЗагрузкеБиблиотеки C:\OneScript\lib\1bdd
ПриЗагрузкеБиблиотеки C:\OneScript\lib\strings
ПриЗагрузкеБиблиотеки C:\OneScript\lib\1commands
класс Команда, файл C:\OneScript\lib\1commands\src\Команда.os
класс КомандныйФайл, файл C:\OneScript\lib\1commands\src\КомандныйФайл.os
В итоге, получается, для разработки системных библиотек нельзя юзать opm test
либо нужно предпринимать какие-то меры для защиты от подобного поведения :(
Эту проблему обсуждали и решали еще год назад. Надо тестировать что-то, что используется как зависимость в фреймворке тестирования - подключай свой файл через ЗагрузитьСценарий
ЗагрузитьСценарий использует те же библиотеки, т.к. он находится в одном сеансе oscript. и это не решает проблему. opm test как раз так и работает, насколько я понимаю.
ЗагрузитьСценарий вообще не использует библиотек. Он создает новый экземпляр класса/модуля по указанному пути, ему наплевать, что там в снаружи происходит.
тестируешь классы 1коммандс - загружаешь 1коммандс.
@nixel2007 Ты уверен в 'ЗагрузитьСценарий вообще не использует библиотек'? У нас же одно пространство имен.
@EvilBeaver @dmpas А вы что скажете?
@nixel2007 Ты какой вариант предлагаешь для 1коммандс? я что-то не понял.
Кстати, в типовом Jenkinsfile для билд.оскрипт.ио Андрей удачно использует именно oscript tasks/test.os
и пакеты прогоняются без ошибок, в т.ч. и 1тестраннер, например.
@artbear я имею ввиду, что если у тебя уже загружен через Использовать класс КомандныйФайл, то через загрузить сценарий ты подключишь конкретную версию с диска, а не с каталога либ. Библиотеки, импортируемые внутри КомандныйФайл, понятное дело, полезут из каталога либ, но тебе и не надо их тестировать - они просто должным быть прописаны в зависимостях с нужными версиями
В целом результат - для правильного тестирования библиотек, которые есть и в разработке, и в каталоге lib движка на машине, нужно
oscript tasks/test.os
, а не opm test
Использовать ".."
".."
нужно писать правильный путь к исходникам классов/модулейИспользовать 1bdd
и/или Использовать 1testrunner
И дополнительно (но необязательно):
без подобной доработки тесты, скорее всего, будут падать и нельзя будет гарантировать правильность разработки
обсудили эту с @nixel2007 других вариантов не нашли
И кстати, после недавнего PR по PowerShell тесты AppVeyor стали падать.
А после исправления согласно комментариям выше эти тесты опять стали зелеными.
Я вчера также добавил типовой Jenkinsfile для CI на build.oscript.io