Думаю, что тривиальными они становятся для специалиста, который сталкивался с ними неоднократно и уже знает, где соломку подстелить. Недавно администрация сайта упоминала, что очень многие люди (больше 60% посетителей) заходят на сайт из поисковиков. Многие из них — новички, которые не всегда задумываются о вещах, не связанных непосредственно с решением стоящей перед ними задачи. Вот для таких людей эта статья может оказаться крайне полезной, а проблемы, описываемые в ней — далеко не тривиальными.
Хороший подход, вполне позволяет писать тесты на контроллер. Но есть и минусы: когда в публичном интерфейсе класса есть attr_writer, можно решить, что где-то кто-то собирается поменять значение поля (или, по крайней мере, может это сделать). Особенно эти проблемы проявляют себя тогда, когда код сервиса начинает расширяться с помощью плагинов, хранящихся в отдельных репозиториях (например, при использовании модификаций одного и того же сервиса для разных компаний-заказчиков).
В общем, писать код с оглядкой на тесты — это одно. Писать код, который будет использоваться только в тестах, уже другое.
Странно, что в голосовании нет варианта WithMe — единственного, который выделяет оба слова. Ну и хэштег #Спортспервымвстречным совершенно не читается. Хотя это моё личное мнение; может, кто-то считает это модным и трендовым, а readability уже не котируется.
Я правильно понимаю, что хэш поможет только в том случае, если злоумышленники получили доступ лишь к смене файла для загрузки? Ведь если есть полный доступ к системе, можно без проблем поменять и файл, и хэш на сайте. Это даже создаст иллюзию безопасности (что, на мой взгляд, ещё хуже её очевидного отсутствия).
Да, в любом случае это будет сложным процессом. Но в сравнении с переписыванием всех тестовых сценариев количество мест, где можно ошибиться, существенно снижается.
Однажды видел (возможно, в виде упоминания на Хабре) интересный вариант применения Gherkin: допустим, первая версия продукта пишется на Ruby в целях ускорения разработки. Для неё пишутся тесты на Gherkin. Затем, когда продукт уже выпущен, набирает пользователей и в целом более-менее устоялся, его начинают переписывать, к примеру, на Java. Тогда надо просто переписать step_definitions с Ruby на Java, а сами сценарии (которых могут быть тысячи) остаются неизменными. Конечно, редкий случай, но для него применение Gherkin весьма полезно.
К своему стыду, до вашего комментария я считал http/2 стандартом, поддержка которого ещё не скоро будет реализована. Оказалось, что это уже не так. Постараюсь в ближайшее время его настроить, оценить результаты и дополнить пост. Спасибо за ценное замечание!
1. Да, можно, и это будет правильно. Хотя я и не могу придумать, как проекту сайту можно навредить, эксплуатируя звёздочку в Access-Control-Allow-Origin. Впрочем, если кто-то не знает об уязвимости, это не значит, что её нет.
2. В статье я для примера привёл разделение на .com/.ru. На самом деле, в моём случае ресурсы немного разные, хоть и обслуживаются одним и тем же инстансом, поэтому и пришлось разделять ссылки по доменам. А в случае простого синонима — конечно, вы правы, можно обойтись простой строкой в настройках, да.
По поводу set_variants — уверен, что скоро сделают какой-нибудь гем с названием, к примеру, «popluar_variants», и будет альтернатива: использовать магию или настраивать вручную. Хотя вы правы: видеть подобный функционал из коробки было бы вполне логично.
Считаю это более-менее корректным поведением.
В общем, писать код с оглядкой на тесты — это одно. Писать код, который будет использоваться только в тестах, уже другое.
2. В статье я для примера привёл разделение на .com/.ru. На самом деле, в моём случае ресурсы немного разные, хоть и обслуживаются одним и тем же инстансом, поэтому и пришлось разделять ссылки по доменам. А в случае простого синонима — конечно, вы правы, можно обойтись простой строкой в настройках, да.