xUnitFor1C
xUnitFor1C copied to clipboard
xDrivenDevelopment
При загрузке тестов/получении списка тестов тестам недоступен контекст тестового фреймворка
При загрузке тестов/получении списка тестов тестам недоступен контекст тестового фреймворка
Т.е. при вызове ПолучитьСписокТестов при загрузке теста нет возможности обратиться к методам юТест и к методам плагинов.
А это бывает крайне полезно.
Например, в некоторых моих тестах используется этот функционал, т.к. в 3.Х ПолучитьСписокТестов(КонтекстЯдра) выполнял роль инициализации.
Уверен, что и у других пользователей есть подобные примеры.
Поэтому предлагаю добавить этот функционал и в 4.0
Вижу варианты:
1 При загрузке тестов всегда вызывать Инициализация(КонтекстЯдраПараметр)
2 Все-таки подумать о совместимости со старыми тестами и использовать ПолучитьСписокТестов(КонтекстЯдра) как и в 3.0, а Инициализация(КонтекстЯдраПараметр) сделать необязательным при наличии ПолучитьСписокТестов(КонтекстЯдра)
ИМХО в этом случае никаких старых тестов переделывать не нужно и 4.0 взлетит сразу :)
А в документации укажем только новый вариант Инициализация(КонтекстЯдраПараметр) и ПолучитьСписокТестов()
@wizi4d что скажешь?
Я не совсем понял. Зачем при получении списка тестов контекст ядра? Расшифруй пожалуйста свое "удобно", желательно в конкретных кейсах.
20:25, Пн, 16.11.2015, Artur Ayukhanov [email protected]:
Assigned #557 https://github.com/xDrivenDevelopment/xUnitFor1C/issues/557 to @wizi4d https://github.com/wizi4d.
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/557#event-465682623 .
Совместимость в любом случае не взлетит, потому что ассерты и генерация данных - плагины и требуют изменения кода тестов.
9:49, Вт, 17.11.2015, Evgeniy Pavlyuk [email protected]:
Я не совсем понял. Зачем при получении списка тестов контекст ядра? Расшифруй пожалуйста свое "удобно", желательно в конкретных кейсах.
20:25, Пн, 16.11.2015, Artur Ayukhanov [email protected]:
Assigned #557 https://github.com/xDrivenDevelopment/xUnitFor1C/issues/557 to @wizi4d https://github.com/wizi4d.
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/557#event-465682623 .
+1 к карме за обратную совместимость.
16 ноября 2015 г., 20:16 пользователь Artur Ayukhanov < [email protected]> написал:
При создании тестов тестам недоступен контекст тестового фреймворка Т.е. при вызове ПолучитьСписокТестов при загрузке теста нет возможности обратиться к методам юТест и к методам плагинов.
А это бывает крайне полезно. В некоторых моих тестах используется этот функционал, т.к. в 3.Х ПолучитьСписокТестов(КонтекстЯдра) выполнял роль инициализации.
Поэтому предлагаю добавить этот функционал и в 4.0
Вижу варианты: 1 При загрузке тестов всегда вызывать Инициализация(КонтекстЯдраПараметр)
2 Все-таки подумать о совместимости со старыми тестами и использовать ПолучитьСписокТестов(КонтекстЯдра) как и в 3.0, а Инициализация(КонтекстЯдраПараметр) сделать необязательным при наличии ПолучитьСписокТестов(КонтекстЯдра)
ИМХО в этом случае никаких старых тестов переделывать не нужно и 4.0 взлетит сразу :) А в документации укажем только новый вариант Инициализация(КонтекстЯдраПараметр) и ПолучитьСписокТестов()
@wizi4d https://github.com/wizi4d что скажешь?
— Reply to this email directly or view it on GitHub https://github.com/xDrivenDevelopment/xUnitFor1C/issues/557.
З повагою Сосна Євген, mailto:[email protected] skype:shenjasosna +380933897103
1 При получении списка тестов контекст ядра нужен для возможности работы с ядром :) Фреймворк это же просто запускалка тестов, но и набор полезных функций/плагинов. А плагины нужны на этапе создания списка тестов Например, у меня есть тесты, в которых список тестов получается в зависимости от метаданных конфигурации. И еще вопрос - зачем нам плагины, которые можно вызывать только для непосредственного тестирования ? работа в режиме получения списка тестирования это также работа во фреймворке.
2 Инициализация должна выполняться всегда.
Давайте по порядку.
Все-таки подумать о совместимости со старыми тестами
Обратной совместимости все равно не получится достичь, потому что раньше был всего 1 контекст юТест, теперь же контексты ядра, утверждений и генерации данных это 3 разных контекста, которые в одну переменную ну никак не впихнуть.
При получении списка тестов контекст ядра нужен для возможности работы с ядром
- Я просил конкретные кейсы, а получаю абстрактные утверждения, что это просто нужно. Давай cформулируем пользовательскую историю по шаблону "Как X Я хочу Y Чтобы Z". Как ты понимаешь, мне очень интересно то, чему будет равен Z.
- Прошу принять во внимание, что я по максимуму следую принципу единой обязанности. Пока же я вижу, что есть попытка этот принцип нарушить.
Я думаю о хотя бы частичной обратной совместимости при переходе на 4.0 Сейчас при переходе на 4.0 очень серьезная потеря совместимости. Очень много тестов придется менять, только у меня под 2 тысячи тестов, сто с лишним файлов тестов :( Хочется как-то облегчить процесс перехода на 4.0, нужно поддержать своих пользователей и упростить им переход. Иначе может сложиться ситуация, что народ останется на 3.Х :(
Поэтому я решил заняться конвертером тестов из 3.Х в 4
Конвертер дело хорошее. Правда с этой темой никак не связан :smile: Если живых кейсов нет либо они приведут к нарушению принципа единой обязанности, то предлагаю задачу закрыть.
По получению списка тестов и контексту ядра В новом варианте (4х) у теста получается 2 состояния - работа в режиме тестирования и работа в режиме получения списка тестов. Код инициализации этих состояний разный :( в одном случае вызывается Инициализация, в другом нет. Почему так? я в первую очередь против этого
Ты меня не понял, я не призываю нарушить принцип единой обязанности. Каждый метод выполняет свою функцию - Инициализация инициализирует тест, ПолучитьСписокТестов получает список. Я против двойного входа по созданию тестов, когда в одном случае вызывается Инициализация, в другом нет.
Никаких режимов тестирования и получения списка тестов нет. Есть просто метод получения списка тестов. Инъекция зависимости может быть осуществлена через параметр, если это реально нужно, но я не представляю ситуацию, когда для получения списка тестов может понадобиться прям контекст ядра. Инъекция зависимости должна быть строго в соответствии с требуемой абстракцией, например, как сделано в новом интерфейсе по получению списка тестов.
По кругу ходим :disappointed: Давай cформулируем пользовательскую историю по шаблону "Как X Я хочу Y Чтобы Z" Я даже начну, чтобы помочь.
КАК пользователь xUnitFor1C Я ХОЧУ чтобы всегда вызывался метод Инициализация у тестовой обработки ЧТОБЫ ...
Собственно чтобы что?
Конечно, ходим:(
Чтобы в коде теста ВСЕГДА иметь доступ ко всей мощи фреймворка xUnitFor1C
Есть игра в 5 "Почему?", я ее превращу в 5 "Чтобы что?" :smile:
КАК пользователь xUnitFor1C Я ХОЧУ при получении списка тестов иметь доступ ко всей мощи xUnitFor1C ЧТОБЫ ... что?
У меня кейсов нет, и пока не придумывается ни одного. Артур написал, цитирую: "Например, в некоторых моих тестах используется этот функционал...". Артур, можешь описать кейс по одному из существующих тестов (лучше по трем)? Сейчас пока более понятна позиция Евгения.
Еще одна попытка :(
У фреймворка есть куча полезных методов.
при получении списка тестов в моих тестах используются утверждения + методы получения информации из базы данных, например, ПолучитьЭлементыМетаданногоПоОтбору или ПолучитьКоличествоЭлементовСправочникаПоОтбору
я люблю защитное программирование и утверждения использую часто. Отсутствие доступа к утверждениям из-за отсутствия контекст фреймворка меня сильно напрягает, тем более, что сейчас это искусственное ограничение.
ЗЫ начинает надоедать это бессмысленное перекидывание мячика туда/обратно :(
Последнее предложение - добавляем параметр КонтекстЯдраПараметр в ПолучитьСписокТестов() и ЗаполнитьНаборТестов(Набор)
Ты по прежнему не отвечаешь на прямой вопрос, "зачем тебе это?". Реальный кейс так и не описываешь.
В каких случаях ты используешь то, что описал? А именно:
- Когда тебе нужны утверждения при получении списка тестов?
- Когда тебе нужны какие-то специфические методы ядра или плагинов? (btw приведенных тобой методов в новой версии фреймворка нет, по крайней мере я их туда не добавлял)
- Не нарушает ли это принцип единой обязанности?
Важно!!! Я хочу понять, какая цель/потребность у того, что ты просишь сделать. Когда станет понятна цель, будем думать, как ее достичь.
Пока же это как в классических проблемах с заказчиками, когда они проходят с готовыми решениями, но не озвучивают своей цели/потребности.
я люблю защитное программирование и утверждения использую часто. Отсутствие доступа к утверждениям из-за отсутствия контекст фреймворка меня сильно напрягает, тем более, что сейчас это искусственное ограничение.
Вот этого мало?
Слишком конкретный кейс я не хочу приводить, т.к. мы уйдем в детали реализации этого конкретного кейса и наверняка будут приведены обходные пути.
Далее я планирую выносить в плагины различные полезные общие методы для тестов, некий аналог библиотек. И вот эти общие методы/объекты должны быть доступны тестам на всех стадиях работы.
Я понимаю, что 1С это не ООП в чистом виде. Но то, что ты хочешь - это сильное нарушение принципов SOLID.
Ой, а можно я, можно я?! тянет руку
- Я хочу обратную совместимость в рамках "зафигачил старый тест и забыл" 1.1 - сейчас такая возможность есть, через необязательный параметр метода ПолучитьСписокТестов()
- Сейчас Инициализация и ПолучитьСписокТестов вызываются для одного и того же экземпляра обработки или для разных? Если Инициализация предшествует вызову ПолучитьСписок, то что мешает сохранить контекст ядра в переменную, а в получить список - его заюзать?
- Версия 4.0 не должна ничего передавать в ПолучитьСписокТестов, здесь я солидарен с @wizi4d. Это зло и пагубный путь. Говнокод только и ищет момент, когда будут допущены послабления контрактов, после чего хлынет рекой.
@EvilBeaver я в первую очередь думаю о совместимости и программном интерфейсе.
1 и 3 у тебя противоречат друг другу :(
2 Инициализация сейчас вызывается только после запуска тестов на выполнение. в момент загрузки тестов (получения списка тестов) не вызывается.
Фишка в чем - ПолучитьСписокТестов не вызывается при запуске тестов на выполнение, т.к. дерево тестов сформировано заранее.
Мы как раз обозначаем, что тесты должны реализовать 2 разных публичных интерфейса для выполнения тестирования.
Один интерфейс это загрузка тестов, второй - выполнение тестов.
за работу в этих состояниях отвечают разные наборы методов.
За загрузку отвечают ПолучитьСписокТестов или ЗаполнитьНаборТестов
За выполнение - Инициализация, метод теста, ПередЗапускомТеста/ПослеЗапускаТеста и прочее.
В обоих случаях в методы инициализации разного поведения мы передаем контекст ядра для того, чтобы тесты могли полноценно пользоваться методами/объектами фреймворка тестирования.
ИМХО С точки зрения ООП и принципов проектирования все нормально.
@artbear ничего у меня не противоречит. Это желания.
КАК пользователь xUnitFor1C Я ХОЧУ при переходе на версию 4 минимально доработать существующие тесты ЧТОБЫ не тратить время на кардинальную переработку
Ты же хочешь нарушить интерфейсы между модулями только потому, что у тебя ассерты стояли в методе получения списка и ты теперь не хочешь там ничего рефакторить.
В то же время, я склоняюсь к тому, чтобы метод Инициализировать вызывался не только перед прогоном тестов, но и вообще, при каждом создании экземпляра обработки со стороны ядра. Ну или пусть это будут два разных метода, но смысл такой, что предварительная инициализация - не такая уж плохая идея. Пусть, например (мысли вслух), будет событие "ПриСозданииОбработкиЯдром(КонтекстЯдра)"... ну или как-то там так... А?
@EvilBeaver да, это один из двух путей, который я и предлагаю. Но мне немного не нравится, что здесь код Инициализации будет выполняться дважды - при загрузке тестов и при выполнении тестов. Я вижу, что код инициализации соответствует конструктору теста, который вызывается.
Меня на текущий момент устроит любой из 2х вариантов.
КАК пользователь xUnitFor1C Я ХОЧУ при переходе на версию 4 минимально доработать существующие тесты ЧТОБЫ не тратить время на кардинальную переработку Ты же хочешь нарушить интерфейсы между модулями только потому, что у тебя ассерты стояли в методе получения списка и ты теперь не хочешь там ничего рефакторить.
Зря ты на меня наезжаешь, я как раз и думаю о совместимости. Я даже начал делать конвертер тестов 3.Х на 4 #518
@artbear я не наезжаю, но я против поспешных решений. И я против того, чтобы в ПолучитьСписокТестов что либо передавалось, т.к. этот метод совсем про другое. У него другая ответственность ( @wizi4d ) Не надо его перегружать дополнительными смыслами.
Я выше писал, что помню о договоренности вызывать Инициализацию всегда при создании объекта, неважно, в какой момент это происходит. Женя не хочет этого делать.
@EvilBeaver
Сейчас Инициализация и ПолучитьСписокТестов вызываются для одного и того же экземпляра обработки или для разных? Если Инициализация предшествует вызову ПолучитьСписок, то что мешает сохранить контекст ядра в переменную, а в получить список - его заюзать?
Экземпляры разные.
Теперь для всех. Для бОльшего понимания, как все работает.
Наличие метода Инициализация обязательно для любых тестовых обработок, метод вызывается ядром, перед выполнением теста. О любых других методах ядро ничего не знает и знать не должно.
Все остальное - требование конкретных загрузчиков. Так, метод ПолучитьСписокТестов - требование к программному интерфейсу тестовых обработок от загрузчика файлов для формирования дерева тестов.
Из этого следует, что это методы разных интерфейсов.
@artbear
Я выше писал, что помню о договоренности вызывать Инициализацию всегда при создании объекта, неважно, в какой момент это происходит. Женя не хочет этого делать.
Утверждение в корне не верно. Прежде чем хоть что-то делать, я всегда задаю вопрос "Чтобы что?", ты же меня знаешь. Это позволяет избежать ненужной работы. Я хочу понимать, какую цель/потребность ты преследуешь созданием этой задачи. Ты ведь не просто так это все затеял. Ну а пока цели не понятны, смысла предпринимать хоть какие-то телодвижения не вижу.
Можно и я выскажу свое имхо в таком интересном и драматичном обсуждении? Должен предупредить, что xUnitFor1C я не пользуюсь, как там все устроено, практически не знаю, и рассуждаю только исходя из прочитанного в этом обсуждении. Как мне кажется, основная проблема в том, что вы пытаетесь натянуть принципы ООП на разработку, написанную на языке, ООП не поддерживающем. Как я понимаю, тест у вас - это внешняя обработка, к которой вы хотите относится как к классу в ООП. Но у класса должны быть конструкторы/деструкторы. И как мне показалось из обсуждения, метод Инициализация() и является своеобразным конструктором. По крайней мере, имхо, @artbear к этому методу относится именно так. А вот @wizi4d относит этот метод всего лишь к одному из интерфейсов. Как мне думается, всякие конкретные загрузчики не должны создавать сами объект внешней обработки, они должны вызывать некий метод ядра для получения объекта теста, а внутри этого метода ядра должна создаваться внешняя обработка и вызываться Инициализация(). Образно говоря, загрузчики не должны сами делать malloc(), они должны делать new.
