Падает в дамп при открытии тест ранера внешнего на 8.2.18.102, 19.83

[Ndochp]

Падает на последней строке модуля объекта

ЭтоВстроеннаяОбработка = Не Метаданные.НайтиПоТипу(ТипЗнч(ЭтотОбъект)) = Неопределено;

по причине того, что ТипЗнч(ВнешниеОтчеты.Создать("F:\1CBase\xddTestRunner.epf")) у меня вызывает ошибку вида:
"Тип не определен "некий гуид"
Завершить работу/Перезапустить

[artbear]

Какие действия выполняешь?
какую версию обработки юзаешь? из какой ветки?
УФ или ОФ? тонкий или толстый клиент?
подробнее дай информацию.

[artbear]

Странная ошибка, боюсь, опять что-то из-за особенностей платформы 1С.
Я дома нарвался на эту же ошибку на 8.2.19.68 при открытии на ОФ на файловой базе
несколько раз запускал, был баг.
Затем открыл через отладчик, посмотрел эту строчку и баг перестал повторяться :(
в отладчике, без отладчика баг уже не повторяется.
попытался смоделировать баг -

• создавал новую пустую файловую базу, запускал раннер,
• загружал старую тестовую базу, запускал раннер
• загружал в эту базу новую конфигурации, запускал раннер
• еще несколько странных шаманских тестов,
  ошибка больше ни разу не повторилась :(

[Ndochp]

Действие - файл-открыть тест ранер.
Режим - толстый ОФ
Ветка девелоп.
Работает действительно не стабильно. Гонял туда обратно вариант исправления, падать перестало само.
Похоже глюк платформы в объекте "ВнешниеОтчеты". Гонял в консоли следующий код:

цй = ВнешниеОтчеты.Создать("F:\1CBase\xddTestRunner.epf");
йц = ТипЗнч(цй);
//йц = ТипЗнч(ВнешниеОтчеты.Создать("F:\1CBase\xddTestRunner.epf"));

В таком режиме отрабатывает, а если раскомментировать третью строку и закрыть первые две- падает стабильно. То-ли времени иногда не хватает на регистрацию, толи еще что.

В итоге переписал у себя функцию в модуле объекта тест ранера "ЭтоВнешняяОбработка" на работу с "ИспользуемоеИмяФайла". Может включить ее в таком виде, раз не только у меня порой воспроизводится?

Функция ЭтоВнешняяОбработка(ПарамОбъект = Неопределено) Экспорт
    Перем НужныйОбъект;
    НужныйОбъект = ПарамОбъект;
    Если НужныйОбъект = Неопределено Тогда
        НужныйОбъект = ЭтотОбъект;
    КонецЕсли;

    #Если ТолстыйКлиентОбычноеПриложение или ТолстыйКлиентУправляемоеПриложение или Сервер Тогда
        СисИнфо = Новый СистемнаяИнформация;
        Если СисИнфо.ВерсияПриложения < "8.2.19.83" Тогда
            Рез = ЗначениеЗаполнено(НужныйОбъект.ИспользуемоеИмяФайла);
        Иначе
            Рез = Метаданные.НайтиПоТипу(ТипЗнч(НужныйОбъект)) = Неопределено;
        КонецЕсли;
    #Иначе
        Рез = Метаданные.НайтиПоТипу(ТипЗнч(НужныйОбъект)) = Неопределено;
    #КонецЕсли

    Возврат Рез; 
КонецФункции

[artbear]

Давно хотел спросить, почему ВнешниеОтчеты, когда у нас внешняя обработка и в коде юзается ВнешниеОбработки ?

[artbear]

В общем, пока не понятно :(

[artbear]

Жду ответа.

[Ndochp]

Это была копипаста из запуска Мобильных инструментов разработчика, не заметил. Да собственно платформе без разницы, она съедает ТестРанера как отчет вроде.
Ну и цй = ТипЗнч(ВнешниеОбработки.Создать("F:\1CBase\xddTestRunner.epf")); кладет базу.
Но, эта фраза у меня успешно кладет базу и на 19.83, так что может проблема и не в этом.

С другой стороны, если исходная ошибка прояляется (хоть и не стабильно) только в толстом клиенте обычных формах, то может для этого случая переписать определение "внешности" через ИспользуемоеИмяФайла в попытке исключении? (падает в исключение - значит встроенная).

[artbear]

Ошибка сегодня дома еще несколько раз повторилась на 8.2.19.68 :(
Лечилась просто - я перед проверкой Метаданные.НайтиПоТипу(ТипЗнч(НужныйОбъект)) = Неопределено вставлял пустую строку, перезаписывал файл и перезапускал 1С.
очень странно.

[ValeraS]

У меня раннер в режиме обычных форм стал валить предприятие при запуске, во время загрузки тестов из-за информатора. Падает в дамп на строке 214 модуля объекта xddInformator: ScrptCtrl.AddCode(ТекстМодуля);

[artbear]

@ValeraS платформа 1С какая? платформы винды? клиент-сервер, 32/64?

[ValeraS]

8.2.19.121 файловая Windows 7 64
на этой же конфигурации раньше не падало.

[artbear]

Странно, буду проверять.

[Ndochp]

Аналогичный случай (с падением на ScrptCtrl.AddCode(ТекстМодуля); ) у меня объяснился тем, что тест не проходил синтакс контроль. В итоге, от загрузок тестов из папки пришлось перейти на загрузку теста из файла, так как иначе тест ранер конфликтует с автосохранением внешних обработок из снегопата.

[artbear]

@Ndochp поясни конкретнее, при чем здесь синтакс-контроль. что-то я совсем не понял связи с Информатором.

[Ndochp]

текс.... Пояснить не могу специально не воспроизвелось, в следующий раз как столкнусь, создам ишшку с примером воспроизведения.
Но у меня было несколько раз, что при наличии теста с синтакс ошибкой, при загрузке тестов система падала, вместо того, чтобы просто ругнуться Ошибка: {ВнешняяОбработка.xddTestRunner.МодульОбъекта(2929)}: Ошибка при вызове метода контекста (Создать)
И как раз на той строчке в информаторе.

[artbear]

У меня подобных сообщений очень давно не было.
Да и народ, кто юзает раннер, не обращался с подобными ошибками очень давно.
Предлагаю закрыть задачу до следующего проявления и я наконец-то выпущу релиз :)

@Ndochp @ValeraS Жду ответа от обоих

[Ndochp]

Согласен. Сейчас еще попинал со всех сторон, не воспроизвелось.

[ValeraS]

Воспроизводится. При открытии раннера во время получения тестовых случаев из обработки. Не могу понять причину, может раз запуститься, а потом постоянно падает. Чаще падает чем, запускается.

На другой машине с XP не воспроизводится.

[artbear]

@ValeraS У тебя вылет именно по Информатору?

[ValeraS]

@artbear да

[artbear]

@Zaidfly насколько для тебя критично использование Информатора?
т.е. у тебя все скрипты используют Информатор?

[Zaidfly]

@artbear, да, все тесты используют информатор в обоих проектах.

Совсем не хочется отказываться от информатора. Сейчас люди пишут тесты и сразу прогоняют их. Когда их всреднем по 30-40 штук в одном тестовом наборе (в одной обработке), то очень велика вероятность того, что тесты будут писать, а регистрировать их вручную в процедуре ПолучитьСписокТестов() будут забывать. Написал тест, запустил - прогнал. Все зеленое, а на самом деле свой новенький тест и не прогнал.

[artbear]

Нужно какое-то решение - возможность простого и удобного отключения/включения Информатора.
Т.е. по умолчанию он включен для ОФ, как и сейчас, но его можно отключить при желании.
В тестах несложно сделать через спец.параметр командной строки, а вот с интерактивом сложнее.
Не могу придумать для интерактива удобный вариант.
Народ, что предложите?

[ValeraS]

Сейчас, на win7x64, 1cv8.2.19.121 файловый , падает с завидной постоянностью ))

[artbear]

А можешь новую версию Информатора проверить?
http://www.1cpp.ru/forumfiles/Attachments/DWX____________83_epf.7z
Если не сможешь скачать, выложу отдельно.
Будет ли падать также часто?
зы у меня сейчас на домашней машине перестало падать. вчера ночью несколько раз падало. повторяемости нету.

[ValeraS]

Ещё быстрее падает ))

