просто я пока писал комментарий, вы уже дополнили ответ по 4 ситуацииНу да, я для ясности псевдокод усложнил. На самом деле Promise.resolve() вполне себе умеет принимать на вход другой промис и в дополнительной проверке нет смысла.
Т.е. в ситуации 2 идет именно просто игнор, а не создание какого-то промиса-заглушки-пустышки, правильно я понял?Чтобы достоверно ответить на этот вопрос, нужно читать спеку или исходники реализации. Поскольку сценарий высосан из пальца, в реальности не встречается и ответ не имеет никакого практического значения, делать я этого не буду :)
Так получается?Я показал псевдокодом, как это происходит в моём понимании. Опять же - разработчику не нужно погружаться в эти детали реализации, особенно в начале пути. Вас должен интересовать только внешний API, с которым вы непосредственно взаимодействуете, а он хорошо описан в документации и в примерно миллионе статей и курсов.
чтобы они удостоверились в разработке на ReactЭто очень странная задача. Кажется, мы имеем дело с Проблемой XY.
getElementById и нет, на самом деле, такого специфического случая. Он работает точно так же, как querySelector, только # указывать не нужно. Гораздо проще не мудрить и использовать для всех выборок один метод.getElementsByClassName.
HTMLCollection вместо NodeList (почти никогда не надо), нет никаких причин использовать getElementsByClassName. Используйте querySelector, когда хотите получить один элемент и querySelectorAll, когда вам нужен список из нескольких.
Идём дальше: мы хотим протестировать поиск по продуктам. Продукт не может существовать без раздела и цены для данного типа пользователя. Мы либо в тесте под капотом засидим базу нужными данными, либо пойдём через Postman создавать по цепочке через API все эти сущности (по дороге борясь с валидацией, которая, может включать в себя, например, обязательность картинки, загруженной через multipart-форму). Мне вот как-то кажется, что первый способ проще.
У записи могут быть служебные поля, которые не отдаются в ответе API, но заполнение которых важно проверить.
В общем - использовать только Postman для тестирования хоть сколько-то сложного проекта не получится. И тогда встаёт вопрос: а зачем вообще тесты разбивать на два инструмента?