«С точки зрения дизайна»… Поправьте меня, если принят иной взгляд на это, но в моем понимании отображение контента на мобильных устройствах — и выбор доступного при этом функционала и организация доступа к нему — это тоже дизайн. Особенно в наши дни и тем более если имеется версия сайта, по идее адаптированная для мобильных устройств.
Понимаю ваши рассуждения, но я как раз и попытался взглянуть на ситуацию с той стороны, которая позволяет рассматривать это по-прежнему как blackbox. Сделать decoupling между разметкой и контроллером — и тестировать не компонент в целом как блекбокс, а два куска компонента как два блекбокса. Возможно, я перемудрил с этим, но до тестирования реализации мы тут не скатываемся. Да и почему сложнее ложится на реальные сценарии? Мы просто вместо «поставил стейт и нажал кнопку» будем делать «поставил стейт и сказал что нажал кнопку» — практически одно к одному.
Если ваш опыт говорит, что без проблем можно действовать через симуляцию enzyme и component.find — возможно, так и следует делать, а не как я предложил.
Ну это нормально — отдельный тест проверяет что кнопку в некой ситуации нельзя нажать. Одно условие — один тест. Вот тут я не знаю, как лучше это сделать — простейший способ при помощи сравнения с эталонной разметкой (допустим, проверяется что на кнопке есть класс button-disabled), но ведь она может быть и неправильной. Если тут именно simulate сработает более правильно — учитывая все атрибуты — то возможно все же следует его использовать.
На самом деле проверка того что кнопку нажать не получается — это интеграционный тест. Он проверяет 1) классы 2) получившиеся в результате атрибуты 3) какие-то контролы которые возможно кнопку закрывают на экране (те же модалки всякие), и тд; может, для этого даже лучше прикручивать всякие разные селениумы, которые для интеграционного и предназначены?
1) если у вас очень простые внутренности у компонента — как в вашем примере один button — то может и не стоит городить огород из клика по нему (я ж там чуть дальше и пишу что возможно и не стоит заморачиваться). А если у вас две кнопки, то выбор одной из них начинает выглядеть уже некрасиво, разве что у них еще и id например есть; хотя и тут вы можете сами для себя решить, что проще их искать каким-то селектором, чем дергать через апи.
2) TheShock привел пример. Понятно что этот hover может быть и не обрабатывается в приложении, но факт тот, что мы с одной стороны как бы «имитируем событие», а с другой, в реальной жизни оно в таком виде и одно — не возникает. А вызов метода «пользователь нажал на кнпоку» — это уже чуть выше по уровню абстракции и можно там игнорировать какую-то специфику работы браузера (ненужные нам события).
Ну, то есть я отдельно в тексте не выделил, что внешние зависимости следует мокать, но это как бы в контексте юнит-тестирования само собой подразумевается. Добавлю указание, что речь именно о юнит-тестировании.
Так я в сущности так и делаю тут. Я задумал тестировать публичные «действия юзера» — тот код контроллера, который они дергают, еще не означает интеграционный тест; и даже механизмы react при этом не задействуются: только код обработчика, другие какие-то методы компонента, и переданный props.setXXX; ну и возможно заодно какие-то сервисы (которые в этом случае следует так или иначе замокать). Вроде бы вполне модульно получается?
Если ваш опыт говорит, что без проблем можно действовать через симуляцию enzyme и component.find — возможно, так и следует делать, а не как я предложил.
На самом деле проверка того что кнопку нажать не получается — это интеграционный тест. Он проверяет 1) классы 2) получившиеся в результате атрибуты 3) какие-то контролы которые возможно кнопку закрывают на экране (те же модалки всякие), и тд; может, для этого даже лучше прикручивать всякие разные селениумы, которые для интеграционного и предназначены?
2) TheShock привел пример. Понятно что этот hover может быть и не обрабатывается в приложении, но факт тот, что мы с одной стороны как бы «имитируем событие», а с другой, в реальной жизни оно в таком виде и одно — не возникает. А вызов метода «пользователь нажал на кнпоку» — это уже чуть выше по уровню абстракции и можно там игнорировать какую-то специфику работы браузера (ненужные нам события).