А причем здесь, собственно, node.js?
Да не суть, вопрос в том, что тест – это всегда цепочка последовательно выполняемых действий. Асинхронность в коде теста только мешает.
В современном web-е это принятая терминология
Ок, не слежу за миром тестирования фронта, упустил.
Сомнительное удовольствие для синхронного кода (а функциональные тесты это только последовательное выполнение шагов) использовать асинхронный node.js и бороться с ним с помощью await'ов.
Из минусов – собственные селекторы, представляющие собой смесь jquery и xpath, ни слова про Page Object'ы в документации (непонятно, сколько нужно костылять, чтобы их тут вообще прикрутить) и вообще общий уровень "велосипедизма". Например, вместо повсеместно используемых setUp/tearDown, тут beforeEach/afterEach.
Короче, что люди не делают, только бы не брать selenium с его JsonWire протоколом, биндинги для которого есть для всех языков и который де-факто стандарт в автоматизации тестирования веба и не только.
Тут просто теплое с мягким. Естественно, стейтфул быстрее стейтлесс, т.к. не надо каждый раз поднимать все окружение (читать конфиг, строить роуты, коннектиться к базам и т.д.) для обработки одного запроса, но nginx тут ни при чем.
Того, что мы не видим и не лезем в код приложений. Вопрос тут скорее политический, но для компании важный.
И вы пишете на …?
В основном PHP. Один тестовый проект с одной инфраструктурой под все платформы (api, веб, ios, android) с минимальными изменениями.
Да не сказал бы, что прям критически низкая, у нас сетевые задержки иногда больше. На ios используем instruments-without-delay, чтобы убрать секундную задержку, воткнутую Эпплом.
Преимущества в тестировании black box, у нас это был основной критерий при выборе инструмента. Также, работа через wd протокол позволяет писать тесты на любом языке.
Espresso и XCUITest мы используем для более низкоуровневых тестов, а-ля такие функциональные юниты.
Вот тут главное не забывать, что стопроцентное покрытие кода тестами в реальном проекте недостижимо за приемлемое время, да к тому же само по себе ничего не гарантирует с точки зрения работоспособности программы.
Не стремящееся к бесконечности, а ровно бесконечность. Но на то и существуют классы эквивалентности, чтобы сократить число подобных вариантов к минимуму.
Только не стоит забывать, что после "Значит они работают над архитектурой и качеством кода" есть ", а не над фичами".
Ну так и у JetBrains есть EAP.
Это почему? У нас WebDriver тесты на PHP и есть все это и куда больше
Ох, как я налажал с форматированнием :(
Дублирую:
Да не суть, вопрос в том, что тест – это всегда цепочка последовательно выполняемых действий. Асинхронность в коде теста только мешает.
Ок, не слежу за миром тестирования фронта, упустил
Серьезно более реалистично? По той же ссылке выше 0.0%. Если имелся ввиду Windows Phone, то там проблем нет
Сомнительное удовольствие для синхронного кода (а функциональные тесты это только последовательное выполнение шагов) использовать асинхронный node.js и бороться с ним с помощью await'ов.
Из минусов – собственные селекторы, представляющие собой смесь jquery и xpath, ни слова про Page Object'ы в документации (непонятно, сколько нужно костылять, чтобы их тут вообще прикрутить) и вообще общий уровень "велосипедизма". Например, вместо повсеместно используемых setUp/tearDown, тут beforeEach/afterEach.
Короче, что люди не делают, только бы не брать selenium с его JsonWire протоколом, биндинги для которого есть для всех языков и который де-факто стандарт в автоматизации тестирования веба и не только.
Сначала socket_shutdown, потом уже socket_close ?
Тут просто теплое с мягким. Естественно, стейтфул быстрее стейтлесс, т.к. не надо каждый раз поднимать все окружение (читать конфиг, строить роуты, коннектиться к базам и т.д.) для обработки одного запроса, но nginx тут ни при чем.
Именно. Иногда боль, да, но мы держимся
Ну так исторически сложилось, да
Вряд ли буду согласен на 100%. Все-таки хочется тестировать реальное приложение с api, а не моки. Мокаем только самое необходимое.
Того, что мы не видим и не лезем в код приложений. Вопрос тут скорее политический, но для компании важный.
В основном PHP. Один тестовый проект с одной инфраструктурой под все платформы (api, веб, ios, android) с минимальными изменениями.
Да не сказал бы, что прям критически низкая, у нас сетевые задержки иногда больше. На ios используем instruments-without-delay, чтобы убрать секундную задержку, воткнутую Эпплом.
Преимущества в тестировании black box, у нас это был основной критерий при выборе инструмента. Также, работа через wd протокол позволяет писать тесты на любом языке.
Espresso и XCUITest мы используем для более низкоуровневых тестов, а-ля такие функциональные юниты.
Вот тут главное не забывать, что стопроцентное покрытие кода тестами в реальном проекте недостижимо за приемлемое время, да к тому же само по себе ничего не гарантирует с точки зрения работоспособности программы.
Не стремящееся к бесконечности, а ровно бесконечность. Но на то и существуют классы эквивалентности, чтобы сократить число подобных вариантов к минимуму.
Ну офигеть, а то мы не знали преимуществ статической типизации.
А ведь вместо написания статей, автор мог бы научится нормально писать юнит-тесты.
Тут еще стоит указать, что Gogs прекрасно работает на Raspberry Pi, а для GitLab'a мне пришлось покупать второй план на DO.
Если быть точнее, то эту возможность сломали при редизайне. В предыдущий дизайн я лично впиливал эту фичу.
Что есть ревью кода? Пулл-реквесты в Гогсе есть
Конечно, любая маковская, например