14
Karma
0
Rating
Владислав @ihost

Программист

Тестовая задачка Яндекса

+3

Это задача о сумме подмножеств и имеет псевдополиномиальное время решения в общем случае.
Новенькие интересные алгоритмы можно посмотреть здесь или погуглить более широко.
В любом случае непонятно, почему минусят автора статьи, и тем более откуда предлагаются решения с линейной или квадратичной сложностью: пока не доказано P=NP — это невозможно решить быстрее.

Динамический импорт в JavaScript

+1
Google Chrome с 63 версии уже поддерживает эту возможность

А Edge и Safari поддерживают эту фичу уже два года — https://habr.com/ru/company/tuturu/blog/326716/. Оперативно, может еще через десяток лет хром наконец-то оптимизирует потребление памяти до уровня Edge

Динамический импорт в JavaScript

+1

В Edge и Safari эта фича уже давно поддерживается и работает — больше двух лет как — см. https://habr.com/ru/company/tuturu/blog/326716/ — как собственно и с множеством современных ES-фичей, которые в Edge поступают раньше, чем в хром

Уязвимость runC, затрагивающая Kubernetes, Docker и containerd

0

У docker-а скорее другая проблема: он не подходит для низкоуровневых highload приложений, вроде сетевого ввода/вывода на основе poll mode-драйвера IGB UIO на сервере с несколькими 40-гигабитными карточками. По очевидным причинам IGB UIO или KNI на docker-ах не запустить, а иначе сложно выжать соответствующую производительность


А не-highload приложения, не столь критичные к ресурсам, можно запускать и на виртуалках, или что еще лучше — в serverless-облаке.

Можно ли использовать Redux на сервере?

+4
Если вы пишете серверные приложения в среде Node.js, взгляните на wolkenkit. Этот фреймворк, среди того, что удалось обнаружить в данной сфере предоставляет разработчику один из самых простых интерфейсов для реализации шаблонов CQRS и Event Sourcing

Только при этом wolkenkit, к сожалению, требователен к инструментам — как минимум, придется docker устанавливать, что к примеру под windows — сомнительное занятие


Существуют более легковесные CQRS+ES фреймворки на Node.js, не требующие дополнительных инструментов, к примеру, Resolve.JS. Еще и поддержка React Native из коробки

Microsoft разрабатывает браузер на базе Chromium, который будет поставляться по умолчанию вместо Edge

+18
EdgeHTML менее стабилен и быстр, чем Chromium

Можно спорить о разных аспектах, но это утверждение ложное.
Может быть оно и является истинным на рабочей станции с Core i9 и 256 ГБ оперативной памяти.
Но на ноутбуке 2012-ого года выпуска с Win10 и 4GB памяти использовать что-то кроме Edge решительно невозможно — это единственный браузер, который не отжирает все эти 4GB, даже если открыть 100500 вкладок.
Если выключить swap-раздел, то хваленый Хром каждую вторую вкладку аварийно завершает с нехваткой памяти, а Edge летает очень шустро.
Так что если новость правда — то это колоссальная потеря для стареньких маломощных ноутбуков и нетбуков — тогда их будет только на мусорку отнести.
Конечно, можно снести винду и поставить Lununtu или Xubuntu с облегченным рабочим столом, но это уже совсем другая история.

Интересная задачка на С

+5

Интересное решение, хотя при использовании C extensions (gcc), можно обойтись без функторов вообще — за счет Label Values. Эта функциональность применяется в низкоуровневых модулях высоконагруженных приложений для организации переходов без ветвления, хотя в зависимости от ситуации может быть оптимальнее использовать if в сочетании с builtin_expect для мануальной настройки branch prediction. Вместо отрицания, возможно, применить более подходящий оптимальный intrinsic


int main() {
  int n = 100500;
  void* refs [] = { &&work, &&done };
  work:
    printf("%d ", n);
    n--;
    goto *refs[!n];
  done:
  return 0;
}

Настройка системы WEB — тестирования на основе headless chromium-browser, chromedriver, nightwatch и node.js на Ubuntu

+2

Безусловно, у всех решений свои плюсы и минусы. В принципе, в современном web-е код модифицируется и так немало раз — babel для async/await и генераторов, bundle-ирование в webpack-е, polyfills и так далее — так что в принципе в еще одном преобразовании особо ничего страшного нет.
Сам hammerhead выглядит довольно надежным — мне удалось найти, как выйти из песочницы, но маловероятно, что в обычном web-приложении такое бывает. Зато пользователи SmartTV и прочих необычных браузеров счастливы :)

