Из чего состоит шаг?

Шаг полностью создаётся разработчиками или пользователем Ванессы или же есть какие-то служебные операторы (если тогда иначе цикл пока для каждого), и разработка шага - это только разработка проверки условия?

Например, я хочу иметь шаги

  1. Если Погода = -30ИСнег Тогда
  2. Пока Погода = -30ИСнег Цикл

Мне нужно разработать оба шага в описанном виде или же можно сделать шаг, который будет проверять условие Погода = -30ИСнег, а дальше я просто делаю конструкции
Если <МойШагПроПогоду> Тогда
Пока <МойШагПроПогоду> Цикл
?

@for_sale как-то с середины Ваш вопрос?

зачем тебе нужны шаги - Если Погода = ХХХ Тогда ?

в тестах вообще НЕЖЕЛАТЕЛЬНЫ ветвления.

ведь при ветвлении

  • непонятно, какая из частей функционала проверяется?
  • при одном запуске теста будет проверена только одна часть ветвления? а как/когда будет проверяться вторая часть?

правильно делать несколько сценариев (например, 2) вместо ветвления.

и возвращаемся к началу - цель какая?
что хотите проверить?

Спасибо за ответ!

Этот вопрос перекликается с моим вторым вопросом про циклы. Например, такая ситуация - открывается форма, из неё идут запросы во внешний АПИ. Иногда, довольно часто, и это в том числе цель доработки и тестирования, АПИ отваливается на той стороне, т.е. в 1С нет ничего, что могло бы спрогнозировать - придёт ответ от АПИ или нет. Но при этом пользователю интерфейс блокируется, чтобы он там не наклацал чего, пока оно грузится. Поэтому в тесте желательно бы как-то понимать - пришло или нет? ЕСЛИ пришло - тогда продолжаем тест. ИНАЧЕ - закрываем форму, открываем форму, перезапускаем запрос в АПИ - что-то в этом роде.

Ещё не привык думать в парадигме тестирования, поэтому не исключаю, что это можно победить как-то по-другому.

Вообще интеграционное тестирование - сложная штука.
А если еще юзать внешнее АПИ не под своим управлением, это совсем непросто.

очень часто такие тесты падают по разным причинам - нет связи, изменилось АПИ и т.п.
И бывает нелегко быстро понять причину падения.

Желательно к таким интеграционным тестам добавлять еще и более мелкие тесты, аналог юнит-тестов - проверять поведение до и после вызова АПИ без вызова самого АПИ.
Способов много - эмуляция, моки.

Вообще такие тесты, когда нет связи, будут часто падающими, в разные моменты времени. их еще называют flaky-тесты.
Наличие таких тестов - это большая боль для команды. Т.к. непонятно, нужно ли его чинить сейчас, т.к. это проблема на нашей стороне, или нет?

  • Главный вопрос - если все-таки нет связи с АПИ, тест считается упавшим или нет?

тут нужно понять тест-кейс и его ограничения.

  • нужно бесконечно долбиться до АПИ, если нет связи, или нет?
  • сколько нужно сделать попыток?
  • или по времени сколько раз пытаться?

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

КолвоПопыток = 0;
Пока НЕ ПолучилосьДостучаться И КолвоПопыток < 10 Цикл
ПолучилосьДостучаться = ПробуемДостучаться();
КолвоПопыток++;
КонецЦикла;
Если КолвоПопыток = 10 Тогда
СегодняНеТвойДень();
Возврат;
КонецЕсли;

Тест();

Т.е. красным неудачу по АПИ тоже нельзя считать, потому что теста-то фактически и не было в этом случае. Но и навечно его вешать Пока НеДостучится - тоже неправильно, потому что теоретически можно повиснуть вообще навсегда, плюс получить бан в АПИ за ДДОС.

Моками пользоваться тоже не хотелось бы, потому что АПИ на той стороне развивается, иногда может поменяться что-то раз в полгода, иногда - раз в неделю. Получить зелёные тесты, выкатить продукт, а потом получить праведную ярость от клиентов, у которых ничего не работает, потому что в АПИ поменялось поле, тоже не хочется.

Тут даже не столько вопрос в том, что можно не достучаться, сколько в том, что время ответа плавает, может быть 1 секунда, может быть 20 секунд, соответственно, хотелось бы начать тест только после того, как стало ясно, что ответ пришёл и форма разблокировалась. Каждый раз ожидать 20 сек тоже вариант так себе, потому что иногда и это время не предел, а иногда и вообще ответа не бывает. Плюс у нас на самом деле используется, кажется, 3 разных АПИ, т.е. на одной из форм бывают всякие наложения всех этих Блок-Запрос-Ответ-Анблок.

В принципе, наверное, всё-таки можно установить ВремяОжидания=20 и просто ждать каждый раз 20 сек, если ответа нет - тогда таймаут, перезапуск. Но всё же думал, может, есть какие-то ветвления.

пропустил ответ, извините.

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

а ветвление, как выясняется в очередной раз, это перебор при тестировании.