Size: a a a

2019 February 20

LP

Leonid Pautov in testspro1c
Alexander Tsukanov
Leonid В порядке бреда.
Вот сижу проверяю сценарий и невольно возникает следующая мысль:
Первой линией обороны в кликере судя по всему должна быть проверка текущего окна.
Оно гаранированно валит сценарий если в процессе что-то пошло не так (неожиданное окно) или вылетело исключение.
Но шаг проверки окна нужно во-первых вдумчиво расставлять и следить что он везде где нужно есть (где меняется текущее окно),
плюс при ревью сценария приходится их выуживать и интерпретировать в голове что происходит и не пропущен ли такой шаг.
Хотелось бы чтобы смена текущего окна как-то нативно логически выделялась в сценарии.
Типа чтоб был синтаксический элемент "Я работаю с окном 'заголовок окна'" и код под этим шагом выделяется оступом.
Т.е. чтоб был уровень визуально где меняются окна, а весь код под этими сменами с отступом. При этом шаг сам проверяет текущее окно до исполнения подчиненного кода и после. Ну и записывалка конечно должна сразу делать в таком формате.
Не совсем понимаю проблему. При накликивании всегда появляется шаг
Тогда открылось окно "Заголовок окна"
Он и гарантирует проверку смены окон.
источник

LP

Leonid Pautov in testspro1c
Если меняется заголовок окна - используйте символ *
источник

LP

Leonid Pautov in testspro1c
Тогда открылось окно "ЧастьИмени*"
источник

LP

Leonid Pautov in testspro1c
Символ * также используется при поиске элементов формы.
источник

LP

Leonid Pautov in testspro1c
Например:
Тогда элемент формы с именем "Наимен*" стал равен 'Нужное значение'
источник

LP

Leonid Pautov in testspro1c
Если нужно символ * использовать при проверке значений полей, то это пишется так
Тогда элемент формы с именем "Наименование" стал равен 'ЧастьСтроки*' по шаблону
В этом случае будет применятся регулярное выражение для проверки значения поля.
источник

AT

Alexander Tsukanov in testspro1c
Вопрос в оформлении кода. Я вроде все расписал подробнее некуда )
источник

LP

Leonid Pautov in testspro1c
Alexander Tsukanov
Вопрос в оформлении кода. Я вроде все расписал подробнее некуда )
Вопрос по отступу к шага? Я правильно понял?
источник

AT

Alexander Tsukanov in testspro1c
Ага
источник

LP

Leonid Pautov in testspro1c
Можно пример посмотреть - что вы хотите получить?
источник

AT

Alexander Tsukanov in testspro1c
ok, вечером нарисую пример
источник

LP

Leonid Pautov in testspro1c
Валентин Ажеронок
А вот шаблоны автозамены автоформируемых шагов конечно бы не помешали. А в шаблонах и отступы настроить можно было бы.
Тоже интересует более подробный пример.
источник

VL

Vladimir Litvinenko in testspro1c
Alexander Tsukanov
Возможно. Понятно что ко всему привыкнуть можно.
У нас пока получается так, что хорошо понимает сценарий только человек его писавший.
Чтение чужого сценария уже далеко не так легко (нет контекста в голове такого как у писателя).
А если сценарий без логических отступов, то чтение вообще в ад превращается.
В итоге мы все переформатировали руками и выделили кучу блоков с отступами где смогли.
Работа с вкладкой документа, составной шаг выбора значения и т.д.
Вот еще хотелось бы чтоб текущее окно выделялось отступом, но как лучше поступить непоятно.
Когда эти проверки линейно на уровне соседних шагов, приходится в голове весь процесс представлять себе визуально и так понимать какой участок кода в каком окне выполняется. Не знаю кому как, а для меня это тяжеловато.
Так ведь сразу начинать надо с общих понятных человеку высокоуровневых шагов. Или грппировку/декомпозицию делать сразу после написания сценария. Иначе "технический долг"  накопится так что потом с процентами отдавать не захочется )) Это чувствуется даже после появления первых сценариев. Когда много станет - уже сидеть с декомпозицией никто не захочет.

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

А кнопконажималка нам простыню неструктурированого текста выдаёт. Конечно её изначально нужно изначально записывать либо на основе тест-кейса-сценария, либо сразу после записи в порядок приводить группируя шаги. Тогда и читать сможет не только автор. И адаптировать проще будет. Автоматика не может сама за нас логические блоки продумывать. Надеястья, что кто-то научится видеть блондинку в красном в простыне иероглифов не стоит. Нужно нормально на логические блоки разбивать.
источник

AT

Alexander Tsukanov in testspro1c
> Или грппировку/декомпозицию делать сразу после написания сценария
Я разве спорю с этим? )
источник

AT

Alexander Tsukanov in testspro1c
> Автоматика не может сама за нас логические блоки продумывать.
Это понятно. Речь то была о совершенно конкретном элементе, который автоматика и так вставляет, просто без форматирования
источник

VL

Vladimir Litvinenko in testspro1c
Alexander Tsukanov
> Или грппировку/декомпозицию делать сразу после написания сценария
Я разве спорю с этим? )
Сделал такой вывод исходя из обсуждения выше и слов "У нас пока получается так, что хорошо понимает сценарий только человек его писавший."

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

A

Alexey Lab Sosnoviy in testspro1c
Сама мысль Группировать выхлоп кнопконажималки нормальная.
источник

AT

Alexander Tsukanov in testspro1c
Если не использовать автоматику, то можно вообще сразу на встроенном языке писать так как нужно )
источник

A

Alexey Lab Sosnoviy in testspro1c
его так проще разгребать будет
источник

VL

Vladimir Litvinenko in testspro1c
Alexey Lab Sosnoviy
Сама мысль Группировать выхлоп кнопконажималки нормальная.
Да, иначе действительно никто кроме автора не захочет разбираться в простыне кода. Антипаттерн "это не моя правка" ))
источник