Настройка системы WEB — тестирования на основе headless chromium-browser, chromedriver, nightwatch и node.js на Ubuntu

+11

Конечно, Nightwatch в целом неплох, но имеет свои недостатки: устаревший синтаксис с callback-цепочками вместо Promises и async/await, и требования наличия webdriver-а к браузеру — как тестировать на смартфоне или смарт-ТВ? Если Вы занимаетесь функциональным тестированием web-сфере и следите за развитием технологий, рекоммендую ознакомиться с этой статьей, и в частности, присмотреться к решениям от TestCafe — тоже на Node.js, но поудобнее и решающий вопрос с любыми девайсами. Можно вообще SauseLabs прикрутить, чтобы тестировать на всевозможных устройствах скопом.

Глупый JS. Делаем фильтры «по красоте»

+1
react-scripts, или уж тем более с resolve-scripts
Что здесь сложного?

Тем что надо отдельно настраивать конфигурируемую head-секцию с внешнием сценарием через React Helmet ?


Тем что из-за синхронной загрузки скриптов увеличивается время загрузки страницы? А если CDN этого внешнего сервиса отвалится, то и web-приложение тоже? А также тем, что начинаются проблемы с offline-режимом, и к примеру, невозможно зарегистрировать service worken для удаленного СDN: https://filipbech.github.io/2017/02/service-worker-and-caching-from-other-origins ?


Тем что это может уже не сработать, если браузер поддержал ES modules-подобную загрузку, которая уже асинхронная, и если предполагался polyfill уровня ES8+, то он мог не успеть загрузиться?


Тем что нельзя установить жесткую CSP-политику для безопасности web-приложения, к примеру, отключающую eval для внешних сценариев или аналогичную?


В общем, можно дискутировать бесконечно. На каждое решение — свой потребитель. Как Вам уже не раз говорилось ранее — нравится — пользуйтесь на здоровье.

Глупый JS. Делаем фильтры «по красоте»

+1
о динамической генерации полифиллов полезно знать

Безусловно. А еще лучше иметь заранее подготовленные bundle-ы для версия браузеров. Более того, есть решения, которые позволяет также включать сразу ES Modules для современных клинетских агентов, не выполняя дифференциации генерируемой HTML-страницы, а делая это исходя из feature discovery: статьи как настроить раз и два.


Promise и fetch не завезли в IE11

Разумеется. Для fetch-а в исходном коде вообще скорее всего не будет прямого вызова, а изоморфный импорт import fetch from 'isomorphic-fetch'.


Это все довольно очевидные вещи. Весь тред собственно о том, если не использовать ES8+, то выбрасывание многострадального и довольно бесполезного includes позволяет сэкономить тонну работы по deployment-у.


Если вдруг ваше приложение использует ES8+, то и говорить не о чем. Собственно, как Вы сами частично и признаете:


includes сам по себе не очень хороший пример

А весь тред только об includes и есть.

Глупый JS. Делаем фильтры «по красоте»

+8
сервис polyfill.io

Сторонний сервис, который судя по обзору документации и единственному стороннему устаревшему пакету для bundle-ирования, не стыкуется с концепцией упаковки и доставки кода на клиент, не говоря уже о chunk splitting, feature detecting-based bundles, HMR и тому подобное.


Как это использовать с react-scripts, или уж тем более с resolve-scripts, с изоморфным кодом data layer-а, и чтобы при этом оставалась поддержка требуемых клиентских агентов без избычного кода — совершенно неясно, и вероятно, вообще невозможно.


Если Вы где-то используете и для Ваших задач подходит — на здоровье, никто не против. В серьезных же проектах лучше отказаться от одной малополезной функции, ради упрощения и стабилицаии продукта.
Посмотрите на тот же React (includes vs indexOf) — на клиентской стороне ни одного includes, та парочка что есть — это серверный task runner.


Разумеется, на node.js в НЕ-изоморфном окружении можно использовать что угодно, хоть stage-0 со всякими флагами. На клиенте или изоморфном коде следует подходить аккуратнее.

Глупый JS. Делаем фильтры «по красоте»

+2
Подключили скрипт на страницу

Какой скрипт, на какую страницу. о чем Вы вообще? Как у Вас организован deployment, bundle-ирование и доставка кода на клиент?


