вроде точно =)

хорошее определение

у меня мак не под рукой

brew install pulseaudio и сам узнаешь :)

на маке пульсаудио работает да. я уже запускал

да да работает так

но докер ругается когда пытаешься сделать run с припиской /dev/snd

с последним апдейтом макоси нельзя быть ни в чем уверенным :)

Привет, Вы именно имели дело с электрон приложением?

Всем привет.
Практикуется ли такое в вашей стези, чтобы Thread.sleep запихнуть в отдельный метод, что бы не засорять код трай-кетчами?
Wait'ом у меня не получается сделать то, что мне нужно, ибо элемент, который он ищет и "ждет", пока он станет кликабельным, появляется сразу с загрузкой страницы и это никоим образом не заставляет его сделать задержку. А она нужна, чтобы страница секунд 3 пришла в себя и  далее я с ней делаю манипуляции.

вот об этом речь:
   public void waiter(){
       try {
           Thread.sleep(3000);
       } catch (InterruptedException e) {
           e.printStackTrace();
       }
   }

Вообще лучше конечно обходиться без него, у selenide есть куча своих ожидалок советую лучше посмотреть их

И плюс конечно expected conditions:)

объясните кто-то, почему у всех такое отношение к thread.sleep'у?

Может есть другие признаки, что страница успешно загрузилась и "пришла в себя"?

Потому что в слип забито константное значение, а сайт завтра может измениться, и например задержки не будет. Тогда мы тратим лишние 3 секунды. Или - наоборот, задержка стала больше, придется увеличить тайм-аут. А если таких мест много? Попробуйте жонглировать этими слипами

Не вижу таких. Может еще быть беда в моем компуктере старом, который живет своей жизнью.

Но, если слип решает проблему, то используйте. Если вы один на проекте, никто слова не скажет. Работающий тест важнее не работающего

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

У меня тоже есть слип в одном месте в 300мс ). И ничего, это лучше, чем вейтер. И эти 300мс не менялись... никогда

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

Оцените сколько тратят время тесты на ожидание, характер запуска тестов, сколько их нужно успевать запускать на полную / частичную регрессию как в реальной жизни это мешает разработке с вашим размером команды и доступности ресурсов. А ещё некоторые ожидания бывает дороже починить чем время время разработчика автотестов. Единственное что однозначно должно присутствовать в строке с ожиданием — это объяснение причины так делать. Ответишь — и ты на полпути к лучшему решению.