[artbear]

Ага, я протупил. Оказывается. вчера ночью выключил использование Информатора и падать перестало :)
Сейчас поразбираюсь

[ValeraS]

По поводу быстродействия: мне кажется странным решение передавать объект раннера через метод ПолучитьСписокТестов, логичнее было его передавать в тестовый метод напрямую. Тогда бы получение тестовых методов происходило только один раз для каждой обработки.

[artbear]

Поясни, не понял.

[ValeraS]

Сейчас, метод ПолучитьСписокТестов вызывается перед каждым выполнением тестового случая, потому что туда передается объект раннера, который сохраняется в переменной модуля тестовой обработки, и потом используется в тестовом методе. (ТестОбъект.ПолучитьСписокТестов(ЭтотОбъект))

А правильным кажется такой вариант Выполнить("Тест." + ИмяТестовогоСлучая + "(ЭтотОбъект, " + строкаПараметров + ");")

[ValeraS]

В общем, кажется логичным, во все методы тестовой обработки, вызываемые из раннера, передавать объект раннера.

[artbear]

Нет, это нелогично. Зачем в каждый метод передавать этот метод, когда это можно сделать один раз при инициализации?
Сейчас вызов ПолучитьСписокТестов перед выполнением теста нужен для того, чтобы развязать тесты и сделать их независимыми. Для каждого теста создается отдельный экземпляр объекта-обработки. После создания его нужно инициализировать, для этого и вызывается ПолучитьСписокТестов.
У нас есть задача #253 по отключению независимости тестов.