Если Вы делаете transpile-инг на серверной стороне, то и все необходимые polyfills надо интегрировать сразу, чтобы сборщик зависимостей исключил дубликаты. Если не делаете — то код просто сломается на старых клиентских агентах из-за синтаксических ошибок, тогда и polyfills вообще не понадобится уже — и так страница не откроется.


Получается, что Вы предлагаете разрабатывать на синтаксисе ES5, но с функциями из ES7? Смысла мало, но если в Вашем проекте Вам там удобно — кто ж запретит, юзайте на здоровье


Вы точно разбираетесь, чем полифилл отличается от библиотеки?

Ничем не отличаются, что одно package, что другое package. Правда обычно polyfill package не является прямой prod-зависимостью других пакетов, а добавляется явно во входной точке конфигурации того же webpack-а или другого bundler-а, если Вам угодно.


Однако в таком случае встречный вопрос — regenerator-runtime это в Вашей терминологии polyfill или абстрактный library?


Его надо явно import-ить (Как видимо "библиотека" в Вашей терминологии), но при этом он модифицирует глобальное пространство процесса (Как видимо "полифилл" в вашей терминологии)


Впрочем, позволю резюмировать. Каждый deploy-ит как хочет, выбирает клиентские агенты, какие поддерживать, а какие нет, решает, оптимизировать производительность или сделать попроще, забив на это. Для каждого случая это можно решать отдельно. Однако если вспомнить, что все это ради одной функции, то лучше на нее забить.

Глупый JS. Делаем фильтры «по красоте»

+1
Сервер читает userAgent

Производить проверку браузера, исходя из строки агента, не рекоммендуется — современным методом является feature discovery — к примеру, вариант для ES6, но это даже не столь существенно


Самое главное — такое решение плохо сочетается с самой идеей bundle-ирование клиентского кода. Конечно, можно загрузить предложенную библиотеку как статику и добавить в externals, но тогда bundle все равно или будет целиком содержать излишний исходный код, или требовать условной сборки, зависимой от клиентского агента.

Глупый JS. Делаем фильтры «по красоте»

+1

Или babel-polyfill, если зависимости собираются webpack-ом и поставляются на клиент в виде bundle-а? Окей, но скорее всего нет, поскольку есть один важный аспект — вопросы оптимизации, включая объем трафика для bundle-а и вычислительные ресурсы для выполнения на клиенте.


Применение единого bundle-а со всеми polyfills и transpile-кодом на современных браузерах приводит к существенному оверхэду, поэтому рекоммендуется разворачивать отдельный bundle для современных клиентских агентов (раз, два).


Условно все относительно-современные браузеры поддеривают ES6, и для них может приозводиться доставка непосредственно ES6-кода. Для старых браузеров можно применять polyfills, transpile-ить код, или вообще просить пользователя обновиться для просмотра ресурса — это вопрос отдельный.


Теперь если взять все браузеры с ES6, то часть из них, включая IE11, Smart TV, Tizen, не поддерживают ES7, но отлично понимают ES6. Если вспомнить соответствующую спецификацию комитета TC39, то 6-ая версия включает всего два изменения — оператор возведения в степень и includes. ВСЁ.


Исходя из этого вопрос — имеет ли смысл заморачиваться с отдельным bundle-ом с polyfills и transpile-ингом с уровня ES7 до ES6 (*), по сути ради одной единственной функции, которая чуть менее, чем на 100% — всего лишь синтаксический сахар для arr.indexOf(value) > 0? Настраивать развертывание, кеширование отдельного bundle-а, отдельные функциональные тесты на каком-нибудь SauseLabs, ради одной малополезной функции?


(*) При условии, что такое легко реализовать; babel по умолчанию, вроде бы, так не умеет, так что задача приобретает еще один виток сложности

Глупый JS. Делаем фильтры «по красоте»

+1
Если говорить об ES6 то почему бы не использовать Array.prototype.includes вместо вот этого

Безотносительно ко всей статье, но именно includes в некоторым смысле вредная штука — способ выкинуть поддержку как минимум IE11 и Samsung TV browser на пустом месте
Если синтаксические конструкции ES7+ легко раз-babel-иваются, а для ES6-функционала polyfills во всех современных браузерах не нужны и по умолчанию их давно уже никто не включает в bundle-ы, то includes — фактически единственное исключение и способ нажить неудобства при deployment-е

