Вот даже и в спеке сказано "Program execution begins by initializing the program and then invoking the function main in package main. When that function invocation returns, the program exits. It does not wait for other (non-main) goroutines to complete."
Подскажите, пожалуйста, конкретно в Go я новичок, но разве раньше (пусть до 1.14) такой бесконечный цикл именно после завершения main мог заблокировать выполнение? Завершение main означает смерть всех горутин, разве нет? Тут не важно есть ли в них вызов планировщика. Мне кажется что если тут и есть проблема то не в этом, может быть main НЕ завершается? Потому что println, являясь io вызовом, является preemption point и в этот момент горутина вытесняет main, а вот обратно уже нет? Но не знаю, все-таки это не network io.
«С точки зрения дизайна»… Поправьте меня, если принят иной взгляд на это, но в моем понимании отображение контента на мобильных устройствах — и выбор доступного при этом функционала и организация доступа к нему — это тоже дизайн. Особенно в наши дни и тем более если имеется версия сайта, по идее адаптированная для мобильных устройств.
Понимаю ваши рассуждения, но я как раз и попытался взглянуть на ситуацию с той стороны, которая позволяет рассматривать это по-прежнему как blackbox. Сделать decoupling между разметкой и контроллером — и тестировать не компонент в целом как блекбокс, а два куска компонента как два блекбокса. Возможно, я перемудрил с этим, но до тестирования реализации мы тут не скатываемся. Да и почему сложнее ложится на реальные сценарии? Мы просто вместо «поставил стейт и нажал кнопку» будем делать «поставил стейт и сказал что нажал кнопку» — практически одно к одному.
Если ваш опыт говорит, что без проблем можно действовать через симуляцию enzyme и component.find — возможно, так и следует делать, а не как я предложил.
Ну это нормально — отдельный тест проверяет что кнопку в некой ситуации нельзя нажать. Одно условие — один тест. Вот тут я не знаю, как лучше это сделать — простейший способ при помощи сравнения с эталонной разметкой (допустим, проверяется что на кнопке есть класс button-disabled), но ведь она может быть и неправильной. Если тут именно simulate сработает более правильно — учитывая все атрибуты — то возможно все же следует его использовать.
На самом деле проверка того что кнопку нажать не получается — это интеграционный тест. Он проверяет 1) классы 2) получившиеся в результате атрибуты 3) какие-то контролы которые возможно кнопку закрывают на экране (те же модалки всякие), и тд; может, для этого даже лучше прикручивать всякие разные селениумы, которые для интеграционного и предназначены?
1) если у вас очень простые внутренности у компонента — как в вашем примере один button — то может и не стоит городить огород из клика по нему (я ж там чуть дальше и пишу что возможно и не стоит заморачиваться). А если у вас две кнопки, то выбор одной из них начинает выглядеть уже некрасиво, разве что у них еще и id например есть; хотя и тут вы можете сами для себя решить, что проще их искать каким-то селектором, чем дергать через апи.
2) TheShock привел пример. Понятно что этот hover может быть и не обрабатывается в приложении, но факт тот, что мы с одной стороны как бы «имитируем событие», а с другой, в реальной жизни оно в таком виде и одно — не возникает. А вызов метода «пользователь нажал на кнпоку» — это уже чуть выше по уровню абстракции и можно там игнорировать какую-то специфику работы браузера (ненужные нам события).
Ну, то есть я отдельно в тексте не выделил, что внешние зависимости следует мокать, но это как бы в контексте юнит-тестирования само собой подразумевается. Добавлю указание, что речь именно о юнит-тестировании.
Так я в сущности так и делаю тут. Я задумал тестировать публичные «действия юзера» — тот код контроллера, который они дергают, еще не означает интеграционный тест; и даже механизмы react при этом не задействуются: только код обработчика, другие какие-то методы компонента, и переданный props.setXXX; ну и возможно заодно какие-то сервисы (которые в этом случае следует так или иначе замокать). Вроде бы вполне модульно получается?
Вот даже и в спеке сказано "Program execution begins by initializing the program and then invoking the function
mainin packagemain. When that function invocation returns, the program exits. It does not wait for other (non-main) goroutines to complete."Подскажите, пожалуйста, конкретно в Go я новичок, но разве раньше (пусть до 1.14) такой бесконечный цикл именно после завершения main мог заблокировать выполнение? Завершение main означает смерть всех горутин, разве нет? Тут не важно есть ли в них вызов планировщика. Мне кажется что если тут и есть проблема то не в этом, может быть main НЕ завершается? Потому что println, являясь io вызовом, является preemption point и в этот момент горутина вытесняет main, а вот обратно уже нет? Но не знаю, все-таки это не network io.
Если ваш опыт говорит, что без проблем можно действовать через симуляцию enzyme и component.find — возможно, так и следует делать, а не как я предложил.
На самом деле проверка того что кнопку нажать не получается — это интеграционный тест. Он проверяет 1) классы 2) получившиеся в результате атрибуты 3) какие-то контролы которые возможно кнопку закрывают на экране (те же модалки всякие), и тд; может, для этого даже лучше прикручивать всякие разные селениумы, которые для интеграционного и предназначены?
2) TheShock привел пример. Понятно что этот hover может быть и не обрабатывается в приложении, но факт тот, что мы с одной стороны как бы «имитируем событие», а с другой, в реальной жизни оно в таком виде и одно — не возникает. А вызов метода «пользователь нажал на кнпоку» — это уже чуть выше по уровню абстракции и можно там игнорировать какую-то специфику работы браузера (ненужные нам события).