Коллеги подскажите использование [Order] в Nunit плохая практика как я понимаю. Но как обойтись без этого когда нужно протестировать сложную бизнес логику где переходим на 10 страниц  ?

В одном тесте. [Fact] или как там оно

Это был июль этого года) возможно на большое количество предложений так же повлиял недавний выпуск. Но факт остается фактом, что спрашивали в основном про строчку в резюме про c#

Так тогда протеворечет правилу на 1 тест 1 Assert

это ж правило для юнит теста

иногда есть смысл зафейлиться сразу, получив 500, чем пытаться искать что-то, что не вернулось. Вот тебе уже минимум 2 ассерта

Такого правила нет.

Имеется ввиду "один логический ассерт". Если у вас длинный сценарий, то логический ассерт - "сценарий завершен успешно"

Про один ассерт в коде - это чушь.

Спасибо )

И для юнит теста нет такого правила.  Можно привести кучу примеров, где несколько ассертов - это естественно и разумно

приведите, пожалуйста, никогда такого не видел

Интересно как будет выглядить тестовый метод и на сколько строк. Допустим нам нужно в каждом методе вызывать метод регистрации , который будет перебрасывать на нужную страницу. Преимущество же конечно что можно распаралелить сами тесты

Но никто не мешает при использовании Order паралелить фикстуры

да вообще нет такого правила)

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

Никто не запрещает делить на методы для удобства чтения) но тест - один, остальные методы - приватные например.

Когда до компа доберусь. Напомните, если забуду

вызываете функцию, получаете респонс. Первый ассерт проверяет тип возврата, второй - значение. С точки зрения результата теста это лучше, чем один ассерт с and внутри

это вы сейчас про языки с динамической типизацией?

Привет . Хочу переходить на технологии cucumber+ Appium+Java. Насколько это перспективно? Раньше на чистом селениуме писала, создавала свой фреймворк для веб-апликации на .NET

Сценарные е2е тесты сложно представить с одним ассертом. В юнит тестах этой рекомендации следуют чтобы легко было точечно проблему локализовать, и это работает только потому, что в юнит тестах контекст воссоздать сравнительно дёшево по времени / ресурсам. В UI тестах сценарных зачастую в приложениях, где ты не можешь драйвить состояние приложения, а только как пользователь делаешь тест максимально человеко-подобным, контекст создавать дорого, и «один асерт на сценарий» это слегка попахивает оверинжинирингом