Cj — новый язык программирования

Cj — новый язык программирования

+1
А теперь тоже самое для статичных (выделяемых в стеке) фукнций.

Имеются в виду функции, использующие переменные из activation object, то бишь замыкания? Они такие же объекты с похожим жизненным циклом, так что отлавливать и подсчитывать ссылки на объекты из activation object проблем нет.


Еще раз — потенцаильная сложность это функции из host object, типа DOM-модели, но это тоже обходится в transpile-фазе


но компилятор… все еще ждем

Это вопрос к автору статьи, к которому я никакого отношения не имею. Это лишь ответ на вопрос о том, что при должной сноровке поддерживать деструкторы в ES262 не представляется проблемой

Cj — новый язык программирования

0

На платформе node.js решается очень легко — https://www.npmjs.com/package/weak и подобное


Для клиентской стороны немного сложнее, потребуется babel-плагин, осуществляющий обертку объектных сущностей — вроде таких https://www.npmjs.com/package/babel-plugin-source-wrapper или https://gist.github.com/IhostVlad/9310188edbdbc9f62dc3107417cc8fe4


Основная сложность в том, что придется обернуть взаимодействие с native и host-object-функциями, которые также могут хранить внутри себя ссылку на объекты — да, это объемная работа, но вполне реализуемая.


К тому же, большинство обертки и преобразования для DOM-модели уже решено здесь: https://github.com/DevExpress/testcafe-hammerhead/tree/master/src/processing

Cj — новый язык программирования

0

Сама по себе идея разрабатывать части web-приложения на C/C++ далеко не новая — другое дело, какой результат вы хотите получить от такого подхода? Возможно, вам будет интересно ознакомиться с WASM: http://webassembly.org/docs/c-and-c++/

Selenium и Node.js: пишем надёжные браузерные тесты

+1

Да, без качественных автоматических функциональных тестов хорошее сложное web-приложение не сделать.
Однако у оригинального Selenuim-а два недостатка: отличие языка тестов от языка клиентского кода и необходимость наличия webdriver-а для целевого браузера. И если первый недостаток давно решен в библиотеках Webdriver.io, Nightwatch, и тому подобное, позволяя писать на том же ECMA-262 ver 6+, то со вторым недостатком никаких подвижек нет.
В частности, учитывая обилие устройств, как проверить работоспособность на всевозможных смартфонах, Smart TV и тому подобное. В этом плане TestCafe нет равных, или связке TestCafe + SauceLabs — на случай если у вас нет фермы живых устройств для прогона тестов

Пятничный JS: reqyire.js и очепятко-ориентированное программирование

0

Да, наверное можно получше сформулировать. Форма и значения в том или ином объекте могут стать известны только в runtime-фазе, например, когда прочли request body в HTTP-запросе и инстанцировали из него объект посредством JSON.parse — по сути преобразование из произвольного string в произвольный plain object.


Каждое из полей может быть null, undefined или чем угодно, но эта станет известно только в фазе выполнения. Есть такая штука как tcomb — это да, может помочь.


Опять-таки самая ближайшая аналогия из строго-типизированного языка, C#, это по типу:


dynamic excel = Interop.create("Excel.Workbook");
dynamic book = excel.Workbook[0];
book.Activate();

Пятничный JS: reqyire.js и очепятко-ориентированное программирование

0

Одно из самых распространенных заблуждений состоит в том, что статическая типазация, или новомодные обертки для ее эмуляции в виде ES-Flow, могут помочь побороть ошибку undefined is not a function, но на деле это невозможно сделать в статическом анализе.


Аналогичный примерчик на C#. В общем-то проблема в Nullable объектах, а не то, что часто принято приводить в качестве аргумента


// One
MyClass obj = null;
obj.someMethod();

// Two
delegate void SomeFunc(int x);
SomeFunc dlg = cond ? obj.someMethod : null
dlg(10);

Пятничный JS: reqyire.js и очепятко-ориентированное программирование

0

Теоретически можно заимплементить плагин для prettier-а, но это решает очень узкую задачу — выявление опечаток в именах подключаемых модулей, заданных в виде строковых констант. А если require(vasya${petya}) ?


Многие остальные вещи становятся известными только в runtime-фазе, так что ни EsLint, ни Flow тут не помощники. Поэтому если уж заморачиваться, то нужна более тяжелая артиллерия.