[artbear]

Ну и плюс красота тест.метода пропадет, если ему будет передаваться спец.параметр.
Юзабельность сильно понизится.

[Ndochp]

Вот в чем нарушение красоты и гармонии. Функция "ПолучитьСписокТестов"
занимается еще и инициализацией тестовой обработки. Может их развести?

[artbear]

Так сделано для упрощения интерфейса тестов и повышения юзабельности.
Инициализация в ПолучитьСписокТестов - это неявная фича :)
я не так давно сделал спец.задачу #395 Методы "ПередЗапускомТестовогоНабора"/"ПослеЗапускаТестовогоНабора" - для запуска перед/после первого/последнего тестов из тестового набора для реального разделения

[ValeraS]

Чем это не логично? С точки зрения ООП, по сути, тестовая обработка это потомок раннера. А дальше можно посмотреть на объекты в python, в каждый метод объекта первым параметром передается экземпляр класса (self). Просто у нас это будет не self а super(родительская часть объекта).

[artbear]

В этом вопросе за неявную передачу self/this, как, например, в С++/C#/Java.
С этим синтаксическим сахаром код смотрится намного проще.

[pumbaEO]

Согласен с @artbear , вот чего бы не хотелось - это нести с из питона self :( .

[ValeraS]

А в результате, инициализация через ПолучитьСписокТестов, и медленная работа без информатора.
Хорошо, когда будет сделана задача #395, больше не будет постоянно вызываться ПолучитьСписокТестов?

[ValeraS]

А зачем каждый раз при выполнении тестов проверять существование метода ПолучитьСписокТестов? Его существование было проверено при загрузке.

[pumbaEO]

Мы только в ПолучитьСписокТестов можем получить юТест, т.е. или кажый раз передавть объект в процедуру теста self или же каждый раз вызывать ПолучитьСписокТестов, ну или требование в обработке объявлять экспортную переменную и туда явно писать Обработка.юТест = ЭтаФорма.

[artbear]

когда будет сделана задача #395, больше не будет постоянно вызываться ПолучитьСписокТестов?

Метод ПолучитьСписокТестов будет вызываться каждый раз при создании тест-объекта.
Когда будет решена #253, тогда создание будет происходить реже и вызов этого метода автоматически также будет вызываться реже.

А зачем каждый раз при выполнении тестов проверять существование метода ПолучитьСписокТестов? Его существование было проверено при загрузке.

Оптимизация работы разработчика и повышения юзабельности.
Разработчик может загрузить тесты один раз, а потом просто менять код обработки, изменять набор тестов, менять код тестов и т.п. Хотелось, чтобы все его изменения подхватывались на лету, без необходимости использования кнопки "Перезагрузить".
Ну и опять помни про создание тест-объектов и #253

[ValeraS]

Использование информатора для быстродействия в случае определения наличия метода ПолучитьСписокТестов какое-то странное. Если у нас куча тестовых обработок, то их имеет смысл хранить отдельно (в папке, в подсистеме) , соответственно у них этот метод будет присутствовать и проверка не нужна. Для большого набора, это ещё быстрее работать будет)).

Тесты из модуля объекта в управляемом режиме, сейчас, не подхватывают изменения. Клиентские тесты переподключаются каждый раз.

[artbear]

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

[artbear]

Плюс из-за особенностей 1С я лично люблю хранить и тесты, и боевой код в одной обработке, т.к. я работаю по ТДД.
Т.е. у меня часто в одной папке и обычные обработки, и обработки и с кодом и с тестами.

[artbear]

@pumbaEO Не нужно эту задачу закрывать, я ее специально переоткрыл вчера для дальнейшего обсуждения.
Договоримся и тогда закрою.
Лады?

[artbear]

Еще вариант решения:
для определенных платформ (например, 8.2.19, 8.2.18) для новых ИБ/новых пользователей в интерактивном режиме при запуске раннера в ОФ задавать вопрос о подключении Информатора.

Если пользователь разрешает, то Информатор включается. Если ответ "Нет", то Информатор выключается.

Один минус - вопрос придется задавать в ПередНачаломРаботыСистемы.

Лично мне сейчас этот вариант импонирует больше всего, т.к. на 8.2.17 и 8.3 проблем пока не замечено :(

[artbear]

Работы по Информатору уже выполнены.
В случае интерактивного режима вопросы после падения 1С задаются.
Закрываю.