Комментарии 23
Узнаю старый добрый хабр. Сразу скепсис и мокание в дерьмо. Как же я по этому соскучился :)
Согласен с претензией насчет абстракции. Есть такая проблема. Но как мне кажется проблема написания и поддержки тестов на "чистом" SeleniumWebDriverJS (или его аналогах) стоит гораздо острее. Опять таки, легко запутаться в промисах или слишком углубиться в техническую имплементацию потеряв суть.
Опять таки, легко запутаться в промисах или слишком углубиться в техническую имплементацию потеряв суть.
Несогласен, т.к. это зависит от архитектуры приложения и качества кода.
Приемочные тесты мало зависят от архитектуры приложения.
Так как мы тестируем приложение снаружи, мы рассматриваем его как черный ящик и можем обращаться по нему только через публичные интерфейсы. Да, при плохой архитектуре и отсутствии юнит тестов, кол-во приемочных непропорционально возрастет, но на сам принцип написания тестов это повлияет мало.
мокание в дерьмо
Это какая-то новая JS либа для создания mocks and stubs?
Казалось бы, что можно сделать, чтобы тест ещё более читабельным. Давайте напишем его по-русски!
Не прошло и двух месяцев с момента последней попытки перевести JS на русский, как вот еще одна
Шутки-шутками, но фича с переводами появилась после пул реквеста одного разработчика из Сан Пауло, который разрабатывал правительственную систему и соответственно хотел писать тесты на португальском. Я в португальском ничего не понял, потому добавил перевод на русский. Кому надо — тот воспользуется, кому не надо — посмеется.
И если в мире фронтенд фреймворков уже наметились явные фавориты: AngularJS, React, Vue, Ember
Никак не могу понять, почему такое большое количество людей называет ReactJS фреймворком и ставит его в один ряд с AngularJS и EmberJS....
Если бы я убрал из перечня React, незамедлительно появился бы комментарий: "а где в списке React."
Какая, блин, разница в контексте этой статьи?
Что есть фреймворк? Это структура + более высокоуровневая абстракция. React+Redux+смасса библиотек, реализующих нужный функционал это дают. Чем в финальной «сборке» всех нужных составляющих это отличается от какого-нибудь Ember? ИМХО только тем, что составляющие ты выбрал сам.
Достоинства React — ты можешь «выбрать компоненты» для своего «идаельного» фреймворка. Минус — нет четких парадигм. Два проекта на React могут сильно отличаться. Хотя в сухом итоге мы получим всё тот же фреймворк, способный делать ровно столько же, сколько Ember/Angular/etc., но с необходимостью отслеживать зависимости и удостоверяться, что Казуал Карл не забил на поддержку конкретной библиотеки, которая есть часть проекта.
Что есть фреймворк? Это структура + более высокоуровневая абстракция.
Уточнение: структура, которую сложно игнорировать + более высокоуровневая абстракция над инфраструктурой, которую (абстракцию) обычно нет смысла игнорировать + (опционально) набор готовых компонентов для задач типа валидации, которые часто можно игнорировать. Собственно хороший фреймворк отличается от плохого двумя вещами, по-моему: сколько инфраструктурного и прочего не относящегося к конкретной задаче кода придётся писать для её решения и насколько легко заменить какой-то компонент фреймворка сторонним или самописным, если встроенный чем-то не устраивает, не теряя поддержки по остальным компонентам.
Минус — нет четких парадигм.
Это сомнительный минус. Скажем, в сейчас активно разрабатываемых приложениях мы отказались от "стандартного" однонаправленного потока данных с единым хранилищем состояния на плоских JS-объектов на базе Flux/Redux, сочтя его оверинжинирингом для наших задач. Если бы Redux был неотъемлемой частью React, то, вероятно, стали бы смотреть в сторону чего-то другого.
способный делать ровно столько же, сколько Ember/Angular/etc.
Обычно не столько же, а значительно меньше. При использовании "монолитных" фреймворках часто вся их функциональность не востребована, и даже если умный сборщик в конечный билд её включать не будет, то всё равно во время разработки она будет где-то рядом (например в node_modules) и хорошо если не будет ограничивать свободу своим наличием.
сколько инфраструктурного и прочего не относящегося к конкретной задаче кода придётся писать для её решения и насколько легко заменить какой-то компонент фреймворка сторонним или самописным, если встроенный чем-то не устраивает, не теряя поддержки по остальным компонентам.
Вот тут не согласен — чем более низкоуровневое решение, тем проще обойти фреймворк. Пока вы будете в парадигме какого-нибудь Ember мыслить — обойти его изкаробочные части сложно, как только вы отказываетесь от Ember Object/Data и начинаете просто писать решения для ES6 — все становится просто.
Это сомнительный минус. Скажем, в сейчас активно разрабатываемых приложениях мы отказались от «стандартного» однонаправленного потока данных с единым хранилищем состояния на плоских JS-объектов на базе Flux/Redux, сочтя его оверинжинирингом для наших задач. Если бы Redux был неотъемлемой частью React, то, вероятно, стали бы смотреть в сторону чего-то другого.
Всё просто — если я знаю Ember, то влиться в любобй проект на нём будет легко. Если я знаю React — то не факт, вы сами привели пример. А для бизнеса интересны решения, которые потом будет в свостоянии кто-то поддерживать.
Не сочитите за троллинг, вопрос к React-специалисту — почему вы не воспользовались еще до React каким-нибудь handlebars или чем-то подобным? Что реально отличает React от остальных настолько? Я просто не понимаю хайпа вокруг него…
Обычно не столько же, а значительно меньше. При использовании «монолитных» фреймворках часто вся их функциональность не востребована, и даже если умный сборщик в конечный билд её включать не будет, то всё равно во время разработки она будет где-то рядом (например в node_modules) и хорошо если не будет ограничивать свободу своим наличием.
На счет нахождения рядом — согласен, но вам не все ли равно? Я получал из Ember сборку равную проекту на React (последний даже был тяжелее на пару десятков кб) — сложностей не возникло. А про ограничения — как? Я такого еще не видел ни разу.
Что реально отличает React от остальных настолько?
React предоставляет полноценный механизм View (в терминах MVC) и даже ViewModel (setState), хотя часто его не используют, предпочитая Redux, MobX или что-то другое, в том числе своё, обеспечивая автоматический ререндеринг при изменении свойств. Handlebars и прочие — лишь шаблонизаторы, не решающие когда нужно произвести повторный рендеринг.
- React предоставляет в виде JSX расширенный вариант JavaScript для реализации логики отображения, включая шаблонизацию, в то время как классические шаблонизаторы либо урезанный, либо вообще свой, функционально так же урезанный.
В общем и в целом, React — это дальнейшее развитие классических шаблонизаторов, значительно уменьшающее количество "чёрной работы", необходимой для своевременного отображения изменений состояния приложения, позволяя разработчику сосредоточиться на логике приложения, не думая о том, когда эти изменения отображать.
Спасибо, действительно важный момент.
1) описание ошибок:
-- FAILURES:
1) Testing Begins: ANI testing:
expected web page to include "bogus text that is not there"
+ expected - actual
-Home
-About
-Portfolio
-Services
-My Account
-Contact
-bring your site to life
-content rich
-graphically interesting
-search engine optimized
---( 49 lines more )---
+bogus text that is not there
Scenario Steps:
- I.see("bogus text that is not there") at Test.<anonymous> (examples/absolutenet_test.js:8:5)
- I.grabTitle() at Test.<anonymous> (examples/absolutenet_test.js:6:23)
- I.amOnPage("http://www.absolutenet.com/") at Test.<anonymous> (examples/absolutenet_test.js:5:5)
Run with --verbose flag to see NodeJS stacktrace
2) GitHub: register:
Field q not found by name|text|CSS|XPath
Scenario Steps:
- Within .js-signup-form: I.click("button") at examples/github_test.js:31:7
- Within .js-signup-form: I.fillField("q", "aaa") at examples/github_test.js:30:7
- Within .js-signup-form: I.fillField("user[password]", "user@user.com") at examples/github_test.js:29:7
- Within .js-signup-form: I.fillField("user[email]", "user@user.com") at examples/github_test.js:28:7
- Within .js-signup-form: I.fillField("user[login]", "User") at examples/github_test.js:27:7
- I.seeInCurrentUrl("/explore") at Test.<anonymous> (examples/github_test.js:35:5)
- I.click("Explore") at Test.<anonymous> (examples/github_test.js:34:5)
- I.see("There were problems creating your account.") at Test.<anonymous> (examples/github_test.js:33:5)
2) при запуске с флагом verbose покажет полный стектрейс + все состояния глобального промиса, чтобы можно было проследить какие события действительно выполнились, а какие — нет. Помогает разбирать кейсы, когда случайно забыл вернуть промис и он потерялся.
3) интерактивная консоль: возможность в любой момент остановить выполнение и попробовать запускать команды из консоли. Например, проверять доступность элемента по селектору.
Да, асинхронность это круто, но в контексте приемочного end-2-end тестирования асинхронность это вечная проблема. Тесты должны иметь линейный вид, посоледовательности команд: я открываю страницу, я кликаю кнопку, я хочу увидеть нужный мне текст.
Читается как
Я не умею в асинхронность и потому вместо того, чтобы освоить её, напишу свой велосипед.
А ведь всего-то и нужно, если уж совсем тяжко:
Scenario('search github', (I) => {
await I.amOnPage('https://github.com/search');
await I.fillField('Search GitHub', 'CodeceptJS');
await I.pressKey('Enter');
await I.see('Codeception/CodeceptJS', 'a');
});
CodeceptJS — современные end2end тесты для NodeJS