И еще раз важная заметочка: подобная задача вполне имеет место в динамическом анализе кода и функциональном тестировании. Есть как минимум:



Задачи ооочень нетривиальные в общем случае. К примеру, довольно проблемно перехватить сгенерированный script-блок из DOM-манипуляций, чтобы выполнить предварительную обертку.

Пятничный JS: reqyire.js и очепятко-ориентированное программирование

+4
почему в JS нельзя получить напрямую доступ к контексту выполнения

Раньше можно было даже программно доступ получить через parent, потом убрали видимо из соображений чистого кода и безопасности/sandboxing-а. Можно почитать тут подробнее: http://whereswalden.com/2010/05/07/spidermonkey-change-du-jour-the-special-__parent__-property-has-been-removed/


Сейчас доступ только из отладчика по скрытому свойству [[Scope]]. Подозреваю, что для node.js можно и сейчас получить доступ через V8 natives: https://www.npmjs.com/package/v8-natives, только надо с флажком будет запускать процесс


Правда, все ошибки перехватить всё равно не удастся

Если перехватить сами вызовы, которые могут генерировать новый код динамически тем или иным образом, начиная от new Function и заканчивая манипуляциями с DOM Node и создания новых script-секций, то вполне возможно
Подобная техника, правда не для шутки, а функционального тестирования, применяется в TestCafe: https://github.com/DevExpress/testcafe-hammerhead

Пятничный JS: reqyire.js и очепятко-ориентированное программирование

+5

Очень неплохо! Правда есть и недостатки, например имена лексических переменных с очепятками никак не перехватываются, да и синтактические ошибки по-прежнему актуальны. Так что нужно сделать babel-плагин, который будет выполнять пред-обработку и учитывать опечатки во всех сущностях.

Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов

+14
Virtual DOM в React является медленным и неточным

В движке Fiber проблема производительности уже неактуальна


React требует сложного асинхронного программирования при общении с сервером

Напротив, в связке с Redux весь код бизнес-логики на клиенте может быть сведен в единое место, представляемое одним или несколькими комбинированными reducer-ами. Продолжительные по времени действия легко описать в sagas, а еще лучше реализовать всю архитектуру через events — в таком случае явные асинхронные вызовы вообще не нужны


Даже используя propType React сможет найти ошибки только во время работы программы, а не во время компиляции.

Если нужна статическая проверка, можно использовать Flow


Поддерживает ли Binding.scala серверный rendering?

Доставляем себе в офис чашку горячего кофе одной командой консоли с помощью TestCafe

0
И второй вопрос – а эта штука поможет в этом?

Да, с принципом работы TestCafe, Вы можете хоть с утюга запускать функциональные тесты, если там есть браузер с поддержкой ES-262 и выходом в интернет

Доставляем себе в офис чашку горячего кофе одной командой консоли с помощью TestCafe

+5
асинхронный node.js и бороться с ним с помощью await'ов

А причем здесь, собственно, node.js? Это же клиентский EcmaScript-код, который с версии ES2017 вообще будет поддерживать это нативно. Ваше web-приложение асинхронно само по себе, а это инструмент для организации цепочки действий


общий уровень "велосипедизма".… повсеместно используемых setUp/tearDown, тут beforeEach/afterEach

В современном web-е это принятая терминология, смотрите Ava, Jest, Mocha и так далее.


Короче, что люди не делают, только бы не брать selenium

Короче, что люди не делают, только бы не разрабатывать на C++; придумали всякие интерпретаторы, динамические типизации и другие синтаксические сахара.

Доставляем себе в офис чашку горячего кофе одной командой консоли с помощью TestCafe

+1
Под капотом, вероятнее всего, всё тот же вебдрайвер

Нет, там действительно совершенно иной принцип, со своими достоинствами и недостатками. Матчасть можно почитать в моей статье на эту тему, там же сравнение этих тестовых фреймворков


Если смириться с JS синтаксисом

Выбор языка это конечно вкусовщина, но исторически сложилось, что все современные браузеры работают на ES-262, а реализовывать функциональный тест на том же языке, что и тестируемое приложение — IMHO довольно удобно

Доставляем себе в офис чашку горячего кофе одной командой консоли с помощью TestCafe

+3

