Судя по перовому тегу в webdrivercss, он вышел почти одновременно с gemini. Эксклуды действительно у него крутые, но и мы умеем пару вещей, которые он пока не умеет:
— позволяем задать несколько элементов в одном тесте (webdrivercss, насколько я понял, умеет либо снимать всю страницу, либо один элемент, либо заданный координатами прямоугольник)
— учитываем outline и box-shadow при снятии скриншота.
— считаем coverage
Да, все именно так. Ну и когда сознательно меняете верстку надо тоже удостоверится, что поменяли только то, что хотели (просмотреть diff в тестах, например) и потом запустить gather повторно.
Мы старались сохранить преемственность с обычными тестовыми фреймворками, там где инструмент работает также, как и они и сознательно делали интерфейс другим там, где gemini работает по другому. ИМХО, получить то что называется и вызывается также, как ты привык, но работает по другому было бы менее приятно.
Из общих черт c юнит-тстовыми библиотеками: У нас также есть именованные тест-сьюты, которые выстраиваются в иерархию, есть хуки before и after, есть общий контекст между всеми тестами в сьюте, как у mocha.
Отличия же в том, что нашему сьюту от программиста требуется вручную задать гораздо больше чем имя: как минимум нужна область скриншотов и URL. И это нужно для абсолютно всех тестов, поэтому требовать делать это в опциональном методе before/beforeEach было бы как-то неправильно.
Второе отличие в том, что наши 'capture' всегда выполняются последовательно и каждый последующий спокойно может зависеть от предыдущего (к в примере из статьи с кнопкой). Для традицонных тестов это не всегда так и тесты там подразумеваются независимыми, поэтому мы решили объявлять их немного по другому.
Ну и еще одно отличие – отсутствие assert проще всего объяснить. Assert у нас для любого теста всегда один: совпадение текущей и сохраненной картинки и писать его явно нет нужды.
Сейчас это можно сделать комбинацией из действий executeJS() и wait(). WebDriver в принципе позволяет сделать более умный асинхронный execute, эта возможность просто не проброшена в gemini. Я создал тикет об этом (https://github.com/bem/gemini/issues/66). В ближайшее время планируем пробросить недостающие команды WebDriver, туда попадет и эта.
Сейчас программист.
Возможно, попробовал податься в геймдизайнеры — для любительских проектов этим занимался.
Из не связанного с IT — недавно stop motion анимацией увлекся, было б интересно джуниором в какую-нибудь студию попасть.
— позволяем задать несколько элементов в одном тесте (webdrivercss, насколько я понял, умеет либо снимать всю страницу, либо один элемент, либо заданный координатами прямоугольник)
— учитываем outline и box-shadow при снятии скриншота.
— считаем coverage
Из общих черт c юнит-тстовыми библиотеками: У нас также есть именованные тест-сьюты, которые выстраиваются в иерархию, есть хуки before и after, есть общий контекст между всеми тестами в сьюте, как у mocha.
Отличия же в том, что нашему сьюту от программиста требуется вручную задать гораздо больше чем имя: как минимум нужна область скриншотов и URL. И это нужно для абсолютно всех тестов, поэтому требовать делать это в опциональном методе before/beforeEach было бы как-то неправильно.
Второе отличие в том, что наши 'capture' всегда выполняются последовательно и каждый последующий спокойно может зависеть от предыдущего (к в примере из статьи с кнопкой). Для традицонных тестов это не всегда так и тесты там подразумеваются независимыми, поэтому мы решили объявлять их немного по другому.
Ну и еще одно отличие – отсутствие assert проще всего объяснить. Assert у нас для любого теста всегда один: совпадение текущей и сохраненной картинки и писать его явно нет нужды.
Возможно, попробовал податься в геймдизайнеры — для любительских проектов этим занимался.
Из не связанного с IT — недавно stop motion анимацией увлекся, было б интересно джуниором в какую-нибудь студию попасть.
Может сами сначала поймем node.js перед тем как кого-то учить?
Posted 3 years ago,