Лень писать это в соседнюю ветку на 100500 страниц, поэтому понапложу сущности без необходимости
Пара смешных людей рассказывают о том, как все подряд покрывается автоматическими тестами и прочей ерундой, и тесты на GUI пишутся на раз.
И тут у меня как раз возник момент.
Дано: рисуется в браузере график при помощи SVG. График рисуется generic-библиотекой. После того, как он отрисовался, среди прочего, делается следующее:
— берется текст, который будет заголовком графика, title
— берется нарисованый график, chart
— oldY = chart.Y
— chart.Y = chart.Y + title.height
— title.X = chart.X
— title.Y = oldY
— title.height, естественно, зависит от CSS, и, собственно, от того, как это отображается в браузере.
То есть, понятно, что график смещается вниз, и вверху рисуется заголовок.
Проблема 1. Firefox
В Safari и Chrome все правильно. В Firefox title смещается влево примерно на title.width/2.
Вопрос: как это определить автоматическими тестами, без тестирования человеком? Ну, учитывая, что автоматический тест будет использовать те же getWidth[1] и прочее, что и код
Проблема 2. Display: none -> Display: block/inline
Графики отображаются на панели, которая изначально скрыта.
— Если панель изначально раскрыта, то никаких проблем нет.
— Если панель скрыта, а потом раскрывается, то в зависимости от времени загрузки данных в график (среди прочего), те самые getWidth и прочая возвращают неправильные значения, из-за чего chart не смещается вниз, а title отображается в неправильной позиции.
Найдено тоже только при ручном тестировании. Какой автоматический тест это покроет?
здесь вам нужны не юнит-тесты, также из описания непонятна частота появления таких багов.
отловить такие проблемы автоматизированными тестами вполне реально, но требует усилий и каких-либо затрат. самый тупой вариант — через автосравнивалки скриншотов, подход вполне будет работать можно с использованием Sikuli. вопрос в стабильности решений и в цене разработки-поддержки по отношению к тестированию интерфейса руками.
Z>отловить такие проблемы автоматизированными тестами вполне реально, но требует усилий и каких-либо затрат. самый тупой вариант — через автосравнивалки скриншотов,
Ээээ. Сравнение каких скриншотов?
Z>вопрос в стабильности решений и в цене разработки-поддержки по отношению к тестированию интерфейса руками.
Здравствуйте, Mamut, Вы писали:
M>Лень писать это в соседнюю ветку на 100500 страниц, поэтому понапложу сущности без необходимости
Мне кажется вполне очевидным, что любое автоматизированное тестирование обязано тестировать полезную работу, которая от кода ожидается, вне зависимости от гранулярности тестирования (то есть и в тестировании самого мельчайшего модуля мы тестируем, что «при корректных данных на входе получаются корректные данные на выходе», а не что «внутренний цикл выполнится 84 раза»);
тестирование GUI — это, по сути, много разных типов тестирований, но два базовых (и сильно разных типа) — а) как оно выглядит и б) как оно себя ведёт;
тесты «как оно выглядит» раньше были менее важны (ну, грубо говоря в период когда почти любой интерфейс это была статичная «форма», раз и навсегда сляпанная в «дизайнере форм»), теперь всё по-другому, конечно;
естественно, тест «как оно выглядит» в идеале должен тестировать ээээ КАК ОНО ВЫГЛЯДИТ, а не значение внутренней переменной dom.get('blah').children('foo').innerHeight;
↑ естественно, единственный способ корректного тестирования «как оно выглядит» — это снятие и анализ скриншотов; поскольку это алгоритмически сложно (кроме простейшего случая «сравнение скриншота с образцом попиксельно», далеко не всегда уместного) — автоматизированное тестирование интерфейса подменяется либо ручным тестированием, либо тестированием внутреннего состояния объектов интерфейса;
но «алгоритмически сложно» не значит невозможно; потенциальные подходы довольно очевидны, и я подозреваю, что соответствующие инструменты вполне себе есть (я не могу сходу назвать таковых, но я и не искал, though, вот интересный ответ на SO).
Здравствуйте, Гест, Вы писали:
Г> ↑ естественно, единственный способ корректного тестирования «как оно выглядит» — это снятие и анализ скриншотов; поскольку это алгоритмически сложно (кроме простейшего случая «сравнение скриншота с образцом попиксельно», далеко не всегда уместного) — автоматизированное тестирование интерфейса подменяется либо ручным тестированием, либо тестированием внутреннего состояния объектов интерфейса;
Можно сравнивать DOM.
Ну и в общем случае можно провести сначала ручное тестирование, записав все действия и заскриншотив состояние после, а потом при автомтическом тестировании проигрывать действия пользователя и уже реально просто сравнивать скриншоты. В общем случае — так как все браузеры разные, придется пройти по разу для каждого браузера.
Так очень быстро можно отловить ошибки, которые возникнут после очередного обновления <вставьте имя своего любимого браузера>
Здравствуйте, Гест, Вы писали:
Г> Г> любое автоматизированное тестирование обязано тестировать полезную работу, которая от кода ожидается, вне зависимости от гранулярности тестирования (то есть и в тестировании самого мельчайшего модуля мы тестируем, что «при корректных данных на входе получаются корректные данные на выходе», а не что «внутренний цикл выполнится 84 раза»); Г> тестирование GUI — это, по сути, много разных типов тестирований, но два базовых (и сильно разных типа) — а) как оно выглядит и б) как оно себя ведёт; Г>
Правильнее говорить о проблемах с тз конечного потребителя
1. снижается продуктивность (юзер будет быстро уставать и делать невынужденные ошибки)
2. функционал недоступен (юзер не сможет нажать кнопку)
3. результаты некорректны (юзер примет неверное решение, вынужденная ошибка)
4. и тд, например данные юзера повреждаются, безопасность страдает (прямой или непрямой ущерб для юзера)
При этом само решение может быть в трёх случаях совершенно одинаковым, например, правка CSS. Более того, в зависимости от данных юзера 1 2 и 3 могут быть вообще одним и тем же багом с тз девелопера, который воспроизводится по разному. На одних данных результат трудно читать. На других — результаты не видны, на третьих — выглядят как корректные, но такими не являются.
Что бы накидать авто-тест, нужен ни много, ни мало, а эталонный dom/css процессор, который сможет сказать, что де результаты 1 отрендерились корректно и 2 видны должным образом и 3 кликабельны. Без этого можно сказать что "бокс есть, стиль установлен", что означает "есть ли проблема — а хрен его знает"
Что касается автоматизации, то надо учитывать, что затраты на создание авто-тестов много больше любых мануальных тестов, нужно и отладить и всё равно проверить вручную, действительно ли тест зеленый, когда все сильно, и действительно ли тест красный, когда всё плохо и наоборот.
Отсюда ясно, что автотестами покрывать функционал, который еще не устаканился, смысла не сильно много — завтра всё изменится, а тесты придется выбросить и писать новые.
Специфика UI в основном такая, что:
1 требования в большинстве "сделайте шоб всё было сильно, как на картинке, но по другому"
2 зависимость от чужого кода просто адская — svg, dom, css и тд, не говоря о либах
3 особенности os которые не позволяют использовать кое какие аспекты рендеринга
Ну собственно мы уперлись в более точную постановку задачи.
Например, предположим (так как в исходной постановке я этого не увидел, то могу предполагать то что мне удобно), что у нас есть задача прогонки так иногда называемых регресс-тестов (или просто функциональных), т.е. автоматизированы успешно проходящие тесты или тесты, которые когда либо выявляли ошибки, тогда у нас очевидным образом при создании теста могут оказаться скриншоты того как должны выглядеть наши контролы в том или ином состоянии (и возможно скриншоты типичных ошибок рендеринга). Если это так, то при прогоне мы можем делать скриншот (полный экрана, но лучше частичный некоторой области — вплоть до отдельного контрола) и сравнивать его с помощью встроенной функции или функции из внешней библиотеки сперва на ожидаемое значение, если изображения не совпали, то прогонять сравнение на скриншотах типичных ошибок для классификации текущего состояния или помечать ошибку как вновь найденное подозрительное состояние. Я что-то из питоновской либы PIL использовал вроде. C названием Image Grab (!?) и тулу Image Magic.
Sikuli, работающий через распознавание, должен вроде больше возможностей давать для такого рода анализа. Не помню так как давно на него смотрел умеет ли он текст распознавать. В любом случае можно даже подключить простую распознавалку.
Но детальнее говорить о такого рода тестах нужно при более детальной постановке задачи на тестирование и его автоматизацию. Так как порой проще руками прогнать тесты интерфейса.
Вариантов вообще множество на самом деле. Еще можно определять параметры текста и смотреть отобразился ли текст заданной ширины или что контрол отобразился с шириной х, а текст для данного заданного шрифта и его параметров должен быть y, а x<y (ну и позиционирование сюда добавить). Иногда такие баги по косвенным признакам можно отловить (например задание текста в контроле отличается от аналогичных или от состояния контрола в другой момент времени и тогда делать скрин и кидать ворнинг для ручной проверки).
Еще вариант просто делать скрины в заданный момент времени и отдавать потом просматривать глазами на выходе (это первый этап того что описано в самом начале для классификации ошибок).
Зависит от технологий которые используются, от ресурсов и желания. Давно гуём не занимался, потому мог что-то забыть или упустить или не знать о каких-то новинках.
Здравствуйте, Mamut, Вы писали:
M>В Safari и Chrome все правильно. В Firefox title смещается влево примерно на title.width/2.
M>Вопрос: как это определить автоматическими тестами, без тестирования человеком?
Это как раз просто, подобное я делал — делается эталонное изображение (может быть мокап), потом сравнивается с тем, что есть, если отличий больше некоего процента — алярм.
M>Найдено тоже только при ручном тестировании. Какой автоматический тест это покроет?
Тот который я описал. Правда нужно ли так делать для ГУЯ я не уверен, я делал такие тесты для рендерера.
M>>Вопрос: как это определить автоматическими тестами, без тестирования человеком?
MTD>Это как раз просто, подобное я делал — делается эталонное изображение (может быть мокап), потом сравнивается с тем, что есть, если отличий больше некоего процента — алярм.
У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
Z>у нас очевидным образом при создании теста могут оказаться скриншоты того как должны выглядеть наши контролы в том или ином состоянии (и возможно скриншоты типичных ошибок рендеринга).
1. То, как контролы должны выглядеть, нарисовано дизайнером. Понятно, что в подавляющем большинстве случаев достичь этой эталонности невозможно
2. Я не знаю, что такое «типичные ошибки рендера». У меня в исходном сообщении две ошибки. Являются ли они типичными? Хз.
Z>Вариантов вообще множество на самом деле. Еще можно определять параметры текста и смотреть отобразился ли текст заданной ширины или что контрол отобразился с шириной х, а текст для данного заданного шрифта и его параметров должен быть y, а x<y (ну и позиционирование сюда добавить). Иногда такие баги по косвенным признакам можно отловить (например задание текста в контроле отличается от аналогичных или от состояния контрола в другой момент времени и тогда делать скрин и кидать ворнинг для ручной проверки).
Ну, это — да, возмжно. Но пока напишешь эти тесты, уже стопятьсот раз руками все прокликаешь
Здравствуйте, Mamut, Вы писали:
M>>>Вопрос: как это определить автоматическими тестами, без тестирования человеком?
MTD>>Это как раз просто, подобное я делал — делается эталонное изображение (может быть мокап), потом сравнивается с тем, что есть, если отличий больше некоего процента — алярм.
M>У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
Если результат работы браузера стабилен, то почему нет? Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед. Пока картинка не меняется, тесты зеленые. Изменилась — смотрим вручную и по ситуации фиксим или аппрувим новые скриншоты. Возможно, будет слишком фраджильно, надо пробовать.
M>>У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
v6>Если результат работы браузера стабилен, то почему нет?
Потому что браузер — это не фотошоп/Sketch/Zeplin
v6>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед.
Что вперед? То есть мы в итоге все равно сделали ручное тестирование
Здравствуйте, Mamut, Вы писали:
v6>>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед. M>Что вперед? То есть мы в итоге все равно сделали ручное тестирование
С такими автоматическими gold-тестами можно например спокойно делать рефакторинг, не проверяя каждый раз вручную не поломалось ли чего лишнего.
А в случаях когда вносятся патчи изменяющие результат — то в большинстве случаев меняется только малая часть тестовых case'ов, и нужно перепроверить вручную только их. Причём с возможностью получить/подсветить diff процесс сильно упрощается.
EP>С такими автоматическими gold-тестами можно например спокойно делать рефакторинг, не проверяя каждый раз вручную не поломалось ли чего лишнего.
У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется). Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо.
Здравствуйте, Mamut, Вы писали:
M>>>У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
v6>>Если результат работы браузера стабилен, то почему нет?
M>Потому что браузер — это не фотошоп/Sketch/Zeplin
v6>>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед.
M>Что вперед? То есть мы в итоге все равно сделали ручное тестирование
Получили в довесок к ручном тестированию автоматические регрессионные тесты.
Это не так уж и мало и гораздо лучше, чем все время проверять руками или прозевать внесенный баг.
Здравствуйте, MTD, Вы писали:
M>>Найдено тоже только при ручном тестировании. Какой автоматический тест это покроет?
MTD>Тот который я описал. Правда нужно ли так делать для ГУЯ я не уверен, я делал такие тесты для рендерера.
С UI вся загвоздка. Во первых, динамики полно, во вторых, всякие градиентные заливки в моде, в третьих нюансы лайоута в зависимости от разных вещей, т.е. UI который для человека выглядит одинаково, с т.з. картинки будет совершенно разный набор пикселов. Кроме того, UI в норме меняется довольно часто. Подвинули кнопку — надо забейзлайнить все тесты на которых она видна.
Здравствуйте, Mamut, Вы писали:
EP>>С такими автоматическими gold-тестами можно например спокойно делать рефакторинг, не проверяя каждый раз вручную не поломалось ли чего лишнего. M>У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется).
Рефакторинг по определению не меняет внешнее поведение. В твоём же случае по сути как раз поведение и меняется, пусть и только визуальное.
M>Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо.
Вот автоматический image diff как раз и поможет тебе быстро проверить туда ли уехал график, и не перекрыл ли он что-то лишнее, и не нарисовалась ли какая-нибудь клякса в абсолютно другом месте.
M>>У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется).
EP>Рефакторинг по определению не меняет внешнее поведение. В твоём же случае по сути как раз поведение и меняется, пусть и только визуальное.
Поведение графика не меняется. Всех его родительских компонентов вплоть до чуть ли не 10-го уровня не меняется
M>>Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо.
EP>Вот автоматический image diff как раз и поможет тебе быстро проверить туда ли уехал график, и не перекрыл ли он что-то лишнее.
Скорее, он покажет, что изменился дизайн страницы, после чего — опять с начала. Открываем ручками в трех браузерах, ручками делаем «канонические скриншоты» и т.п.
Здравствуйте, Mamut, Вы писали:
M>>>У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется). EP>>Рефакторинг по определению не меняет внешнее поведение. В твоём же случае по сути как раз поведение и меняется, пусть и только визуальное. M>Поведение графика не меняется. Всех его родительских компонентов вплоть до чуть ли не 10-го уровня не меняется
Какая разница у чего конкретно поменялось визуальное поведение, поменялось же?
M>>>Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо. EP>>Вот автоматический image diff как раз и поможет тебе быстро проверить туда ли уехал график, и не перекрыл ли он что-то лишнее. M>Скорее, он покажет, что изменился дизайн страницы, после чего — опять с начала. Открываем ручками в трех браузерах, ручками делаем «канонические скриншоты» и т.п.
Ты скриншоты ручками что-ли собрался делать?
Автоматический image diff на то и автоматический что он сам соберёт все скриншоты, выявит изменившиеся, сделает diff (попиксельный, либо с подсветкой изменённой области, либо ещё какой подходит по задаче), зашлёт в dashboard и даст кнопочку approve
Тут выше предложили делать исключительно ручками
EP>Автоматический image diff на то и автоматический что он сам соберёт все скриншоты, выявит изменившиеся, сделает diff (попиксельный, либо с подсветкой изменённой области, либо ещё какой подходит по задаче), зашлёт в dashboard и даст кнопочку approve
Здравствуйте, Mamut, Вы писали:
EP>>Ты скриншоты ручками что-ли собрался делать? M>Тут выше предложили делать исключительно ручками
Кто? Где?
EP>>Автоматический image diff на то и автоматический что он сам соберёт все скриншоты, выявит изменившиеся, сделает diff (попиксельный, либо с подсветкой изменённой области, либо ещё какой подходит по задаче), зашлёт в dashboard и даст кнопочку approve M>Это что-то из области фантастики уже
В CDash как раз есть такая фича, её использовали например VTK/ParaView, сейчас сходу не могу найти ссылку на public dashboard, видимо куда-то переместили. Вот, пока только видео нашёл (50:23):
Только там ЕМНИП не скриншоты, а изображения — но не суть, снять скриншоты автоматически вообще не проблема. Ради тестов я сливал с 3rd party программ куда более закрытые данные чем скриншоты
А вот тут конкретно про сайты, скриншоты, и image diff'ы с них
M>>Это что-то из области фантастики уже
EP>В CDash как раз есть такая фича, её использовали например VTK/ParaView, сейчас сходу не могу найти ссылку на public dashboard, видимо куда-то переместили. Вот, пока только видео нашёл (50:23): EP>Только там ЕМНИП не скриншоты, а изображения — но не суть, снять скриншоты автоматически вообще не проблема. Ради тестов я сливал с 3rd party программ куда более закрытые данные чем скриншоты EP>А вот тут конкретно про сайты, скриншоты, и image diff'ы с них
As the name implies, our screenshot tests (1) first capture a screenshot of a URL, then (2) compare the result with an expected image.
Выделенное. Откуда взять "expected image"?
И далее:
Getting generated screenshots to render identically on separate machines was quite a challenge. It took months to figure out how to get it right.
В итоге они выбрали PhanomJS, который использует WebKit. Если посмотреть на пункт первый в моем сообщении, с ВебКитом проблем нет. Но внезапно появились в Firefox'е.
Здравствуйте, Mamut, Вы писали:
EP>>>>Ты скриншоты ручками что-ли собрался делать? M>>>Тут выше предложили делать исключительно ручками EP>>Кто? Где? M>http://rsdn.ru/forum/flame.comp/6198113.1
Там про "смотрим вручную" и "аппрувим вручную", но не про "снимаем скриншоты вручную".
Скриншотов могут быть сотни — под разные комбинации параметров, форм и т.п. — ты что думал после каждого мини-рефакторинга нужно снимать сотни ручных скриншотов?
EP>>А вот тут конкретно про сайты, скриншоты, и image diff'ы с них M>
M>As the name implies, our screenshot tests (1) first capture a screenshot of a URL, then (2) compare the result with an expected image.
M>Выделенное. Откуда взять "expected image"?
Expected image от другого отличается тем, что первый зааппрувили, а второй нет. Способ получения изображений желательно должен быть одинаковый — это проще (так как и там и там автоматически) и надёжней (не будет различий возникших от разных методов)
M>И далее: M>
M>Getting generated screenshots to render identically on separate machines was quite a challenge. It took months to figure out how to get it right.
Да пофиг сколько у них что заняло, я привёл первую попавшуюся ссылку, дабы показать что это никакая не фантастика. Наверняка есть готовые утилиты — я ни вебом ни GUI не занимаюсь, поэтому сходу конкретные тулзы не посоветую.
M>>Выделенное. Откуда взять "expected image"?
EP>Expected image от другого отличается тем, что первый зааппрувили, а второй нет. Способ получения изображений желательно должен быть одинаковый — это проще (так как и там и там автоматически) и надёжней (не будет различий возникших от разных методов)
Ну то есть expected image все равно получается строго вручную. Потому что в описанной мною ситуации уже первый скриншот будет с ошибкой.
M>>И далее: M>>
M>>Getting generated screenshots to render identically on separate machines was quite a challenge. It took months to figure out how to get it right.
EP>Да пофиг сколько у них что заняло
Нет не пофиг.
EP>, я ни вебом ни GUI не занимаюсь
А. Ну тогда твои советы идут лесом, уж извини. Хотя теперь понятно, почему ты скипнул мой комментарий про WebKit vs. Firefox
Здравствуйте, Mamut, Вы писали:
M>>>Выделенное. Откуда взять "expected image"? EP>>Expected image от другого отличается тем, что первый зааппрувили, а второй нет. Способ получения изображений желательно должен быть одинаковый — это проще (так как и там и там автоматически) и надёжней (не будет различий возникших от разных методов) M>Ну то есть expected image все равно получается строго вручную. Потому что в описанной мною ситуации уже первый скриншот будет с ошибкой.
Что значит строго вручную? То что его нужно просмотреть чтобы зааппрувить? Да нужно. Точно также как и подготовить тестовые in/out вектора для любого другого теста
M>>>И далее: M>>>
M>>>Getting generated screenshots to render identically on separate machines was quite a challenge. It took months to figure out how to get it right.
EP>>Да пофиг сколько у них что заняло M>Нет не пофиг.
Пофиг. Даже если взять их месяцы, и допустить что в каждом случае нужно тратить эти месяцы, и нет ничего готового — то это никакая не фантастика как ты выражаешься.
EP>>, я ни вебом ни GUI не занимаюсь M>А. Ну тогда твои советы идут лесом, уж извини.
Ты можешь ныть сколько угодно, но технологию тебе уже разжевали, дальше ищи сам.
M>Хотя теперь понятно, почему ты скипнул мой комментарий про WebKit vs. Firefox
Да причём тут WebKit vs. Firefox, бери все доступные веб-движки и делай со всех скриншоты для каждого случая.
Я кстати вспомнил что уже делал робота для одной веб-игрушки, чисто for fun — целиком на основе эмуляции работы мыши и автоматического снятия скриншотов с Firefox во время процесса, и их "частичного распознавания" (надо было найти расположение игровых клеток, и определить их содержание) — это был небольшой скрипт на Python, написанный за несколько часов — никаких проблем не было
Здравствуйте, Гест, Вы писали:
Г> тесты «как оно выглядит» раньше были менее важны (ну, грубо говоря в период когда почти любой интерфейс это была статичная «форма», раз и навсегда сляпанная в «дизайнере форм»), теперь всё по-другому, конечно;
EP>>>, я ни вебом ни GUI не занимаюсь M>>А. Ну тогда твои советы идут лесом, уж извини. EP>Ты можешь ныть сколько угодно, но технологию тебе уже разжевали, дальше ищи сам.
Это тебе кажется, что ты разжевал. Хотя то, что ты «разжевал» даже близко не является решением. По ссылке пацанам понадобилось несколько месяцев траха, чтобы смочь сделать "a couple dozen" скриншотов только на одном из доступных движков.
Удобно, че.
M>>Хотя теперь понятно, почему ты скипнул мой комментарий про WebKit vs. Firefox
EP>Да причём тут WebKit vs. Firefox,
При том, что ты «не занимаешься вебом и UI» и вообще не понимаешь, о чем говоришь. Кидаешь мне статью, в которой якобы все разжевано при том, что они в итоге снимают скриншоты только в ВебКите, потому что ни один другой способ не подошел.
EP>бери все доступные веб-движки и делай со всех скриншоты для каждого случая.
О да, ведь это так просто, «технология разжевана» и, главное, это будет стабильно работать, ага-ага
EP>Я кстати вспомнил что уже делал робота для одной веб-игрушки, чисто for fun — целиком на основе эмуляции работы мыши и автоматического снятия скриншотов с Firefox
Здравствуйте, Mamut, Вы писали:
EP>>>>, я ни вебом ни GUI не занимаюсь M>>>А. Ну тогда твои советы идут лесом, уж извини. EP>>Ты можешь ныть сколько угодно, но технологию тебе уже разжевали, дальше ищи сам. M>Это тебе кажется, что ты разжевал.
Не только я
M>Хотя то, что ты «разжевал» даже близко не является решением.
Аргументы против?
M>По ссылке пацанам понадобилось несколько месяцев траха, чтобы смочь сделать "a couple dozen" скриншотов только на одном из доступных движков. M>Удобно, че.
Ещё раз, это контраргумент твоему опрометчивому высказыванию про область фантастики. Первая попавшаяся ссылка.
Сколько там им времени понадобилось, какая у них кривизна рук — рояли не играет.
M>>>Хотя теперь понятно, почему ты скипнул мой комментарий про WebKit vs. Firefox EP>>Да причём тут WebKit vs. Firefox, M>При том, что ты «не занимаешься вебом и UI» и вообще не понимаешь, о чем говоришь.
Давай конкретные аргументы в студию.
M>Кидаешь мне статью, в которой якобы все разжевано при том, что они в итоге снимают скриншоты только в ВебКите, потому что ни один другой способ не подошел.
Первый пример показывает что есть реальные Dashboard'ы с image diff'ами, но так как там тема немного другая (не веб) — я привёл ссылку на вариант image diff'ов с веба.
Остальное это всё твои левые домыслы, я не говорил что в статье всё разжёвано, что это самый быстрый вариант, или что скриншоты можно снять только с WebKit, или что это всегда оправданно.
EP>>бери все доступные веб-движки и делай со всех скриншоты для каждого случая. M>О да, ведь это так просто, «технология разжевана» и, главное, это будет стабильно работать, ага-ага
Приводи конкретные аргументы против, а не это лирику.
EP>>Я кстати вспомнил что уже делал робота для одной веб-игрушки, чисто for fun — целиком на основе эмуляции работы мыши и автоматического снятия скриншотов с Firefox M>Ты путаешь робота for-fun и тесты.
Где путаю? Ты по сути ни одного контраргмуента так и не привёл.
Здравствуйте, Mamut, Вы писали:
M>Лень писать это в соседнюю ветку на 100500 страниц, поэтому понапложу сущности без необходимости
M>Пара смешных людей рассказывают о том, как все подряд покрывается автоматическими тестами и прочей ерундой, и тесты на GUI пишутся на раз.
M>И тут у меня как раз возник момент.
Я считаю что автоматические тесты это лишняя трата времени.
А как же раньше софт писали? Вообще без никаких тестов. И работало же оно!
M>>По ссылке пацанам понадобилось несколько месяцев траха, чтобы смочь сделать "a couple dozen" скриншотов только на одном из доступных движков. M>>Удобно, че.
EP>Ещё раз, это контраргумент твоему опрометчивому высказыванию про область фантастики. Первая попавшаяся ссылка. EP>Сколько там им времени понадобилось, какая у них кривизна рук — рояли не играет.
Ну и зачем тебе мои аргументы, если ты их отметаешь с комментарием «я ничего не знаю, но вот тебе первая попавшаяся ссылка все объясняет!!».
Все остальное поскипано, потому что аргументы тебя не интересуют.
Здравствуйте, Mamut, Вы писали:
M>>>По ссылке пацанам понадобилось несколько месяцев траха, чтобы смочь сделать "a couple dozen" скриншотов только на одном из доступных движков. M>>>Удобно, че. EP>>Ещё раз, это контраргумент твоему опрометчивому высказыванию про область фантастики. Первая попавшаяся ссылка. EP>>Сколько там им времени понадобилось, какая у них кривизна рук — рояли не играет. M>Ну и зачем тебе мои аргументы, если ты их отметаешь с комментарием «я ничего не знаю, но вот тебе первая попавшаяся ссылка все объясняет!!».
Забавная трактовка вот этого диалога, видимо сковородка сильно горячая
EP>>>Автоматический image diff на то и автоматический что он сам соберёт все скриншоты, выявит изменившиеся, сделает diff (попиксельный, либо с подсветкой изменённой области, либо ещё какой подходит по задаче), зашлёт в dashboard и даст кнопочку approve
M>>Это что-то из области фантастики уже
EP>В CDash как раз есть такая фича, её использовали например VTK/ParaView, сейчас сходу не могу найти ссылку на public dashboard, видимо куда-то переместили. Вот, пока только видео нашёл (50:23):
EP>Только там ЕМНИП не скриншоты, а изображения — но не суть, снять скриншоты автоматически вообще не проблема. Ради тестов я сливал с 3rd party программ куда более закрытые данные чем скриншоты
EP>А вот тут конкретно про сайты, скриншоты, и image diff'ы с них
M>Все остальное поскипано, потому что аргументы тебя не интересуют.
Врёшь же Прекрати передёргивать, приведи реальные аргументы. Например "у нас на сайте куча всяких анимаций, контент супер-динамичный, кнопки скачут туда-сюда и видоизменяются, поэтому скриншоты сами по себе не особо уместны".
EP>Врёшь же Прекрати передёргивать, приведи реальные аргументы.
Привел:
— твои рассказы про тулзы — фантастика. Твое «разжевывание» свелось к блогпосту, в котором для получения 12 скриншотов им пришлось несколько месяцев бороться с тулзами и с веб-браузерами. Причем проблемы проистекают не из их криворукости, как тебе не хотелось бы, а из кривизны тулзов и браузеров.
— сбор скриншотов на начальном этапе все равно вручную. При этом следующая твоя фраза нереализуема:
Способ получения изображений желательно должен быть одинаковый — это проще (так как и там и там автоматически) и надёжней (не будет различий возникших от разных методов)
Потому что нет никакого хорошего, быстрого, надежного единого способа получить скриншоты
— ты, по твоему признанию не работаешь ни с вебом ни с GUI. Что делает твои фразы типа «Да причём тут WebKit vs. Firefox, бери все доступные веб-движки и делай со всех скриншоты для каждого случая.» особенно смешными:
-- нет стандартного способа получить скриншоты со всех браузеров (если только не поднимать ферму типа browserstack.com[1] — и то, способ получения скриншотов все равно будет разным)
-- нет стандартного способа определить, что является "expected image" для всех движков
-- нет стандартного способа выявить разницу и проблемы рендеринга между движками (например, что один браузер рендерит шрифты немного не так, как другой) и т.п.
---
[1] Так-то да, если отдавать свои данные и прочее на сторону, то кое-какие инструменты есть, типа того же browserstack'а.
Здравствуйте, Mamut, Вы писали:
EP>>Врёшь же Прекрати передёргивать, приведи реальные аргументы. M>Привел: M>- твои рассказы про тулзы — фантастика.
Нет, не фантастика, ссылки я привёл — там и dashboard, и image diff, и скриншоты.
M>Твое «разжевывание» свелось к блогпосту,
Блогпост вообще не про разжёвывание, я уже несколько раз это подчеркнул, а ты до сих продолжаешь врать. Зачем? Уже надоедает
M>- сбор скриншотов на начальном этапе все равно вручную.
Нет, не вручную. На начальном этапе будет ручная настройка софта который снимет скриншоты. При этом вручную снимать их не нужно
M>При этом следующая твоя фраза нереализуема: M>
M>Способ получения изображений желательно должен быть одинаковый — это проще (так как и там и там автоматически) и надёжней (не будет различий возникших от разных методов)
M>Потому что нет никакого хорошего, быстрого, надежного единого способа получить скриншоты
Непонятно с чем ты не согласен.
Если с тем что на начальном этапе нельзя снять скриншоты автоматом — то почему тогда на других можно?
Если с тем что вообще нельзя снять скриншоты автоматом, то непонятно почему ты выделяешь именно начальный этап
M>- ты, по твоему признанию не работаешь ни с вебом ни с GUI. Что делает твои фразы типа «Да причём тут WebKit vs. Firefox, бери все доступные веб-движки и делай со всех скриншоты для каждого случая.» особенно смешными: M>-- нет стандартного способа получить скриншоты со всех браузеров
Например через средства API OS — именно так я делал в упомянутом выше роботе. Этот способ подойдёт для любого браузера
M>(если только не поднимать ферму типа browserstack.com[1] — и то, способ получения скриншотов все равно будет разным)
Способ получения скриншотов может быть одним или разным — сути это не меняет
M>-- нет стандартного способа определить, что является "expected image" для всех движков
Тебе уже выше разжевали, что изображения нужно аппрувить
M>-- нет стандартного способа выявить разницу и проблемы рендеринга между движками (например, что один браузер рендерит шрифты немного не так, как другой) и т.п.
Если есть разница в редеринге, и она допустима, и её нельзя распознать через с какой-нибудь tolerance, то аппрувить придётся изображения каждого. О чём тебе выше и сказали:
v6>>>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед.
M>>Что вперед? То есть мы в итоге все равно сделали ручное тестирование
v6>Получили в довесок к ручном тестированию автоматические регрессионные тесты.
v6>Это не так уж и мало и гораздо лучше, чем все время проверять руками или прозевать внесенный баг.
M>--- M>[1] Так-то да, если отдавать свои данные и прочее на сторону, то кое-какие инструменты есть, типа того же browserstack'а.
Вот именно — "так-то да", это не фантастика, а ты сел в лужу со своим хамством
Прекрати передёргивать, приведи реальные аргументы. Например "у нас на сайте куча всяких анимаций, контент супер-динамичный, кнопки скачут туда-сюда и видоизменяются, поэтому скриншоты сами по себе не особо уместны".