Весь вопрос в том, какую технологию вы используете на серверной части разрабатываемого/поддерживаемого web-приложения. Если node.js, то очевидно в случае TestCafe не надо устанавливать еще один инструмент, если JSP или что-то подобное, то выбор в сторону семейства Selenuim (Webdriver, nightwatch, etc).
Если PHP, Perl, Ruby или что-то еще, то вопрос с такой стороны рассмотрения открытый, но ES6/7 это все-таки тот язык, который исполняется в браузере, и писать функциональный тест писать на нем IMHO значительно удобнее, чем на Java.

Вот тебе, бабушка, и неймспейсы

+4

Безусловно, описанная в статье ситуация с XHTML довольно проблематичная, но скорее в идеологическом плане, поскольку технически те или иные задачи все-таки можно решить. Дело в том, что исторически направления XHTML и CSS selectors развивались параллельно, о чем как минимум свидетельствует наличие двух конкурентных языков для выбора элементов документа — XPath и CSS selector, при этом оба успешно применяются в сфере автоматизации web-приложений и функциональном тестировании, в том же Nightwatch-е к примеру.
Далее по техническим вопросам. Во-первых, навигацию по XHTML лучше реализовывать посредством XPath, который изначально как раз предназначен для XML-документов, и поддерживается посредством функции document.evaluate(), по крайней мере в браузерах, приведенных автором статьи в последней таблице. Для IE старых версий тоже нет проблем, можно использовать объект new ActiveXObject("Msxml2.DOMDocument"), за-map-енный на текущее DOM-дерево, пример решения можно взять здесь https://sourceforge.net/projects/html-xpath/
Это имеет свой смысл, поскольку в общем случае CSS и уж тем более CSS selectors являются чужеродными для произвольных XML-элементов, которые не обязаны ни поддерживать стили, ни иметь какой-то внешний вид для отображения — который должен по-хорошему определяться через XSLT-преобразование (Или, если интересует поддержка IE старых версий, через Element Behaviors, во времена которых как раз задумывался XHTML с определением пользовательского поведения элементов — https://msdn.microsoft.com/en-us/library/ms531426(v=vs.85).aspx).
Во-вторых, с учетом современных тенденций в web-приложениях, включающую предварительное преобразование исходного кода в связке webpack + babel, можно сделать свою реализацию для resolve-а и transform-а исходного XHTML-кода, по аналогии с тем же JSX, который в итоге преобразования будет предоставлять набор элементов с некоторыми идентификаторами и классами, а исходный код будет выглядеть так, как задумал автор — с пространствами имен XHTML.
Резюмируя по исходной задаче, решения можно добиться без polyfills, правда потребуется две версии dist-клиентского сценария — для современных браузеров через document.evaluate(), и если захотите поддержку IE старых версий — то через Element Behaviors API, которое кстати поддерживает о-о-о-очень широкую функциональность.

Функциональное тестирование современных web-приложений

+1
К тому же под Nightwatch есть очень и очень много разнообразных примочек и фишек

Для TestCafe вы просто пишите ES6-код, и можете использовать множество различных библиотек в import-е под свои надобности, причем в selenium-е какие-то сторонние вещи интегрировать в код теста придется через эту функцию, то в TestCafe это обычный код — в таком смысле, возможности по интеграции куда шире.


Асинхронные комманды выполняются с помощью функции .executeAsync()

Безусловно! Однако этот функционал предоставляет значительно большие возможности. Да и promise / async-based стиль выглядит более читаемым, хотя наверное это уже дело вкуса.

Функциональное тестирование современных web-приложений

0

В обоих фреймворках есть довольно легкие в использовании и в то же время конфигурируемые инструменты для ожидания наличия/отсутствия/видимости/невидимости заданного DOM-элемента, в Nightwatch эта функция и ей подобные, в TestCafe есть более богатый набор, и вообще можно использовать кастомный селектор, проверяющий сложное условие — к примеру, наличие заданных relative-элементов и другой программной логики, которую можно написать в клиентском JS-коде
Насчет iframe-ов, есть иснтументы для переключения активного контекста окна, это есть и в Nightwatch, и TestCafe ( Здесь и здесь )

Функциональное тестирование современных web-приложений

+1

@Ayzatqa, спасибо! Насчет вопроса — имеется в виду <input type="file" />? Если да, то в TestCafe для этого есть уже готовое решение, оно проверено работает
Для nightwatchjsЮ во всей видимости, можно реализовать через конструкцию .setValue('input#fileUpload', require('path').resolve(__dirname + '/testfile.txt')), как предлагают здесь, но работоспособность решения гарантировать не могу