феерический факап Яндекса - Компьютерные священные войны

Здравствуйте, IB, Вы писали:

>>А я и не говорил, что soak tests везде применимы.
IB>Прекрасно! И я именно об этом. Иными словами утверждение "для избавления от проблемы Х надо делать soak тесты" — ложно, как минимум потому, что такие тесты не везде применимы.
Для сабжа — вполне, я рассуждал в контексте сабжа. Но в общем случае, ты прав, soak tests не могут решить все проблемы в жизни.

>>И что UI? И что окружение? Подробнее давай.
IB>Да куда уж подробнее — ранее вы сами признались, что UI автоматизировать сложно,
Я признавался о UX. Автоматизировать вообще сложно, думать приходится, вместо того, чтобы просто кнопки клацать. "Зачем думать — прыгать надо."

IB>на воссоздание потенциального окружения, тоже виртуалок не напасешься... Поэтому такого рода тесты если и делаются, то в лучшем случае на 2-х 3-х основных конфигурациях и достаточно ограниченном количестве сценариев.
По сравнению с чем? Если не тестировать вообще, то да, конечно. А если используешь ручное тестирование — проблемы те же, даже больше. Ибо вручную реально протестировать N конфигураций, а автоматически зачастую N * K, где K ≫ 1.

>>soak tests можно и на реальной железке запускать. Я не вижу в этом проблемы.
IB>Вы хорошо представляете себе зоопарк Android устройств?
Я не понимаю к чему это опять. Ты предлагаешь вообще не тестировать и факапить как яндекс?

>>Мы сами принимаем решение — что основной, а что нет. И исходя из этого проектируем тесты. Поэтому, чисто по построению подход отлавливает всё.
IB>Вы сами найдете здесь логическую ошибку или подсказать?
Подскажи.

>>Неужели обо мне? Чем моя персона тебя так впечатлила и заинтересовала? В чём для тебя ценность моего изумительного кода?
IB>Конечно же не о вас, ваша конкретная персона мне в принципе параллельна. Откуда у вас вообще это желание на личности перейти? Нормальные аргументы что ли закончились?
Я тогда не понимаю почему тебе было так необходимо, чтобы я выдал тот код?

>>У нас — пока не пропустил. Это, конечно, не 100% гарантия, но сама структура тестов позволяет на них полагаться.
IB>Good for you. Но уж простите, не сочту это достаточным критерием приемлемости такого подхода.
А есть более приемлимые подходы? Поделись, очень любопытно.

>>Это не было подменой понятий, а уточнением. Тест без процесса — дохлый код.
IB>Как я уже говорил, тот факт, что одно без другого не имеет смысла, вовсе не означает, что эти два понятия суть одно и то же. Вы же, в нескольких сообщениях, явно утверждали, что тест и процесс тестирования — одно и тоже, что является подменой понятий.
Не одно и то же, а связанные понятия — одно без другого не работает.

>>У нас теста нет в требуемом тобой виде, то что ты хочешь называть тестом. А по факту — есть.
IB>Можно я вас здесь же процитирую, чтобы далеко ходить не надо было:

"тест" тоже существует, который ты заставил меня написать

IB>Как мы договорились, я вас заставил написать тест, в виде теста, который принятно называть тестом. И вы признались, что он у вас тоже существует. Но тут же опровергли. Потом еще раз.
IB>Так существует или не существует? Вы уж прям совсем в показаниях запутались. Определитесь уже ))
Повторяю ещё раз. Мы тестируем ситуацию утечек дискового пространства в нашем CI, но как такового теста, который ты принялся называть тестом — нет. Нет кода аналогичного тому, который Вы соблаговолили заставить меня написать. Что непонятного-то?

>>В общем случае да, но иногда хорошо поставленный процесс может заменить тесты. В нашем случае процесс проще в реализации и поддержке, а результат такой же.
IB>Позвольте не поверить. Мне сложно представить ситуацию когда, например, константу threshold в приснопамятном тесте поправить сложнее, чем проконтролировать правильный остаток свободного места на диске CI. А вот обратную ситуацию, когда по совершенно легальной причине, место на CI значительно увеличилось, и из-за этого что-от пропустили полагаясь лишь на ограничения CI — я могу представить запросто. Не говоря уже о времени поиска из-за чего там все свалилось.
Ещё раз напоминаю. У нас нет "диска CI", у нас кластер с тучей разных сервисов, да ещё и разные разделы дисков. Поэтому нужно контолировать не одну константу, а штук сто. А ещё есть staging envs, а ещё perf-test envs, и ВНЕЗАПНО констант становится уже под тысячу.

Здравствуйте, Ikemefula, Вы писали:

I>>>Все понятно, селениум это приложение целиком или почти целиком. Собтсвенно про эти случаи и сказано.
I>·>Я не понимаю что ты хочешь сказать. Вроде начали с того, что некое гипотетическое изменение, о ужас, роняет 100500 тестов. И теперь их все надо фиксить. А то что вручную тоже _надо_ (хотя, конечно, можно и забить) проверить эти же 100500 случаев — ты не вспоминаешь. И да, падение 100500 тестов бывает обычно в приложении целиком.
I>цитирую себя "регрессию нужно детектить автотестами"
I>снова цитирую себя "новые баги ищутся только руками"
Если уже есть авто-тесты, то искать только руками — глупо. Автотесты будут делать 90% действий, а остальной 10% — уже исследование для поиска, и это не ручные тесты, а exploratory.
Если же авто-тестов нет, то _все_ баги ищутся только руками, как у яндекса в сабже.

I>Кроме того, UI обычно переделывается очень сильно. И очень часто — когда меняется вообще всё. Было "три радиобатона", стало "комбобоксы", потом "грид", потом "сложная многоуровневая форма", потом "explorer-like UI". И это только одна небольшая часть приложения.
I>С т.з. юзера все выглядит узнаваемо, с т.з. автотестов это АДъ и Израиль. Кажды раз тебе надо переписывать 100500 тестов.
Я знаю что мне не надо. Если вам надо, то у вас что-то не то.

I>>>Какие именно для тебя детали критичны — никто не знает.
I>·>Это уж вообще крутая отмаза. Так можно что угодно отмазать: и команда, сидящая этажом выше, и коллега за соседним столом, и "я вчерашний" — всё 3rd-party-like.
I>Кто тебе сказал, что этажом выше ? Яндекс уже давно в разных городах и даже странах разработку ведёт.
А я в разных настроениях разработку веду. И позвонить по скайпу в другой город гораздо проще, чем мне вчерашнему.

I>>>Про это сказано в цитате выше. Здесь на самом деле бесконечное количество кейсов, особенно в браузере.
I>·>Близкое к бесконечному количество кейсов автоматически тестировать на порядки проще. У нас более +10к функциональных тестов, включая всевозможные API и WUI, занимает ~25 минут на кластере... Вручную это займёт месяца два, полагаю.
I>

API никто в своём уме в ручную не тестирует.
Скажем, "если юзер использовал неверный пароль трижды при подключении к FIX API, то в Admin UI аккаунт должен нарисоваться заблокированным и об этом должна появиться запись аудита в отчёте." Это UI тест или API? Скажем, как вы вручную будете тестировать такую смесь?

I>Это что, так трудно запомнить ? API используется программными модулями, для него естественные условия это вызов из программных модулей. Автотесты в этом случае наиболее близки к естественным условиям.
Мне трудно оценить скольо именно у нас тестов WUI, но интуитивно около 10%, т.е. 1000 тестов. И проблема в том, что просто "чисто тесты UI" получаются не так часто.

I>·>Понятно сейчас. Ты просто отвечал на вопрос который я не задавал, поэтому я и не понимал ответы. Я масштабы и так представляю. Не понимаю только зачем ты это упомянул. Ты, вроде, наоборот ручное тестирование защищаешь, а приводишь аргументы в пользу автоматического — чем больше масштаб, тем более эффективно авто, чем ручное.
I>Если ты протестировал 20 а осталось еще 7980, это значит, что нужно ожидать целую кучу всякого непотребства. Появился новый девайс, автотесты красные, а все работает хорошо. Твои действия ?
Хорошо. А теперь сравни этот же сценарий с ручным подходом и объясни разницу. Откуда ты узнал, что _всё_ работает хорошо?

I>Или наоборот — всё зеленое, а UI надо переделывать, ибо выглядит коряво. Переделываем форму... и твои тесты отвалились все до единого. А живому человеку — пофигу.
Правильно. Это значит надо просмотреть все эти тесты и проверить — что живому человеку действительно пофигу. Как иначе ты узнаешь, что пофигу?
А вообще — это деструктивный подход, если какое-то изменение ломает сразу всё. Не надо так делать. С автотестами — ты это узнаешь, что изменение слишком глобальне. С ручным тестированием — ты просто находишься в счастливом неведении.

I>>>Очевидно — нет. Вместо эвентов кое где вводятся кастомные схемы навроде
I>·>Разве неочевидно, что "кастомная схема навроде" никоим образом эвентами не является?
I>Принципиально ничем не отличается. Событие в одном компоненте транслируется в другие в одном случае чз унифицированый интерфейс, в другом — через кастомный.
Согласен. Если любой вызов метода обозвать евентом или "кастомной схемой навроде", то можно много глупостей навыдумывать.

I>>>Тесты сами по себе фиксируют внешний АПИ. Ты дополнительно к этому жостко фиксируешь еще и реализацию.
I>·>Разные типы тестов имеют разные цели, средства, сильные и слабые стороны. Ты говоришь слишком общими словами, поэтому смысла никакого.
I>Клиенту совершенно по барабану, кто вызовет его экшн, твой компонент напрямую, команда или еще кто.
I>Абсолютно без разницы, главно что бы вызвали.
Юнит-тесты впервую очередь не для клиента, а для программиста.

I>А если ты прибил к реализации, то внезапно, после рефакторинга надо перелопачивать все тесты. То есть, патчить не код, что бы тесты стали зеленые, а патчить тесты, что бы стали зеленые.
I>Оптимизация — ровно тоже самое.
Тестры — ровно такой же код. И рефакторится вместе с обычным кодом ровно так же. IDEA пофиг в скольки местах переименовать метод — в 5 или в 50. Тесты при рефакторинге остаются зелёные. По определению рефакторинга.

I>>>Такие вещи проще, надежнее и эффективнее реализовывать не на тестах, а на внятных формальных моделях, которые поддаются анализу.
I>·>Разные задачи — разные решения. Не всё имеет смысл формализовать моделями.
I>Сложную логику — практически всю. Сложное поведение — чем больше, тем лучше. Сложное взаимодействие — целиком.
В 90% ПО нет никакой сложной (не путаем с усложнённой) логики.

I>>>1 Оно ловит узкий класс ошибок. В основном это простейшие случаи.
I>·>В типичной разработке 90% ошибок — простейшие случаи. Этот узкий класс ошибок является самым массивным.
I>В типичной разработке ошибок становится больше в зависимости от сложности, при чем зависимость сильно нелинейная. И вот эту самую сложную часть тесты ловят хуже некуда.
Если ты всё ещё о юнит-тестах, то юнит-тесты тестируют просты юниты. Сложная система собирается из протестированных юнитов и тестируется другими типами тестов.
Если ты про авто-тесты, то сложные части ловятся тестами гораздо лучше чем вручную.

I>Скажем, что бы качественно использовать автотесты верстки, нужен эталонный CSS процессор да с мега возможностями типа "закрывает ли какой контрол марджин вот этой мульки ?".
CSS это про UX. Неинтересно.

I>>>Вместо лапши из if-else нужно брать pattern matching. Обработка строк это большей частью внятные грамматики и реализация их с помощью тех же регэкспов.
I>·>Чтобы всё это имело смысл сразу — нужно разрабатывать софт для Ядерных Реакторов с циклом релизов раз в 10 лет. Чтобы взять паттерн матчинг, надо чтобы у тебя была лапша if-else сразу, в 500-страничном фича-реквесте.
I>Не надо никаких 500 страниц. Эти вещи постояно вылазят, ну по крайней мере в UI так. Чуть не любая форма на самом деле сложный автомат. Переходы, навигация унутре приложения == автомат. И тд
Так и UI тоже итеративно разрабатывается. Начинаешь с одной кнопки "сделать всё", а потом...

I>>>Кроме того, вещи навроде контрактов, инвариантов, пред-, пост-условий дают сами по себе гораздо больше пользы. А _вместе_ с юнит-тестами это вообще чудеса.
I>·>Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.
I>Вот как раз для меняющихся требований это идеально работает. Убрал условие, добавил новое и всё.
Что всё? А вдруг это теперь конфликтует с другим бизнес-требованием, написанным 2 месяца назад? Как узнать?

I>Изменилось требование "операция должна начинаться с А, включать Б, заканчиваться С" и теперь все авто-тесты которые имеют к этому отношение, надо взять и пределать, потому что они отвалились.
Зато ты об этом знаешь, что новое требование повлекло изменение поведения в старых ситуациях. А так — просто счастливое неведение и твои родимые reopen баги.

I>>>Цель — обнаружение проблем в разработке, оптимизация процесса в долговременном масштабе — год-два-пять.
I>·>Коммиты о затратах не говорят. Может корреляция и есть, но зависимости нет.
I>И я об чем. Вещи которые трекер умеет искаропки вы заменили на ручной привод.
Для использования трекера требуются дополнительные усилия и затраты времени. А ещё проблема держать всё это актуальным. А выгоды — никакой.

I>>>Например я хочу знать наиболее проблемные компоненты.
I>·>Проблемность компонент смотрится в issue tracker. Я же говорю, что для проблем (issues) у нас есть issue tracker. А аннотации в коде — для разработки новых историй (фичи).
I>Вашего трекера недостаточно. Истории не с нуля пишутся, а с изменением и использованием кода готовых компонентов.
Что недостаточно? Пусть с изменением, в чём проблема-то? Для регрессий есть тесты.

I>>>Или девелоперов, у которых много реопенов, или девелоперов, у которых крайне мало багов вообще.
I>·>У нас нет code ownership. Ещё мы часто в парах работаем...
I>А при чем здесь овнершип код ? Вот сказали тебе авторизацию пофиксить, ты пофиксил. А потом в этом месте еще десяток реопенов вылез.
Я не понимаю откуда эти реопены твои любимые возьмутся? Они не вылезут, а просто упадёт десяток тестов — и фикс твой не пройдёт CI.

I>·>А такие как в UI допустимые задержки позволяют и не знать о целом классе проблем.
I>Ты выйди в реальный мир и позапускай самый разный софт. Через одну софтины лагают и даже тормозят нещадно.
I>Твоё сравнение с сервером не работает. Ресурсы используются принципиально иначе.
I>На сервере ты никогда не вгружаешь вагоны данных целиком. Для UI это вобщем норма. Позволяет реализовать адские возможности в той же визуализации.
Зато искать лаги проще, не надо дебажить kernel, например.

I>>>Одна песчинка ничего не весит. И 10 — ничего. И даже 100 — ничего. И 1000 — тоже ничего.
I>>>Следует ли из этого, что и самосвал песчинок ничего не весит ?
I>·>Они весят, но весят в другом месте, не там где мы измеряем.
I>Я могу тебе назвать не менее сотни багов связанных именно с логированием. Проявлялось именно в виде лагов в UI. Но вообще сильно уверен, что ты выдашь "просто вы не умеете..."
Если вы синхронно пишете текстовые логи на диск — логично. Лагать будет, багов — тонны. Если просто копится статистика в сотне int-переменных lock-free — то это наносекунды. Откуда лаги?

I>>>Глядишь, через 5-6 поколений архитектур приблизишься к успеху

I>·>DDR3 это пиковая 2666 MB/s (мегабайт в секунду), т.е. 20 гигабит в секунду, уже Ethernet 100-гигабитный не новость. Не знаю что ты такое насчитал или в каком поколении ты живёшь. Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.
I>Немного обсчитался, но возможностей шины тебе по любому уже не хватает.
I>1 2666 это пиковая. Реальная много меньше
Так вон уже на TbE замахиваются...

I>2 кроме UI есть и другие потребители шины
Кто? (мы вроде говорим о perf-test env)

I>Более того, на данный момент в большинстве платформ тебе
I>1 не хватит адресного пространства
Большинство это 16 бит или 32? По-моему уже даже мобильные платформы 64bit попёрли.

I>2 OS не сможет переварить данные если ап хватит
Человек и подавно.

I>Итого — твои цифры взяты от балды.
Соврешенно верно, повторюсь: Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.

I>>>Когда ты берёшь либу в хрен знает каком качестве, то вообще не знаешь, ни что в самой либе, ни что в твоем приложения. Поэтому нужно искать не только старые баги, но и новые, к чему авто-тесты принципиально непригодны.
I>·>Логично, но именно 99% проблем когда берёшь либу, сабж в том числе, именно регрессия.
I>Это статистика от балды. По опыту предыдущих проектов, после перехода на новую версию UI либы тестеры всегда находили целую кучу _новых_ багов, при том что вендор гарантировал обратную совместимость. Что характерно, такие баги сложнее всего фиксить.
Опять же.. UX или функциональных? Функционирование приложение при обновлении либы не должно меняться.

I>·>Что можно писать код не поддающийся авто-тестированию? Да запросто. Но правильная идея в том, чтобы так не делать. У нас любая история начинается с вопроса "а как мы это покроем тестами?"
I>А ты в курсе, что это _удорожает_ разработку ?
В курсе, конечно. Зато это удешевляет контроль качества.

I>Кроме того, где гарантия, что тестопригодные средства вообще могут дать внятное решение ?
Если не могут — ищем компромисс. Иногда вообще отказываемся от истории.

I>>>Если нет UI то мануальщику там делать нечего.
I>·>UI есть, и дофига. Но некоторые функции не вынесены в UI, аутентикация или аудит, например. И мануальщики тестируют очень просто, сам наблюдал: открывают SQL Console, копипастят из вордового документа запрос и долго тупят над ошибками если что-то пошло не так.
I>А твои авто-тесты надо полагать умеют работать на раз с кейсом "что-то пошло не так" ?

Конечно умеют — рисуют отчёт. Далее мы правим тест, чтобы там что-то шло не так как можно реже.

I>>>3. Ты снова забыл про разную цену ошибок
I>·>Для меня неочевидно, что ручное тестирование дешевле автоматического.
I>Потому что ты никак не поймешь — рич UI и серверный бакенд это две разные вселенные.
I>В UI у тебя никогда не будет четкого набора требований.
I>Постоянно будут изменения "подвинь, перенеси, убери, подкрасы, выдели"
I>Регулярно будут изменения "давайте попробуем новый flow" — вот это убивает все твои тесты.
I>Скажем, один скрин в визард добавить гарантировано ломает вообще все тесты для этого визарда.
I>Нужно что бы ломались кейсы чувствительные для юзера. А вот добавление скрина в визард таким не является.
Такие "упавшие" тесты чинятся на раз. Быстро поднятое упавшим не считается.

I>>>Это теоретически, если предположить что гугл не глядя ни на что будет доводить до юзеров всех уродцев. На практике, если куча денег вложена а результата все ещ нет, проект нещадно режется.
I>·>Я на 100% уверен, что у них на несколько порядков больше убитых на ранней стадии уродцев, чем доживших до вывода юзерам.
I>И тем не менее Гугл лидер по количеству уродцев, при чем настолько, что во многих областях гуглу в принципе нельзя доверять.
Просто потому, что они могут это себе позволить.

I>>>Технически у подразделений в разных конторах появляется целый стек менеджеров которые не в курсе дел у соседей.
I>·>Менеджеры — это не технология. Технология это их репозиторий и тулзы вокруг него.
I>Ога, так прям и вижу — дать тебе 2тб репу, так в в секунду любой компонент раздраконишь. Чтото мне кажется, будешь писать письма. Кому ? Девелопер может быть занят, ибо у него явный блокер от другой тимы. Итого — тебя поставили в очередь. Всё. Хочешь побыстрее — надо учиться писать письма вверх-вниз по стеку.
Я, конечно, внутренности гугла не знаю, но вроде где-то вроде читал, что у них довольно плоская структура менеджмента. И, собственно, при хорошей автоматизации — ты можешь драконить любой компонент — делай изменение, оно будет авто-проверено, что ничего не ломает и потом попадает на component owner review, который обычно тривиален.
Истории с письмами и очередями в стеках — это когда всё построено на ручном тестировании. Ты предлагаешь изменение овнеру, а он сам не знает — что произойдёт, любое изменение — высокий риск. А значит он своих тестеров должен натравить, а у него тестеры и так под завязку загружены. Вот и начинается волынка...

I>>>А сетевой трафик это UI ? А место на диске ? А память ? А проц ?
I>·>Нет, но мне удивительно, что мануальные тестеры UI-аппликух приносят баги с невалидным json от сервера. Хо-хо! Мрак. Жуть. И тут кто-то мне рассказывал про протоколы, инварианты и формальные модели.
I>Это элементарно. Один из клиентов загоняет неверные данные, но сам рисует их корректно. Другой клиент их не может проглотить. Отсюда ясно, что нужен ответ сервера — кому что откуда пришло. Т.е. выяснить, чье подразделение сломало — тоже задача тестера.
Как это не может проглотить? А как же формальные модели?

I>>>Пудозреваю, ты про нагрузку. Счетчики никто не отменял. Рисуется себе картинка по каждому счетчику и все. В конце сессии смотришь, чего худо, а чего — нет. Элементарно
Вот кстати очень характеризует ваш подход. Вместо того чтобы сделать авто-тест с банальным if, вы процесс специальным образом делаете ручным — тащите какую-то библиотеку визуализации счётчиков, чтобы потом это всё тестировать вручную: максимизируете человеческий фактор, а потом ноете, что невозможно автоматизировать.

I>·>Или новая либа стала куда-то лезть в интернет..
I>Открой для себя прокси-сервер.
С ручным приводом? Это какой?

I>>>"Автоматизировать" человеческий фактор пока еще никто не научился.
I>·>Человеческий фактор можно минимизировать.
I>Это юзеров на софтварные модули заменить ? Интересная идея.
Попробуй, вдруг получится — продавать API, а не UI.

Здравствуйте, ·, Вы писали:

>Для сабжа — вполне, я рассуждал в контексте сабжа. Но в общем случае, ты прав, soak tests не могут решить все проблемы в жизни.
Контекст "сабжа" совершенно ортогонален контексту применения soak тестов. Таким образом, совершенно спокойно может возникнуть ситуация, когда "сабж" возможен, а soak тест, чтобы его отловить к этому не прислонишь.

>По сравнению с чем? Если не тестировать вообще, то да, конечно. А если используешь ручное тестирование — проблемы те же, даже больше. Ибо вручную реально протестировать N конфигураций, а автоматически зачастую N * K, где K ≫ 1.
Вы все время уплываете из контекста и начинаете спорить с выдуманными аргументами. Никто не предлагает отказываться от автотестов, там где это возможно. Речь про другое, про то что автотесты далеко не везде применимы и не все сценарии покрывают, а значит по прежнему остается пространство для возможных ошибок.

>Я не понимаю к чему это опять. Ты предлагаешь вообще не тестировать и факапить как яндекс?
Все к тому же — у автотестов есть проблемы с применимостью. У вас какая-то странная логика — я лишь иллюстрирую проблемы автотестов, а вовсе не предлагаю от них отказаться.

>>>Мы сами принимаем решение — что основной, а что нет. И исходя из этого проектируем тесты. Поэтому, чисто по построению подход отлавливает всё.
IB>>Вы сами найдете здесь логическую ошибку или подсказать?
>Подскажи.
Их тут даже две. Во-первых, из того факта, что вы принимаете решение вовсе не следует, что отлавливается все. А во-вторых, либо вы таки сортируете сценарии на основные и не основные, и тогда покрываются только основные сценарии, либо чего вы там решаете — вообще не важно (но то что это утопичный случай, надеюсь понимаете даже вы =) ).

>Я тогда не понимаю почему тебе было так необходимо, чтобы я выдал тот код?
Прежде всего, не обязательно вы — это чтобы явно указать, что конкретные персоналии меня мало тревожат. Тем не менее, этот код позволил наглядно проиллюстрировать пару тезисов
— Такой тест не дает достаточной гарантии от обсуждаемых проблем
— Даже такой тест — лучше подхода предлагаемого вами

>А есть более приемлимые подходы? Поделись, очень любопытно.
Конечно есть. Даже тот тест, что вы же и написали — уже более удачный вариант.

>Не одно и то же, а связанные понятия — одно без другого не работает.
Друг мой, не надо отказываться от своих слов. Вы даже меня пытались обвинять в отсутствии гибгости мышления из-за того, что я отказываюсь считать одним и тем же, эти два связанных понятия.

>Повторяю ещё раз. Мы тестируем ситуацию утечек дискового пространства в нашем CI, но как такового теста, который ты принялся называть тестом — нет. Нет кода аналогичного тому, который Вы соблаговолили заставить меня написать. Что непонятного-то?
Иллюстрирую:
цитата 1 — ""тест" тоже существует, который ты заставил меня написать"
цитата 2 — "как такового теста, который ты принялся называть тестом — нет"
так все-таки, существует или нет?

>Ещё раз напоминаю. У нас нет "диска CI", у нас кластер с тучей разных сервисов, да ещё и разные разделы дисков. Поэтому нужно контолировать не одну константу, а штук сто. А ещё есть staging envs, а ещё perf-test envs, и ВНЕЗАПНО констант становится уже под тысячу.
Еще веселее — то есть вам проще контролировать "под тысячу" дисковых конфигураций, чем констант? ))
Не говоря уже о том, что константа по прежнему одна, вне зависимости от количества конфигураций. Нам же важен один и тот же параметр, вне зависимости окружения и настроек. А уж если у нас такая экзотика, что в каких-то случаях этот параметр должен отличаться — то тут уж вообще без теста никак, иначе устанешь окрушение подгонять.

Здравствуйте, ·, Вы писали:

I>>цитирую себя "регрессию нужно детектить автотестами"
I>>снова цитирую себя "новые баги ищутся только руками"
·>Если уже есть авто-тесты, то искать только руками — глупо. Автотесты будут делать 90% действий, а остальной 10% — уже исследование для поиска, и это не ручные тесты, а exploratory.

exploratory это просто одна из методик вместе со smoke, ad hoc и тд. У ней особенность "simultaneous learning, test design and test execution". Это снова вики, раз ты веришь только ей.
Кроме того, читаем внимательно "http://www.satisfice.com/articles/what_is_et.shtml"
Ты видишь, что exploratory противопоставляется scripted ?
Более того, exploratory может выполняться с помощью кода, но в большинстве случаев это ручное кликанье.

I>>С т.з. юзера все выглядит узнаваемо, с т.з. автотестов это АДъ и Израиль. Кажды раз тебе надо переписывать 100500 тестов.
·>Я знаю что мне не надо. Если вам надо, то у вас что-то не то.

Ну тогда покажи один функциональный тест UI, который на раз протестирует фичу у которой одно и то же ядро, но разные морды. У первой — 3 радиобатона и кнопки OK Cancel, у второй — explorer like UI.

I>>Кто тебе сказал, что этажом выше ? Яндекс уже давно в разных городах и даже странах разработку ведёт.
·>А я в разных настроениях разработку веду. И позвонить по скайпу в другой город гораздо проще, чем мне вчерашнему.

Когда люди сидят вместе, им часто митинги не нужны, потому что и так все в теме. А когда в разных странах, то и митинги не помогают.

I>>

API никто в своём уме в ручную не тестирует.
·>Скажем, "если юзер использовал неверный пароль трижды при подключении к FIX API, то в Admin UI аккаунт должен нарисоваться заблокированным и об этом должна появиться запись аудита в отчёте." Это UI тест или API? Скажем, как вы вручную будете тестировать такую смесь?

Ты хорошо понял выделеное ?

I>>Это что, так трудно запомнить ? API используется программными модулями, для него естественные условия это вызов из программных модулей. Автотесты в этом случае наиболее близки к естественным условиям.
·>Мне трудно оценить скольо именно у нас тестов WUI, но интуитивно около 10%, т.е. 1000 тестов. И проблема в том, что просто "чисто тесты UI" получаются не так часто.

Чисто UI редко тестируется. Всегда тестируется основной функционал, но посредством UI.

I>>Если ты протестировал 20 а осталось еще 7980, это значит, что нужно ожидать целую кучу всякого непотребства. Появился новый девайс, автотесты красные, а все работает хорошо. Твои действия ?
·>Хорошо. А теперь сравни этот же сценарий с ручным подходом и объясни разницу. Откуда ты узнал, что _всё_ работает хорошо?

А глаза тебе для чего нужны ? Новые кейсы твои авто-тесты не найдут, в принципе. А вот глазами все видно — и лаёут, и функциональность и тд и тд.

I>>Или наоборот — всё зеленое, а UI надо переделывать, ибо выглядит коряво. Переделываем форму... и твои тесты отвалились все до единого. А живому человеку — пофигу.
·>Правильно. Это значит надо просмотреть все эти тесты и проверить — что живому человеку действительно пофигу. Как иначе ты узнаешь, что пофигу?

То есть, в кратце, твои тесты потребуют столько же ручной работы, как и обычное ручное тестирование.
Более того — их придется адаптировать для новой версии.

·>А вообще — это деструктивный подход, если какое-то изменение ломает сразу всё. Не надо так делать. С автотестами — ты это узнаешь, что изменение слишком глобальне. С ручным тестированием — ты просто находишься в счастливом неведении.

В UI у тебя никто не спросит, сколько тестов отвалится. Приходит реквест "заметить форму с радио-батонами на explorer-like UI".

I>>Принципиально ничем не отличается. Событие в одном компоненте транслируется в другие в одном случае чз унифицированый интерфейс, в другом — через кастомный.
·>Согласен. Если любой вызов метода обозвать евентом или "кастомной схемой навроде", то можно много глупостей навыдумывать.

На секундочку — если тебе сообщат о повышении ЗП запиской, значит ли это что записка и есть повышение ЗП ?

Так что не любой вызов метода. Событие это или изменение состояния или сигнал извне. Реакция на это событие реализуется по разному, может быть даже с помощью вызова метода.
Это никак не значит ,что событие и есть вызов метода или наоборот.

I>>А если ты прибил к реализации, то внезапно, после рефакторинга надо перелопачивать все тесты. То есть, патчить не код, что бы тесты стали зеленые, а патчить тесты, что бы стали зеленые.
I>>Оптимизация — ровно тоже самое.
·>Тестры — ровно такой же код. И рефакторится вместе с обычным кодом ровно так же. IDEA пофиг в скольки местах переименовать метод — в 5 или в 50. Тесты при рефакторинге остаются зелёные. По определению рефакторинга.

Переименование это слабый пример, он не меняет структуру кода. Вот рефакторинги, которые меняют структуру кода IDEA ничего такого не умеет. Она вообще такие рефакторинги не умеет.

I>>Сложную логику — практически всю. Сложное поведение — чем больше, тем лучше. Сложное взаимодействие — целиком.
·>В 90% ПО нет никакой сложной (не путаем с усложнённой) логики.

Есть. Просто есть люди, которые не в курсе формальных моделей. Эти же люди и являются носителями утверждений "Нам это не надо"

I>>В типичной разработке ошибок становится больше в зависимости от сложности, при чем зависимость сильно нелинейная. И вот эту самую сложную часть тесты ловят хуже некуда.
·>Если ты всё ещё о юнит-тестах, то юнит-тесты тестируют просты юниты. Сложная система собирается из протестированных юнитов и тестируется другими типами тестов.

Я о тестах вообще.

I>>Скажем, что бы качественно использовать автотесты верстки, нужен эталонный CSS процессор да с мега возможностями типа "закрывает ли какой контрол марджин вот этой мульки ?".
·>CSS это про UX. Неинтересно.

CSS это способ конструирования UI.

I>>Не надо никаких 500 страниц. Эти вещи постояно вылазят, ну по крайней мере в UI так. Чуть не любая форма на самом деле сложный автомат. Переходы, навигация унутре приложения == автомат. И тд
·>Так и UI тоже итеративно разрабатывается. Начинаешь с одной кнопки "сделать всё", а потом...

Давай на примере. Приложение — редактор конфигурации сети Ethernet. Валяй, покажи мне, куда здесь всунуть кнопку "сделать всё", когда к первому релизу должна быть внятная рисовалка.

I>>·>Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.
I>>Вот как раз для меняющихся требований это идеально работает. Убрал условие, добавил новое и всё.
·>Что всё? А вдруг это теперь конфликтует с другим бизнес-требованием, написанным 2 месяца назад? Как узнать?

1 такие вещи решаются бизнес-анализом и проектированием
2 если не помогло, будет регрессия.
Тебе напомнить, чем я предлагаю детектить регрессию ?

·>Зато ты об этом знаешь, что новое требование повлекло изменение поведения в старых ситуациях. А так — просто счастливое неведение и твои родимые reopen баги.

Успокойся — для регрессии и только для неё как раз и нужны автоматические тесты.

I>>И я об чем. Вещи которые трекер умеет искаропки вы заменили на ручной привод.
·>Для использования трекера требуются дополнительные усилия и затраты времени. А ещё проблема держать всё это актуальным. А выгоды — никакой.

Нет такой проблемы. Профит — возможность управления рисками, больше возможностей для планирования, точнее информация о состоянии проекта, о работоспособности команды и тд и тд и тд.

I>>Вашего трекера недостаточно. Истории не с нуля пишутся, а с изменением и использованием кода готовых компонентов.
·>Что недостаточно? Пусть с изменением, в чём проблема-то? Для регрессий есть тесты.

Я хочу знать, у кого из девелоперов больше реопенов, что бы знать, кому доверить ответственный таск.

I>>А при чем здесь овнершип код ? Вот сказали тебе авторизацию пофиксить, ты пофиксил. А потом в этом месте еще десяток реопенов вылез.
·>Я не понимаю откуда эти реопены твои любимые возьмутся? Они не вылезут, а просто упадёт десяток тестов — и фикс твой не пройдёт CI.

Это очевидно — автотесты не находят все баги. Всегда есть шанс, что ты внёс новый, критический для юзера кейс, который еще не покрыт тестом.

I>>На сервере ты никогда не вгружаешь вагоны данных целиком. Для UI это вобщем норма. Позволяет реализовать адские возможности в той же визуализации.
·>Зато искать лаги проще, не надо дебажить kernel, например.

Кое что — проще. Кое что — гораздо сложнее.

I>>Я могу тебе назвать не менее сотни багов связанных именно с логированием. Проявлялось именно в виде лагов в UI. Но вообще сильно уверен, что ты выдашь "просто вы не умеете..."
·>Если вы синхронно пишете текстовые логи на диск — логично. Лагать будет, багов — тонны. Если просто копится статистика в сотне int-переменных lock-free — то это наносекунды. Откуда лаги?

Такой статистики недостаточно. Нужно знать зачастую, что юзер делал последние пол-часа или больше, да что бы порядок сообщений не потерялся, и что бы всё это памяти не съело и тд и тд

I>>Немного обсчитался, но возможностей шины тебе по любому уже не хватает.
I>>1 2666 это пиковая. Реальная много меньше
·>Так вон уже на TbE замахиваются...

Пусть замахиваются. На текущий момент ты хочешь слишком многого. Твой метод экономически нецелесообразен.

I>>2 кроме UI есть и другие потребители шины
·>Кто? (мы вроде говорим о perf-test env)

Вся система, а приложение, к твоем сведение, не только из одного UI состоит.
Что бы 1мб данных кинуть с диска на экран, нужно по шине прогнать в 10-1000 раз больше.
Своп пока никто не отменял. GC — никто не отменял. Минимальная обработка данных — это пересылки по шине туда-сюда. Вот и выходит — шина жрётся не только в момент пересылки из памяти на видеокарту. 99% работы делается как раз ДО того.

I>>Более того, на данный момент в большинстве платформ тебе
I>>1 не хватит адресного пространства
·>Большинство это 16 бит или 32? По-моему уже даже мобильные платформы 64bit попёрли.

Мы про текущее положение дел. Большинство — 32 бита. 64 пока что кот наплакал.

I>>2 OS не сможет переварить данные если ап хватит
·>Человек и подавно.

Человеку не нужно пялиться в скрины 20к на 10к. Так что твоя идея снова экономически несостоятельная.

·>Соврешенно верно, повторюсь: Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.

Важно, что компьютер не умеет находить _новые_ баги.

·>Опять же.. UX или функциональных? Функционирование приложение при обновлении либы не должно меняться.

В пятрый раз повторяю — покажи этот чудесный функциональнгый тест, который одинаково хорошо работает как с радиобатонами, так и с explorer-like UI.

I>>А ты в курсе, что это _удорожает_ разработку ?
·>В курсе, конечно. Зато это удешевляет контроль качества.

Нисколько. Чуть выше ты дал советы навроде "давайте не будем менять UI если ломается много тестов". Таких идей не нужно.

I>>Кроме того, где гарантия, что тестопригодные средства вообще могут дать внятное решение ?
·>Если не могут — ищем компромисс. Иногда вообще отказываемся от истории.

Лучше сразу рассмотреть случай, когда отказ от истории == закрытие проекта.

I>>А твои авто-тесты надо полагать умеют работать на раз с кейсом "что-то пошло не так" ?

·>Конечно умеют — рисуют отчёт. Далее мы правим тест, чтобы там что-то шло не так как можно реже.

Логическая ошибка. Если умеют то не надо править тест. А если не умеют — надо.

I>>Нужно что бы ломались кейсы чувствительные для юзера. А вот добавление скрина в визард таким не является.
·>Такие "упавшие" тесты чинятся на раз. Быстро поднятое упавшим не считается.

Значит возвращаемся к случаю "радиобатоны -> explorer-like UI"

I>>И тем не менее Гугл лидер по количеству уродцев, при чем настолько, что во многих областях гуглу в принципе нельзя доверять.
·>Просто потому, что они могут это себе позволить.

Уже давно не могут. Нынче у них имидж тухлый.

·>Я, конечно, внутренности гугла не знаю, но вроде где-то вроде читал, что у них довольно плоская структура менеджмента.

Это было давно.

·>Истории с письмами и очередями в стеках — это когда всё построено на ручном тестировании. Ты предлагаешь изменение овнеру, а он сам не знает — что произойдёт, любое изменение — высокий риск. А значит он своих тестеров должен натравить, а у него тестеры и так под завязку загружены. Вот и начинается волынка...

Представь, появился кейс "давайте заменим радиобатоны на explorer-like UI"
Здесь, в кратце, надо подойти к QA-автоматчиками и сказать: "Ребята, вы молодцы !!! Выбрасывайте нахрен все ваши тесты по этой фиче"

I>>Это элементарно. Один из клиентов загоняет неверные данные, но сам рисует их корректно. Другой клиент их не может проглотить. Отсюда ясно, что нужен ответ сервера — кому что откуда пришло. Т.е. выяснить, чье подразделение сломало — тоже задача тестера.
·>Как это не может проглотить? А как же формальные модели?

Элементарно, обычные баги разработки, крайне вырожденные случаи. Когда всё намешано — такое вылазит на раз.
Ты наверное хочешь намекнуть, что _ваши_ автотесты такого никогда не пропускают ?

·>Вот кстати очень характеризует ваш подход. Вместо того чтобы сделать авто-тест с банальным if, вы процесс специальным образом делаете ручным

Банальный if не работает, когда билд-сервер используется совместно. Один билд удалился, другой в это время сожрал 1гб памяти. Твой if слился.

I>>Открой для себя прокси-сервер.
·>С ручным приводом? Это какой?

Для разработки/тестирования — web scarab, fiddler и тд и тд

I>>Это юзеров на софтварные модули заменить ? Интересная идея.
·>Попробуй, вдруг получится — продавать API, а не UI.

Я к этому абсолютно равнодушен.

Здравствуйте, IB, Вы писали:

>>Для сабжа — вполне, я рассуждал в контексте сабжа. Но в общем случае, ты прав, soak tests не могут решить все проблемы в жизни.
IB>Контекст "сабжа" совершенно ортогонален контексту применения soak тестов. Таким образом, совершенно спокойно может возникнуть ситуация, когда "сабж" возможен, а soak тест, чтобы его отловить к этому не прислонишь.
А разве можно что-то прислонить, чтобы такая ситуация возникнуть не могла в принципе?

>>По сравнению с чем? Если не тестировать вообще, то да, конечно. А если используешь ручное тестирование — проблемы те же, даже больше. Ибо вручную реально протестировать N конфигураций, а автоматически зачастую N * K, где K ≫ 1.
IB>Вы все время уплываете из контекста и начинаете спорить с выдуманными аргументами. Никто не предлагает отказываться от автотестов, там где это возможно. Речь про другое, про то что автотесты далеко не везде применимы и не все сценарии покрывают, а значит по прежнему остается пространство для возможных ошибок.
Допустим, я это и так прекрасно знаю — любой инструмент имеет границы применимости. И что делать? Тут предлагали ассерты, ручное тестирование и прочие смехотворные вещи, которое оставляет ещё большее пространство для ошибок. Так что делать-то? Ползти на кладбище?

Ситуация напоминает: мы тут построили сарай, а он развалился от неизвестного артефакта — шурупы повыпадали. Я говорю, что надо было взять отвёртку вместо кувалды, а мне тут начинают доказывать что отвёрткой сваи забивать невозможно, да и собранный сарай даже с использованием отвёртки может развалиться — вдруг ураганом снесёт или банально в пожаре сгорит.

>>Я не понимаю к чему это опять. Ты предлагаешь вообще не тестировать и факапить как яндекс?
IB>Все к тому же — у автотестов есть проблемы с применимостью. У вас какая-то странная логика — я лишь иллюстрирую проблемы автотестов, а вовсе не предлагаю от них отказаться.
Я предлагаю замену ручного тестирования автоматическим тестированием, чтобы сабжы практически не встречались, а мне тут говорят, что мол CSS, мол курсор не рисуется. Что за бред?
Я не понимаю что вы хотите сказать. Или просто доказать, что у нас авто-тестирование на самом деле не работает?

>>>>Мы сами принимаем решение — что основной, а что нет. И исходя из этого проектируем тесты. Поэтому, чисто по построению подход отлавливает всё.
IB>>>Вы сами найдете здесь логическую ошибку или подсказать?
>>Подскажи.
IB>Их тут даже две. Во-первых, из того факта, что вы принимаете решение вовсе не следует, что отлавливается все. А во-вторых, либо вы таки сортируете сценарии на основные и не основные, и тогда покрываются только основные сценарии, либо чего вы там решаете — вообще не важно (но то что это утопичный случай, надеюсь понимаете даже вы =) ).
Во-первых, всё никогда не будет отлавливаться. Ты требуешь теоретически невозможного. Во-вторых, основные же не от балды, а от критичности для бизнеса. Критически важные сценарии — покрываются.

>>Я тогда не понимаю почему тебе было так необходимо, чтобы я выдал тот код?
IB>Прежде всего, не обязательно вы — это чтобы явно указать, что конкретные персоналии меня мало тревожат. Тем не менее, этот код позволил наглядно проиллюстрировать пару тезисов
IB>- Такой тест не дает достаточной гарантии от обсуждаемых проблем
А тут сразу возникает два вопроса: Достаточной для чего? А что даёт бОльшую гарантию?

IB>- Даже такой тест — лучше подхода предлагаемого вами
Лучше, но не намного. Единственное чем лучше — сразу точно репортит проблему. Но ценность такого улучшения не покрывает бОльших затрат на его реализацию.

>>А есть более приемлимые подходы? Поделись, очень любопытно.
IB>Конечно есть. Даже тот тест, что вы же и написали — уже более удачный вариант.
Он имеет смысл только в тривиальных случаях.

>>Повторяю ещё раз. Мы тестируем ситуацию утечек дискового пространства в нашем CI, но как такового теста, который ты принялся называть тестом — нет. Нет кода аналогичного тому, который Вы соблаговолили заставить меня написать. Что непонятного-то?
IB>Иллюстрирую:
IB>цитата 1 — ""тест" тоже существует, который ты заставил меня написать"
IB>цитата 2 — "как такового теста, который ты принялся называть тестом — нет"
IB>так все-таки, существует или нет?
Ещё раз. Зависит от того, что ты вкладываешь в значение термина. Ещё раз. Прочитай ОЧЕНЬ внимательно, приглядываясь к каждому слову и символу:
У нас проверка утечек диска проверяется в процессе тестирования за счёт организации тестового окружения. У нас нет специального кода, который делает проверки аналогичные проверкам в приведённом мною тестирующем коде.
Теста не существует, но тестируется. Здесь "тест" — тест в твоём понимании.
В моём понимании, если что-то тестируется, то тест у нас есть, остальное — детали реализации.

>>Ещё раз напоминаю. У нас нет "диска CI", у нас кластер с тучей разных сервисов, да ещё и разные разделы дисков. Поэтому нужно контолировать не одну константу, а штук сто. А ещё есть staging envs, а ещё perf-test envs, и ВНЕЗАПНО констант становится уже под тысячу.
IB>Еще веселее — то есть вам проще контролировать "под тысячу" дисковых конфигураций, чем констант? ))
Естественно. Админы не зря свой хлеб едят. Они там свои железки и провода таскают, puppet скрипты ваяют.
Написание ещё и тестирующего кода — будет тупым повторением того, что уже и так есть в puppet-скриптах и используемом железе.

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

Здравствуйте, Ikemefula, Вы писали:

I>>>цитирую себя "регрессию нужно детектить автотестами"
I>>>снова цитирую себя "новые баги ищутся только руками"
I>Более того, exploratory может выполняться с помощью кода, но в большинстве случаев это ручное кликанье.
А ты уже стал сам себе противоречить:
"новые баги ищутся только руками" != "exploratory может выполняться с помощью кода"
Хотя я надеюсь, что это не противоречие, а ты наконец-то поменял своё мнение.
Т.е. ты уже согласен с собой, что новые баги таки хотя бы иногда можно найти с помощью кода. Теперь осталось понять, что при желании большинство новых багов (по крайней мере некоторого массивного класса) можно таки находить с помощью кода.

I>>>С т.з. юзера все выглядит узнаваемо, с т.з. автотестов это АДъ и Израиль. Кажды раз тебе надо переписывать 100500 тестов.
I>·>Я знаю что мне не надо. Если вам надо, то у вас что-то не то.
I>Ну тогда покажи один функциональный тест UI, который на раз протестирует фичу у которой одно и то же ядро, но разные морды. У первой — 3 радиобатона и кнопки OK Cancel, у второй — explorer like UI.
Почему один? Две морды — два теста. Человек же не может одним тестом тестировать две морды. Почему ты это требуешь от автотеста?

I>>>Кто тебе сказал, что этажом выше ? Яндекс уже давно в разных городах и даже странах разработку ведёт.
I>·>А я в разных настроениях разработку веду. И позвонить по скайпу в другой город гораздо проще, чем мне вчерашнему.
I>Когда люди сидят вместе, им часто митинги не нужны, потому что и так все в теме. А когда в разных странах, то и митинги не помогают.
Я не могу сидеть с собой вчерашним... Вчерашний я не только может быть в другой стране, но и очевидно в другом времени.

I>>>

API никто в своём уме в ручную не тестирует.
I>·>Скажем, "если юзер использовал неверный пароль трижды при подключении к FIX API, то в Admin UI аккаунт должен нарисоваться заблокированным и об этом должна появиться запись аудита в отчёте." Это UI тест или API? Скажем, как вы вручную будете тестировать такую смесь?
I>Ты хорошо понял выделеное ?
Так это как бы тест UI, но чтобы на UI отобразились необходимые изменения нужно обратиться к API. Что делать?

I>>>Это что, так трудно запомнить ? API используется программными модулями, для него естественные условия это вызов из программных модулей. Автотесты в этом случае наиболее близки к естественным условиям.
I>·>Мне трудно оценить скольо именно у нас тестов WUI, но интуитивно около 10%, т.е. 1000 тестов. И проблема в том, что просто "чисто тесты UI" получаются не так часто.
I>Чисто UI редко тестируется. Всегда тестируется основной функционал, но посредством UI.
Я имею в виду тестируется функционирование UI, при этом некоторые функции в UI никак не представлены, но влияние на UI оказывают. Что делать?

I>>>Если ты протестировал 20 а осталось еще 7980, это значит, что нужно ожидать целую кучу всякого непотребства. Появился новый девайс, автотесты красные, а все работает хорошо. Твои действия ?
I>·>Хорошо. А теперь сравни этот же сценарий с ручным подходом и объясни разницу. Откуда ты узнал, что _всё_ работает хорошо?
I>А глаза тебе для чего нужны ? Новые кейсы твои авто-тесты не найдут, в принципе. А вот глазами все видно — и лаёут, и функциональность и тд и тд.
Ты что-то не понимаешь или не то говоришь. Давай подробно. У нас есть приложение. 1000 форм. У нас в спеке написано, что мы контролируем качество на 20 девайсах. Два варианта развития событий, начальное состояние:
1. Делаем ручные тесты. 1000 форм * 20 девайсов. Выполняем их перед каждым релизом, занимает четыре недели.
2. Делаем авто-тесты. 1000 форм * 20 девайсов. Выполняем их каждые ~пять коммитов, занимает 20 минут.
Появляется новое устройство. Что получается:
1. Делаем ручные тесты. Плюс ещё 1000 форм каждый раз проверять глазами, перед каждым релизом.
2. Делаем авто-тесты. Упало N тестов, где N <= 1000. Проверить один раз N форм глазами.

Каким образом вариант 1 может быть лучше варианта 2?

I>>>Или наоборот — всё зеленое, а UI надо переделывать, ибо выглядит коряво. Переделываем форму... и твои тесты отвалились все до единого. А живому человеку — пофигу.
I>·>Правильно. Это значит надо просмотреть все эти тесты и проверить — что живому человеку действительно пофигу. Как иначе ты узнаешь, что пофигу?
I>То есть, в кратце, твои тесты потребуют столько же ручной работы, как и обычное ручное тестирование.
В худшем случае — ровно столько же. В реальных ситуациях — на порядки меньше.

I>Более того — их придется адаптировать для новой версии.
Тесты не адаптируют, а изменяют одновременно при внесении изменений в версию. При получении "новой версии" — тесты уже работают и к моменту релиза уже были запущены много-много раз.

I>·>А вообще — это деструктивный подход, если какое-то изменение ломает сразу всё. Не надо так делать. С автотестами — ты это узнаешь, что изменение слишком глобальне. С ручным тестированием — ты просто находишься в счастливом неведении.
I>В UI у тебя никто не спросит, сколько тестов отвалится. Приходит реквест "заметить форму с радио-батонами на explorer-like UI".
Так замени — одновременно с изменением теста. Если упадут другие тесты, которые ты забыл изменить — сразу узнаешь что ты сломал.

I>>>Принципиально ничем не отличается. Событие в одном компоненте транслируется в другие в одном случае чз унифицированый интерфейс, в другом — через кастомный.
I>·>Согласен. Если любой вызов метода обозвать евентом или "кастомной схемой навроде", то можно много глупостей навыдумывать.
I>На секундочку — если тебе сообщат о повышении ЗП запиской, значит ли это что записка и есть повышение ЗП ?
Продолжаешь выдумывать глупости?

I>Так что не любой вызов метода. Событие это или изменение состояния или сигнал извне. Реакция на это событие реализуется по разному, может быть даже с помощью вызова метода.
I>Это никак не значит ,что событие и есть вызов метода или наоборот.
Хорошо. Но уже лучше. Ещё пойми, что событие (event) не есть обработчик события (event handler, callback) или наоборот. А ещё вспомни и расскажи к чему ты вообще помянул события.

I>>>Оптимизация — ровно тоже самое.
I>·>Тестры — ровно такой же код. И рефакторится вместе с обычным кодом ровно так же. IDEA пофиг в скольки местах переименовать метод — в 5 или в 50. Тесты при рефакторинге остаются зелёные. По определению рефакторинга.
I>Переименование это слабый пример, он не меняет структуру кода. Вот рефакторинги, которые меняют структуру кода IDEA ничего такого не умеет. Она вообще такие рефакторинги не умеет.
Извлечение|инлайн метода. Извлечение|инлайн интерфейса. Удаление|добавление|перестановка параметров. Замена конструктора на Builder. Выделение группы полей в класс. Замена наследования на делегирование. И прочее — всё меняет структуру кода.
Да в общем не важно что умеет IDEA, любой рефакторинг по определению не меняет поведение кода, а значит должен оставлять тесты зелёными.

I>>>Сложную логику — практически всю. Сложное поведение — чем больше, тем лучше. Сложное взаимодействие — целиком.
I>·>В 90% ПО нет никакой сложной (не путаем с усложнённой) логики.
I>Есть. Просто есть люди, которые не в курсе формальных моделей. Эти же люди и являются носителями утверждений "Нам это не надо"
Не понял. Был простой код, ввели формальную модель и стал сложным? А накой?

I>>>Скажем, что бы качественно использовать автотесты верстки, нужен эталонный CSS процессор да с мега возможностями типа "закрывает ли какой контрол марджин вот этой мульки ?".
I>·>CSS это про UX. Неинтересно.
I>CSS это способ конструирования UI.
И что?

I>>>Не надо никаких 500 страниц. Эти вещи постояно вылазят, ну по крайней мере в UI так. Чуть не любая форма на самом деле сложный автомат. Переходы, навигация унутре приложения == автомат. И тд
I>·>Так и UI тоже итеративно разрабатывается. Начинаешь с одной кнопки "сделать всё", а потом...
I>Давай на примере. Приложение — редактор конфигурации сети Ethernet. Валяй, покажи мне, куда здесь всунуть кнопку "сделать всё", когда к первому релизу должна быть внятная рисовалка.
Тесты пишутся не к релизу, а во время написания основного кода.
Вот тебе самый первый тест "сделать всё": Приложение можно запустить, у окна должен быть заголовок "редактор конфигурации сети Ethernet", нажать кнопку "exit" — приложение должно завершиться. И это уже можно показывать заказчику!
Дальше — за деньги, ибо составление техзаданий вещь не бесплатная.

I>>>·>Для постоянно меняющихся бизнес-требований? Сомнительно... В общем сильно зависит от задач.
I>>>Вот как раз для меняющихся требований это идеально работает. Убрал условие, добавил новое и всё.
I>·>Что всё? А вдруг это теперь конфликтует с другим бизнес-требованием, написанным 2 месяца назад? Как узнать?
I>1 такие вещи решаются бизнес-анализом и проектированием
I>2 если не помогло, будет регрессия.
I>Тебе напомнить, чем я предлагаю детектить регрессию ?
Напомни. Юнит-тесты ты вроде не признаёшь. А без них остальные авто-тесты могут быть слишком долгими.

I>>>И я об чем. Вещи которые трекер умеет искаропки вы заменили на ручной привод.
I>·>Для использования трекера требуются дополнительные усилия и затраты времени. А ещё проблема держать всё это актуальным. А выгоды — никакой.
I>Нет такой проблемы. Профит — возможность управления рисками, больше возможностей для планирования, точнее информация о состоянии проекта, о работоспособности команды и тд и тд и тд.
Мы используем другие инструменты. Истории у нас описываются бизнес-аналитиками в планировщике, девы и тестеры их только читают, используя как спеку для кода и тестов. Проблемы (issues) описываются client support team и девы и тестеры используют их как основу для изменения кода и тестов. Многие зарепорченные проблемы тупо преобразуются в истории, т.к. обычно просто новая функциональность. Как ни извращённо это звучит, но для планирования мы используем планировщик, а для трекига проблем — issue трекер.

I>>>Вашего трекера недостаточно. Истории не с нуля пишутся, а с изменением и использованием кода готовых компонентов.
I>·>Что недостаточно? Пусть с изменением, в чём проблема-то? Для регрессий есть тесты.
I>Я хочу знать, у кого из девелоперов больше реопенов, что бы знать, кому доверить ответственный таск.
У нас нет реопенов, откуда они возьмутся-то? А ответственный таск мы обычно доверяем паре, а то и нескольким.

I>>>А при чем здесь овнершип код ? Вот сказали тебе авторизацию пофиксить, ты пофиксил. А потом в этом месте еще десяток реопенов вылез.
I>·>Я не понимаю откуда эти реопены твои любимые возьмутся? Они не вылезут, а просто упадёт десяток тестов — и фикс твой не пройдёт CI.
I>Это очевидно — автотесты не находят все баги. Всегда есть шанс, что ты внёс новый, критический для юзера кейс, который еще не покрыт тестом.
А что находит все баги? Что не оставляешь шанса внести новый критический кейс?

I>·>Зато искать лаги проще, не надо дебажить kernel, например.
I>Кое что — проще. Кое что — гораздо сложнее.
В общем да, согласен.

I>>>Я могу тебе назвать не менее сотни багов связанных именно с логированием. Проявлялось именно в виде лагов в UI. Но вообще сильно уверен, что ты выдашь "просто вы не умеете..."
I>·>Если вы синхронно пишете текстовые логи на диск — логично. Лагать будет, багов — тонны. Если просто копится статистика в сотне int-переменных lock-free — то это наносекунды. Откуда лаги?
I>Такой статистики недостаточно. Нужно знать зачастую, что юзер делал последние пол-часа или больше, да что бы порядок сообщений не потерялся, и что бы всё это памяти не съело и тд и тд
пиши в сеть, сохраняй на терабайтный винт.
Мы пишем всё... финансы однако. И тут не последние пол-часа, а последние 5 лет. И не "нужно знать зачастую", а обязаны по закону. А с порядком сообщений вообще швах. Ибо кластер, репликация, DR... И всё это не жалкая сотня сообщений от мыши, а как минимум тысяча, а в пиках до 20тыс. Т.е. одно сообщение каждые 50 микросекунд.
А статистика это просто для мониторинга и анализа производительности.

I>>>Немного обсчитался, но возможностей шины тебе по любому уже не хватает.
I>>>1 2666 это пиковая. Реальная много меньше
I>·>Так вон уже на TbE замахиваются...
I>Пусть замахиваются. На текущий момент ты хочешь слишком многого. Твой метод экономически нецелесообразен.
По сравнению с чем?

I>·>Кто? (мы вроде говорим о perf-test env)
I>Вся система, а приложение, к твоем сведение, не только из одного UI состоит.
I>Что бы 1мб данных кинуть с диска на экран, нужно по шине прогнать в 10-1000 раз больше.
I>Своп пока никто не отменял. GC — никто не отменял. Минимальная обработка данных — это пересылки по шине туда-сюда. Вот и выходит — шина жрётся не только в момент пересылки из памяти на видеокарту. 99% работы делается как раз ДО того.
И мы вроде начали с системы скриптования тестов. И сколько она добавит оверхеда? Хоть сотая доля процента наберётся?

I>>>Более того, на данный момент в большинстве платформ тебе
I>>>1 не хватит адресного пространства
I>·>Большинство это 16 бит или 32? По-моему уже даже мобильные платформы 64bit попёрли.
I>Мы про текущее положение дел. Большинство — 32 бита. 64 пока что кот наплакал.
Мы вроде об авто-тестах... Для стресс-тестов уж можно на одну 64-битную железяку раскошелиться.

I>Человеку не нужно пялиться в скрины 20к на 10к. Так что твоя идея снова экономически несостоятельная.
Мы о тестах или опять о космических кораблях?

I>·>Соврешенно верно, повторюсь: Но это не важно, важно то, что компьютер может обрабатывать на несколько порядков больше и быстрее чем человек.
I>Важно, что компьютер не умеет находить _новые_ баги.
Компьютер ничего не умеет. Что скажешь, то и будет делать.

I>·>Опять же.. UX или функциональных? Функционирование приложение при обновлении либы не должно меняться.
I>В пятрый раз повторяю — покажи этот чудесный функциональнгый тест, который одинаково хорошо работает как с радиобатонами, так и с explorer-like UI.
Функциональный тест UI тестирует функционирование UI. Радиобатоны и explorer-like это UI и они должны ожидаемо функционировать. В чём проблема писать тесты для них?

I>>>А ты в курсе, что это _удорожает_ разработку ?
I>·>В курсе, конечно. Зато это удешевляет контроль качества.
I>Нисколько. Чуть выше ты дал советы навроде "давайте не будем менять UI если ломается много тестов". Таких идей не нужно.
Я не давал такие советы. Это ты откуда-то сам взял. Я давал совет: не меняйте так, чтобы ломалось слишком много. Локально, маленькими итерациями, частыми коммитами, постепенно вносим изменения, меняя параллельно тесты. Слона надо есть по кусочкам.

I>>>Кроме того, где гарантия, что тестопригодные средства вообще могут дать внятное решение ?
I>·>Если не могут — ищем компромисс. Иногда вообще отказываемся от истории.
I>Лучше сразу рассмотреть случай, когда отказ от истории == закрытие проекта.
Ищем компромисс же.

I>>>А твои авто-тесты надо полагать умеют работать на раз с кейсом "что-то пошло не так" ?

I>·>Конечно умеют — рисуют отчёт. Далее мы правим тест, чтобы там что-то шло не так как можно реже.
I>Логическая ошибка. Если умеют то не надо править тест. А если не умеют — надо.
Эээ. В чём ошибка? Умеют — справятся, не умеют — научим. Но одно дело учить тест, который потом будет всегда работать, а другое дело учить тестеров, которые бывают увольняются, нанимаются и т.п.

I>>>Нужно что бы ломались кейсы чувствительные для юзера. А вот добавление скрина в визард таким не является.
I>·>Такие "упавшие" тесты чинятся на раз. Быстро поднятое упавшим не считается.
I>Значит возвращаемся к случаю "радиобатоны -> explorer-like UI"
Ок. Как я понимаю сценарий: есть форма с радиобатонами. Фич-ревест — переделать её в explorer like UI.
Как мы действуем: Смотрим сущестующе тесты радиобатонного UI. Каждый тест — некий юзкейс. Тестеры изучают каждый из них и пишут новый тест, аналогичный каждому сценарию. Очевидно, маппинг будет не 1к1, можно будет заметить, что некоторые сценарии могут измениться, какие-то вовсе исчезнуть, какие-то новые появиться. Все эти новые тесты помечаются в коде как WiP. В это же время девы добавляют feature toggle (булевый флажок, который будет определять публичность фичи). По умолчанию true, в prod — false. Флажок так же определяет какой из наборов тестов будет выполняться — старый или новый. Затем собственно начинают рисовать новый UI, постепенно снимая пометки WiP с тестов. Когда тестеры заявят, что все тесты написаны, а в коде не останется WiP, можно поменять флажок в true и следующий ближайший публичный релиз увидит новую фичу. После какого-то времени, если фича всем понравилась и всё прошло хорошо, удаляем флажок и все участки кода для значения false. Вуаля. И никаких упавших тестов вообще. Релиз новой фичи заключается в изменении одной строчки кода с false на true.

I>>>И тем не менее Гугл лидер по количеству уродцев, при чем настолько, что во многих областях гуглу в принципе нельзя доверять.
I>·>Просто потому, что они могут это себе позволить.
I>Уже давно не могут. Нынче у них имидж тухлый.
По сравнению с кем?

I>·>Истории с письмами и очередями в стеках — это когда всё построено на ручном тестировании. Ты предлагаешь изменение овнеру, а он сам не знает — что произойдёт, любое изменение — высокий риск. А значит он своих тестеров должен натравить, а у него тестеры и так под завязку загружены. Вот и начинается волынка...
I>Представь, появился кейс "давайте заменим радиобатоны на explorer-like UI"
I>Здесь, в кратце, надо подойти к QA-автоматчиками и сказать: "Ребята, вы молодцы !!! Выбрасывайте нахрен все ваши тесты по этой фиче"
Да пожалуйста, но только после того как замена пройдёт полностью успешно.

I>>>Это элементарно. Один из клиентов загоняет неверные данные, но сам рисует их корректно. Другой клиент их не может проглотить. Отсюда ясно, что нужен ответ сервера — кому что откуда пришло. Т.е. выяснить, чье подразделение сломало — тоже задача тестера.
I>·>Как это не может проглотить? А как же формальные модели?
I>Элементарно, обычные баги разработки, крайне вырожденные случаи. Когда всё намешано — такое вылазит на раз.
I>Ты наверное хочешь намекнуть, что _ваши_ автотесты такого никогда не пропускают ?
Если только какой-нибудь gson/jackson сглючит только. Иначе как ещё можно сформировать невалидный json, да ещё в зависимости от клиента...

I>·>Вот кстати очень характеризует ваш подход. Вместо того чтобы сделать авто-тест с банальным if, вы процесс специальным образом делаете ручным
I>Банальный if не работает, когда билд-сервер используется совместно. Один билд удалился, другой в это время сожрал 1гб памяти. Твой if слился.
Как это? В смысле ты меряешь погоду на марсе и общее место на диске? При этом пуская несколько билдов одновременно на том же диске? Так не надо так делать, очевидно.

I>>>Открой для себя прокси-сервер.
I>·>С ручным приводом? Это какой?
I>Для разработки/тестирования — web scarab, fiddler и тд и тд
А причём тут веб? Сеть вебом не ограничивается. Интересно как ты фиддлером будешь ловить udp трафик. А для веба селениум есть, гораздо мощнее чем с проксями мучиться.

Здравствуйте, ·, Вы писали:

·>Функциональный тест UI тестирует функционирование UI. Радиобатоны и explorer-like это UI и они должны ожидаемо функционировать. В чём проблема писать тесты для них?
Допустим, у нас есть некое десктоп (подразумевающее десктопный look&feel) приложение с кнопкой.

Тест кейс (или "как оно должно быть") выглядит так:
1. При клике на кнопку "главной" (пусть это будет левая) кнопкой мыши (но не отпускании при этом кнопки мыши)
кнопка должна перейти в состоянии "нажато", но привязанной к ней команды не должно выполняться;
2. При перемещении курсора за область кнопки ("главная" кнопка мыши всё ещё нажата), кнопка должна перейти в
состояние "не нажато", и если отпускаем кнопку мыши, то привязанной к кнопке команды не должно выполняться;
3. При перемещении курсора обратно из области, не принадлежащей кнопке, в область кнопки, кнопка переходит
в состояние нажато и при "отжатии" кнопки действие, привязанное к кнопке выполнится.

Каким образом можно протестировать обычную кнопку функциональным тестом, если у неё нет "вывешенного наружу" функционала для тестирования?

Здравствуйте, ·, Вы писали:

[]

I>>Если сложно — можно проще. Есть ровно один контрол — текст бокс. Он пустой. Юзер жмёт backspase. Валяй, список тестов в студию. Здесь уже нужен мануальный контроль, потому что ты не знаешь, чего ожидать.

·>Если вы пишете GUI control library, то да, должен быть тест testBoxUnderTest.setContent("").sendKeystroke(BACKSPACE), в чём проблема? Если вы пишете очередной диалог, то тестировать уже протестированные контролы — странный подход (или вы не доверяете разработчикам GUI-библиотеки?).

При этом по ~~воле бога~~факапа разработчика форма, на которой ровно один контрол оказалась не в фокусе клавы и бэкспейс ушел не в текст бокс от разработчиков GUI-библиотеки, которым мы доверяем, а в основное окно, где и отработал штатным образом, что в целом в этой ситуации нихера не штатно. Это как, например, после прогона VTuna'ом на слабенькой машинке ждешь открытия результатов, и решаешь во время этого неспешного процесса по-редактировать файл — blah-blah DEL — упс, результат прогона VTuna удалился из solution. Убил бы ...

Здравствуйте, Venom, Вы писали:

V>Допустим, у нас есть некое десктоп (подразумевающее десктопный look&feel) приложение с кнопкой.

V>Тест кейс (или "как оно должно быть") выглядит так:
V>1. При клике на кнопку "главной" (пусть это будет левая) кнопкой мыши (но не отпускании при этом кнопки мыши)
V>кнопка должна перейти в состоянии "нажато", но привязанной к ней команды не должно выполняться;
V>2. При перемещении курсора за область кнопки ("главная" кнопка мыши всё ещё нажата), кнопка должна перейти в
V>состояние "не нажато", и если отпускаем кнопку мыши, то привязанной к кнопке команды не должно выполняться;
V>3. При перемещении курсора обратно из области, не принадлежащей кнопке, в область кнопки, кнопка переходит
V>в состояние нажато и при "отжатии" кнопки действие, привязанное к кнопке выполнится.

V>Каким образом можно протестировать обычную кнопку функциональным тестом, если у неё нет "вывешенного наружу" функционала для тестирования?
Узнавать состояние, если явно не получится (т.е. нет явного способа проверить isPushed), то можно например попробовать состряпать специальный тестовый l&f — рисовать каждое состояние кнопки отдельным цветом. Тогда можно просто отредерить кнопку в битмап и проверить каким цветом она нарисовалась.
В особо запущенных случаях можно дойти до дизассемблирования и чтения приватных полей через рефлексию|прочие хаки.
Но это крайний случай, ведь если мы берём чужую библиотеку кнопок, то не наше дело тестировать чужой код, только случай, если библиотека нам позарез нужна, исходников нет, а полагаться на качество не можем.

Если мы пишем контрол сами, то в чём проблемо вывесить наружу функционал, который можно использовать при тестировании?

Мы не будем тестировать look&feel, т.к. это UX, а будем тестировать функциональность. Функциональность от l&f зависеть не должна.
Поэтому нужно найти способ узнавать состояние кнопки и найти способ изменять её состояние.
Для изменения состояния нам нужно научиться посылать ей события программно. Например, я смотрю на QT и там есть QPushButton::event(QEvent * e), т.е. конструируешь в тесте QMouseEvent и шлёшь его твоей кнопке.

Здравствуйте, ·, Вы писали:

I>>>>снова цитирую себя "новые баги ищутся только руками"
I>>Более того, exploratory может выполняться с помощью кода, но в большинстве случаев это ручное кликанье.
·>А ты уже стал сам себе противоречить:
·>"новые баги ищутся только руками" != "exploratory может выполняться с помощью кода"

Может. Нет противоречия. _Типичный_ exploratory это ручной. Из этого не следует, что все exploratory исключительно ручные.

·>Т.е. ты уже согласен с собой, что новые баги таки хотя бы иногда можно найти с помощью кода.

Объясни внятно — каким образом девелопер напишет тест на ту часть, которую он упустил из рассмотрения ?

I>>Ну тогда покажи один функциональный тест UI, который на раз протестирует фичу у которой одно и то же ядро, но разные морды. У первой — 3 радиобатона и кнопки OK Cancel, у второй — explorer like UI.
·>Почему один? Две морды — два теста. Человек же не может одним тестом тестировать две морды. Почему ты это требуешь от автотеста?

Потому что первый вариант больше никому не нужен.

I>>Когда люди сидят вместе, им часто митинги не нужны, потому что и так все в теме. А когда в разных странах, то и митинги не помогают.
·>Я не могу сидеть с собой вчерашним... Вчерашний я не только может быть в другой стране, но и очевидно в другом времени.

Ну то есть ты одновременно присутствуешь во всех офисах на всех континентах одновременно ?
А то ведь либа может пилиться где нибудь за Уралом, а навигатор, скажем, в Москве.

I>>Ты хорошо понял выделеное ?
·>Так это как бы тест UI, но чтобы на UI отобразились необходимые изменения нужно обратиться к API. Что делать?

В одном месте скрипты навроде "очистить базу", в другом — UI для тестирования. И то и другое вызывается мышом.

I>>Чисто UI редко тестируется. Всегда тестируется основной функционал, но посредством UI.
·>Я имею в виду тестируется функционирование UI, при этом некоторые функции в UI никак не представлены, но влияние на UI оказывают. Что делать?

Это из области фантастики или случай выше.

·>1. Делаем ручные тесты. 1000 форм * 20 девайсов. Выполняем их перед каждым релизом, занимает четыре недели.
·>2. Делаем авто-тесты. 1000 форм * 20 девайсов. Выполняем их каждые ~пять коммитов, занимает 20 минут.

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.

·>Появляется новое устройство. Что получается:
·>1. Делаем ручные тесты. Плюс ещё 1000 форм каждый раз проверять глазами, перед каждым релизом.
·>2. Делаем авто-тесты. Упало N тестов, где N <= 1000. Проверить один раз N форм глазами.
·>Каким образом вариант 1 может быть лучше варианта 2?

Во первых, ты забыл, что про регрессию обсудили — для неё нужны автотесты
Во вторых, ты забыл что надо пофиксить все красные, а не просто посмотреть
Во третьих, ты забыл что зеленые тоже возможно придется фиксить, потому что новый девайс == новые неучтенные кейсы.

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.

I>>То есть, в кратце, твои тесты потребуют столько же ручной работы, как и обычное ручное тестирование.
·>В худшем случае — ровно столько же. В реальных ситуациях — на порядки меньше.

В реальных ситуациях ручное применяется в обязательном порядке. Никто не отдаёт прогу в релиз, если она прошла автоматические тесты.
Никто и никогда, кроме отмороженых на всю голову индусо-контор.

I>>Более того — их придется адаптировать для новой версии.
·>Тесты не адаптируют, а изменяют одновременно при внесении изменений в версию. При получении "новой версии" — тесты уже работают и к моменту релиза уже были запущены много-много раз.

Ну вот покажи адаптацию для случая "радиобатоны -> explorer-like UI"

I>>В UI у тебя никто не спросит, сколько тестов отвалится. Приходит реквест "заметить форму с радио-батонами на explorer-like UI".
·>Так замени — одновременно с изменением теста. Если упадут другие тесты, которые ты забыл изменить — сразу узнаешь что ты сломал.

"измени" это значит выбросить всё и написать заново.

I>>Переименование это слабый пример, он не меняет структуру кода. Вот рефакторинги, которые меняют структуру кода IDEA ничего такого не умеет. Она вообще такие рефакторинги не умеет.
·>Извлечение|инлайн метода. Извлечение|инлайн интерфейса. Удаление|добавление|перестановка параметров. Замена конструктора на Builder. Выделение группы полей в класс. Замена наследования на делегирование. И прочее — всё меняет структуру кода.

Это небольшой набор частных случаев. Покажи мне, как IDEA сможет устранить дублирование в таком случае — есть 10 похожих методов, надо заменить тело каждого на вызов одного универсального с разными параметрами.

·>Да в общем не важно что умеет IDEA, любой рефакторинг по определению не меняет поведение кода, а значит должен оставлять тесты зелёными.

Наблюдаемое поведение — это _вызов_ метода
Место вызова — не есть поведение.
Ты хочешь не только вызов детектить, но и само место. То есть, у тебя по определению НЕ юнит тест. И никогда им не будет.

I>>Есть. Просто есть люди, которые не в курсе формальных моделей. Эти же люди и являются носителями утверждений "Нам это не надо"
·>Не понял. Был простой код, ввели формальную модель и стал сложным? А накой?

Простой для кого ? Для тебя, для джуниора который будет фиксить, для новчика в проекте, который пришел совсем из другой области, для человека, у которого в 10 раз больше опыта чем у тебя ?

I>>·>CSS это про UX. Неинтересно.
I>>CSS это способ конструирования UI.
·>И что?

Ты UX тащишь куда попало. Ощущение, что у тебя всё что связано с UI это "UX, тестировать не надо"
CSS сейчас используется для реализации функциональности, а не просто для раскраски.
Нет никакой разницы между "девелопер забыл добавить кнопку" и "написал не тот стиль и кнопка не видна"
БОлее того, "кнопка ничего не делает" и "у кнопки не тот стиль" это абсолютно одно и то же — ФУНКЦИОНАЛ НЕ РАБОТАЕТ

·>Вот тебе самый первый тест "сделать всё": Приложение можно запустить, у окна должен быть заголовок "редактор конфигурации сети Ethernet", нажать кнопку "exit" — приложение должно завершиться. И это уже можно показывать заказчику!

Никому такое не надо. UI-приложения таким способом никто не пишет и никогда писать не будет.
Скажем, у тебя вылазит такая проблема — UI подмораживается на секундочку во время тайпа.
Или такая — апликачка на старте иногда получает белый скрин или черный.
Таких кейсов я тебе миллион могу назвать.
Ты вспотеешь покрывать такое авто-тестами.

I>>Тебе напомнить, чем я предлагаю детектить регрессию ?
·>Напомни. Юнит-тесты ты вроде не признаёшь. А без них остальные авто-тесты могут быть слишком долгими.

Ты по моему нихрена не читаешь

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.

I>>Я хочу знать, у кого из девелоперов больше реопенов, что бы знать, кому доверить ответственный таск.
·>У нас нет реопенов, откуда они возьмутся-то? А ответственный таск мы обычно доверяем паре, а то и нескольким.

Ну то есть все пишут без ошибок и ваши тесты ловят вообще всё. Я так и думал.

I>>Это очевидно — автотесты не находят все баги. Всегда есть шанс, что ты внёс новый, критический для юзера кейс, который еще не покрыт тестом.
·>А что находит все баги? Что не оставляешь шанса внести новый критический кейс?

Успокойся. Речь о том, как найти новые кейсы, которые не предусмотрены тестами.

I>>Такой статистики недостаточно. Нужно знать зачастую, что юзер делал последние пол-часа или больше, да что бы порядок сообщений не потерялся, и что бы всё это памяти не съело и тд и тд
·>пиши в сеть, сохраняй на терабайтный винт.

Не надо ни сети, ни терабайтных винтов. Есть решения проще, дешевле и надёжнее.

I>>Пусть замахиваются. На текущий момент ты хочешь слишком многого. Твой метод экономически нецелесообразен.
·>По сравнению с чем?

По сравнению с обычными методами для тестирования UI в т.ч. под нагрузкой.

I>>·>Кто? (мы вроде говорим о perf-test env)
I>>Вся система, а приложение, к твоем сведение, не только из одного UI состоит.
I>>Что бы 1мб данных кинуть с диска на экран, нужно по шине прогнать в 10-1000 раз больше.
I>>Своп пока никто не отменял. GC — никто не отменял. Минимальная обработка данных — это пересылки по шине туда-сюда. Вот и выходит — шина жрётся не только в момент пересылки из памяти на видеокарту. 99% работы делается как раз ДО того.
·>И мы вроде начали с системы скриптования тестов. И сколько она добавит оверхеда? Хоть сотая доля процента наберётся?

А ты не фантазируй, скачай например HP QTP да посмотри сам. Ну или тулы навроде. Они или кривые и мало чего ловят, или встраиваются в процесс и создают оверхед.

I>>·>Большинство это 16 бит или 32? По-моему уже даже мобильные платформы 64bit попёрли.
I>>Мы про текущее положение дел. Большинство — 32 бита. 64 пока что кот наплакал.
·>Мы вроде об авто-тестах... Для стресс-тестов уж можно на одну 64-битную железяку раскошелиться.

Не смешно. Проблемы которые вылезут здесь, совсем необязательно вылезут в штатном режиме. А вот с большой вероятностью вылезут проблемы, например, из за неуёмного свопа.

I>>Человеку не нужно пялиться в скрины 20к на 10к. Так что твоя идея снова экономически несостоятельная.
·>Мы о тестах или опять о космических кораблях?

Я — о тестах, а ты, судя по битмапам 20к на 10к, о сферических конях в вакууме.

I>>Важно, что компьютер не умеет находить _новые_ баги.
·>Компьютер ничего не умеет. Что скажешь, то и будет делать.

В сотый раз повторяю — покажи тест, который находит ранее неизвестный кейс, последовательность и тд.

I>>В пятрый раз повторяю — покажи этот чудесный функциональнгый тест, который одинаково хорошо работает как с радиобатонами, так и с explorer-like UI.
·>Функциональный тест UI тестирует функционирование UI. Радиобатоны и explorer-like это UI и они должны ожидаемо функционировать. В чём проблема писать тесты для них?

Итак — ответа нет. Ты хорошо понимаешь, что тесты UI на радиобатонах все до одного надо выбросить, а новые писать с нуля ?

I>>Нисколько. Чуть выше ты дал советы навроде "давайте не будем менять UI если ломается много тестов". Таких идей не нужно.
·>Я не давал такие советы. Это ты откуда-то сам взял. Я давал совет: не меняйте так, чтобы ломалось слишком много.

Еще раз — никого не интересуют твои тесты. Юзер заплатит не за них, а за тот функционал который решит его проблему.
Как только выяснили, что старый UI не раскрывает все возможности функционала, значит его нещадно выбрасывают и всем насрать, сколько тестов летит в мусорку.
На самом деле не всем — челы вроде тебя будут до посинения защищать свои тесты: "не трогайте, не надо, придумайте другой выход, я писал тесты два года и восемь месяцев и только-толко начал подходить к концу"

I>>·>Если не могут — ищем компромисс. Иногда вообще отказываемся от истории.
I>>Лучше сразу рассмотреть случай, когда отказ от истории == закрытие проекта.
·>Ищем компромисс же.

А юзера ты попросишь войти в твоё положение ? Ему то по барабану твои компромиссы. Если есть классная рисовалка, которая не вписывается в твою стройную концепцию, он купит решение именно на её основе. А тестов может и не быть, ибо "исторически сложилось".
Есть аналитика-визуализация, котоаря решает его проблему — он купит именно её, а у тебя будет геморрой с тестами, ибо вот так вот её написали те, другие, в соседнем городе.
И вот выходит, что твои компромиссы == оправдания.

I>>Логическая ошибка. Если умеют то не надо править тест. А если не умеют — надо.
·>Эээ. В чём ошибка? Умеют — справятся, не умеют — научим. Но одно дело учить тест, который потом будет всегда работать, а другое дело учить тестеров, которые бывают увольняются, нанимаются и т.п.

Ты так и не показал тест, который находит неучтенный кейс.

I>>Значит возвращаемся к случаю "радиобатоны -> explorer-like UI"
·>Ок. Как я понимаю сценарий: есть форма с радиобатонами. Фич-ревест — переделать её в explorer like UI.
·>Как мы действуем: Смотрим сущестующе тесты радиобатонного UI. Каждый тест — некий юзкейс. Тестеры изучают каждый из них и пишут новый тест, аналогичный каждому сценарию. Очевидно, маппинг будет не 1к1, можно будет заметить, что некоторые сценарии могут измениться, какие-то вовсе исчезнуть, какие-то новые появиться. Все эти новые тесты помечаются в коде как WiP. В это же время девы добавляют feature toggle (булевый флажок, который будет определять публичность фичи). По умолчанию true, в prod — false. Флажок так же определяет какой из наборов тестов будет выполняться — старый или новый. Затем собственно начинают рисовать новый UI, постепенно снимая пометки WiP с тестов. Когда тестеры заявят, что все тесты написаны, а в коде не останется WiP, можно поменять флажок в true и следующий ближайший публичный релиз увидит новую фичу. После какого-то времени, если фича всем понравилась и всё прошло хорошо, удаляем флажок и все участки кода для значения false. Вуаля. И никаких упавших тестов вообще. Релиз новой фичи заключается в изменении одной строчки кода с false на true.

И это отстой, потому что кастомер как правило хочет увидеть результат сразу. Старые тесты никому не нужны. А результат нужен сразу, что бы решить, продлжать или не продолжать. А уже потом — новые тесты.

I>>·>Просто потому, что они могут это себе позволить.
I>>Уже давно не могут. Нынче у них имидж тухлый.
·>По сравнению с кем?

По сравнению с тем, какой у них раньше имидж был.

I>>Здесь, в кратце, надо подойти к QA-автоматчиками и сказать: "Ребята, вы молодцы !!! Выбрасывайте нахрен все ваши тесты по этой фиче"
·>Да пожалуйста, но только после того как замена пройдёт полностью успешно.

"Да, пожалуйста" — а чуть раньше ты сказал "а давайте не будем менять вот так вот радикально".

I>>Элементарно, обычные баги разработки, крайне вырожденные случаи. Когда всё намешано — такое вылазит на раз.
I>>Ты наверное хочешь намекнуть, что _ваши_ автотесты такого никогда не пропускают ?
·>Если только какой-нибудь gson/jackson сглючит только. Иначе как ещё можно сформировать невалидный json, да ещё в зависимости от клиента...

Элементарно. json подходит по схеме, но не подходит по содержанию. Вот и всё. Теперь смотрим, что ушло на сервер и что пришло. Если клиент А отослал валидные данные,а сервер клиенту Б дал невалидные — проблема в сервере. и тд.
Вот так работают тестировщики.

I>>Банальный if не работает, когда билд-сервер используется совместно. Один билд удалился, другой в это время сожрал 1гб памяти. Твой if слился.
·>Как это? В смысле ты меряешь погоду на марсе и общее место на диске? При этом пуская несколько билдов одновременно на том же диске? Так не надо так делать, очевидно.

Это просто один из возможных случаев. Есть вагон таких же. Например, операционая система решит удалить временные файлы и тд и тд.

I>>Для разработки/тестирования — web scarab, fiddler и тд и тд
·>А причём тут веб? Сеть вебом не ограничивается. Интересно как ты фиддлером будешь ловить udp трафик. А для веба селениум есть, гораздо мощнее чем с проксями мучиться.

Я привел пример для веб. Селениум так селениум. Покажи на этом селениуме как найти автотестами пропущенный девелопером кейс.

Здравствуйте, Patalog, Вы писали:

I>>>Если сложно — можно проще. Есть ровно один контрол — текст бокс. Он пустой. Юзер жмёт backspase. Валяй, список тестов в студию. Здесь уже нужен мануальный контроль, потому что ты не знаешь, чего ожидать.

P>·>Если вы пишете GUI control library, то да, должен быть тест testBoxUnderTest.setContent("").sendKeystroke(BACKSPACE), в чём проблема? Если вы пишете очередной диалог, то тестировать уже протестированные контролы — странный подход (или вы не доверяете разработчикам GUI-библиотеки?).

P>При этом по ~~воле бога~~факапа разработчика форма, на которой ровно один контрол оказалась не в фокусе клавы и бэкспейс ушел не в текст бокс от разработчиков GUI-библиотеки, которым мы доверяем, а в основное окно, где и отработал штатным образом, что в целом в этой ситуации нихера не штатно. Это как, например, после прогона VTuna'ом на слабенькой машинке ждешь открытия результатов, и решаешь во время этого неспешного процесса по-редактировать файл — blah-blah DEL — упс, результат прогона VTuna удалился из solution. Убил бы ...
Так это UX, опять, а не функциональность. Конечно, только человек может оценить удобство использования данного UI. Но это одна из последних стадий, после того, как все тесты отработали успешно. Какой смысл тестировать что кнопку нажимать удобно, если при нажатии она не делает то, что должна.

Здравствуйте, ·, Вы писали:

>А разве можно что-то прислонить, чтобы такая ситуация возникнуть не могла в принципе?
В принципе — вряд ли, а свести вероятность до приемлемого минимума, я думаю вполне возможно.

>Допустим, я это и так прекрасно знаю — любой инструмент имеет границы применимости. И что делать? Тут предлагали ассерты, ручное тестирование и прочие смехотворные вещи, которое оставляет ещё большее пространство для ошибок. Так что делать-то? Ползти на кладбище?
Вот вы сейчас опять непонятно с кем спорите. Я пока что ничего не предлагал, более того, я даже не предлагал ваши тесты выкинуть как не нужные. Они нужны, прекрасно справляются со своей работой и вообще замечательны, просто их недостаточно.

>Ситуация напоминает: мы тут построили сарай, а он развалился от неизвестного артефакта — шурупы повыпадали. Я говорю, что надо было взять отвёртку вместо кувалды, а мне тут начинают доказывать что отвёрткой сваи забивать невозможно, да и собранный сарай даже с использованием отвёртки может развалиться — вдруг ураганом снесёт или банально в пожаре сгорит.
Если уж опускаться до аналогий, то скорее вы утверждаете, что отвертки достаточно, а вам говорят, что нет, поскольку в нашей конструкции присутствуют не только саморезы.

>Я предлагаю замену ручного тестирования автоматическим тестированием, чтобы сабжы практически не встречались, а мне тут говорят, что мол CSS, мол курсор не рисуется. Что за бред?
Нечего заменять. Представьте ситуацию — все что теоретически можно и имеет смысл покрывать автотестами — уже покрыто, однако этого недостаточно.

>Я не понимаю что вы хотите сказать. Или просто доказать, что у нас авто-тестирование на самом деле не работает?
Я пытаюсь сказать, что только автотестов может быть недостаточно для закрытия этой проблемы.

>Во-первых, всё никогда не будет отлавливаться. Ты требуешь теоретически невозможного.

Это не я требую, это ваша же фраза. Опять мне вас цитировать?

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

>А тут сразу возникает два вопроса: Достаточной для чего?
Мы уже договорились — для того чтобы считать качество продукта приемлемым для публичного релиза.

> А что даёт бОльшую гарантию?
Комплексный подход. Чтобы минимизировать вероятность таких ошибок, важно грамотно выстроить весь цикл, начиная от сбора и постановки требований, создания тестплана, настройки окружения, работа с кодом — архитектура, ревью, управление выпусками и только в самом конце, ручное и автоматическое тестирование.

>>>Повторяю ещё раз. Мы тестируем ситуацию утечек дискового пространства в нашем CI, но как такового теста, который ты принялся называть тестом — нет. Нет кода аналогичного тому, который Вы соблаговолили заставить меня написать. Что непонятного-то?
IB>>Иллюстрирую:
IB>>цитата 1 — ""тест" тоже существует, который ты заставил меня написать"
IB>>цитата 2 — "как такового теста, который ты принялся называть тестом — нет"
IB>>так все-таки, существует или нет?
>Ещё раз. Зависит от того, что ты вкладываешь в значение термина. Ещё раз. Прочитай ОЧЕНЬ внимательно, приглядываясь к каждому слову и символу:
Тут как не читай, что вдоль, что поперек. В одной фразе вы говорите, что тест у вас тоже есть, причем именно такой, который вы мне здесь написали, а потом говорите, что под тестом вы на самом деле понимаете, что просто CI падает, а собственно теста нет.
Цитаты выше я специально сохранил, чтобы вы перепроверить могли.

>Написание ещё и тестирующего кода — будет тупым повторением того, что уже и так есть в puppet-скриптах и используемом железе.
То есть вы ответственность за часть тестов переложили на админов. Не самый удачный ход, если мне позволено покритиковать, так как это фактически нарушает SRP. У админов свои задачи, не всегда напрямую связанные со стабильностью работы вашего продукта, и вполне может быть случай, когда им понадобится увеличить размер диска для своих целей, а вы об этом узнаете только после релиза, когда все свалится на продакшене.

>Некоторые сервисы пишут разные данные на диск и поэтому расходуемое место отличается до и после запуска. Плюс почти все сервисы пишут логи. Притом явно контролировать — кто и сколько — практически невозможно, да и бессмысленно. До тех пор, пока они остаются в рамках приличия — пусть пишут.
Ну так и задайте одну константу, ограниченную этими рамками приличия.

Здравствуйте, Ikemefula, Вы писали:

I>>>Более того, exploratory может выполняться с помощью кода, но в большинстве случаев это ручное кликанье.
I>·>А ты уже стал сам себе противоречить:
I>·>"новые баги ищутся только руками" != "exploratory может выполняться с помощью кода"
I>Может. Нет противоречия. _Типичный_ exploratory это ручной. Из этого не следует, что все exploratory исключительно ручные.
Типичность варьируется, вещь субъективная. Может у для вас это типично, ибо традиция, низкая квалификация тестеров|разработчиков, бедность или жадность. Факт в том, что бОльшую часть можно автоматизировать.

I>·>Т.е. ты уже согласен с собой, что новые баги таки хотя бы иногда можно найти с помощью кода.
I>Объясни внятно — каким образом девелопер напишет тест на ту часть, которую он упустил из рассмотрения ?
Если что-то упустили из рассмотрения, то оно и вручную не будет протестировано.

I>>>Ну тогда покажи один функциональный тест UI, который на раз протестирует фичу у которой одно и то же ядро, но разные морды. У первой — 3 радиобатона и кнопки OK Cancel, у второй — explorer like UI.
I>·>Почему один? Две морды — два теста. Человек же не может одним тестом тестировать две морды. Почему ты это требуешь от автотеста?
I>Потому что первый вариант больше никому не нужен.
Если не нужен — удали код вместе с тестом. Останется один тест. Зачем тестировать то, что больше никому не нужно?

I>>>Когда люди сидят вместе, им часто митинги не нужны, потому что и так все в теме. А когда в разных странах, то и митинги не помогают.
I>·>Я не могу сидеть с собой вчерашним... Вчерашний я не только может быть в другой стране, но и очевидно в другом времени.
I>Ну то есть ты одновременно присутствуешь во всех офисах на всех континентах одновременно ?
I>А то ведь либа может пилиться где нибудь за Уралом, а навигатор, скажем, в Москве.
Да пофиг. У нас код пилится из разных полушарий... Но наш код мы не считаем 3rd party.

I>>>Ты хорошо понял выделеное ?
I>·>Так это как бы тест UI, но чтобы на UI отобразились необходимые изменения нужно обратиться к API. Что делать?
I>В одном месте скрипты навроде "очистить базу", в другом — UI для тестирования. И то и другое вызывается мышом.
Вот о чём и говорю. Вместо того, чтобы и то и другое вызывать кодом, вы тащите в процесс тестирования дополнительные мышевозилки.

I>

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.
Автоматически возится мышь? Почему ты уверен, что мышевозилка работает ровно так же, как тот автоматический тест?

I>·>Появляется новое устройство. Что получается:
I>·>1. Делаем ручные тесты. Плюс ещё 1000 форм каждый раз проверять глазами, перед каждым релизом.
I>·>2. Делаем авто-тесты. Упало N тестов, где N <= 1000. Проверить один раз N форм глазами.
I>·>Каким образом вариант 1 может быть лучше варианта 2?
I>Во первых, ты забыл, что про регрессию обсудили — для неё нужны автотесты
Новый девайс — не регрессия.

I>Во вторых, ты забыл что надо пофиксить все красные, а не просто посмотреть
Ты вроде сказал что "посмотрев глазами станет очевидно, что всё ок".

I>Во третьих, ты забыл что зеленые тоже возможно придется фиксить, потому что новый девайс == новые неучтенные кейсы.
Зелёные говорят, что работает ровно точно так же. Что может быть неучтённого?

I>>>То есть, в кратце, твои тесты потребуют столько же ручной работы, как и обычное ручное тестирование.
I>·>В худшем случае — ровно столько же. В реальных ситуациях — на порядки меньше.
I>В реальных ситуациях ручное применяется в обязательном порядке. Никто не отдаёт прогу в релиз, если она прошла автоматические тесты.
Не понял. Так ручные или автоматические?

I>Никто и никогда, кроме отмороженых на всю голову индусо-контор.
Типа яндекса?

I>>>Более того — их придется адаптировать для новой версии.
I>·>Тесты не адаптируют, а изменяют одновременно при внесении изменений в версию. При получении "новой версии" — тесты уже работают и к моменту релиза уже были запущены много-много раз.
I>Ну вот покажи адаптацию для случая "радиобатоны -> explorer-like UI"
Тесты не адаптируют. Что показать-то??

I>>>В UI у тебя никто не спросит, сколько тестов отвалится. Приходит реквест "заметить форму с радио-батонами на explorer-like UI".
I>·>Так замени — одновременно с изменением теста. Если упадут другие тесты, которые ты забыл изменить — сразу узнаешь что ты сломал.
I>"измени" это значит выбросить всё и написать заново.
Иногда да, допустим. И что?

I>>>Переименование это слабый пример, он не меняет структуру кода. Вот рефакторинги, которые меняют структуру кода IDEA ничего такого не умеет. Она вообще такие рефакторинги не умеет.
I>·>Извлечение|инлайн метода. Извлечение|инлайн интерфейса. Удаление|добавление|перестановка параметров. Замена конструктора на Builder. Выделение группы полей в класс. Замена наследования на делегирование. И прочее — всё меняет структуру кода.
I>Это небольшой набор частных случаев. Покажи мне, как IDEA сможет устранить дублирование в таком случае — есть 10 похожих методов, надо заменить тело каждого на вызов одного универсального с разными параметрами.
Да запросто — постоянно так делаю. Используешь extract|inline parameter|method|variable рефакторинги, изменение логических условий (например "a || b --> !(!a && !b)"), invert if statement и т.п. несколько раз подряд.

I>·>Да в общем не важно что умеет IDEA, любой рефакторинг по определению не меняет поведение кода, а значит должен оставлять тесты зелёными.
I>Наблюдаемое поведение — это _вызов_ метода
I>Место вызова — не есть поведение.
I>Ты хочешь не только вызов детектить, но и само место. То есть, у тебя по определению НЕ юнит тест. И никогда им не будет.
Ничего не понял.

I>>>Есть. Просто есть люди, которые не в курсе формальных моделей. Эти же люди и являются носителями утверждений "Нам это не надо"
I>·>Не понял. Был простой код, ввели формальную модель и стал сложным? А накой?
I>Простой для кого ? Для тебя, для джуниора который будет фиксить, для новчика в проекте, который пришел совсем из другой области, для человека, у которого в 10 раз больше опыта чем у тебя ?
Ну, допустим, простой для значительной части команды. Т.е. в любое время можно найти кого-то, для кого этот код кажется простым.

I>>>·>CSS это про UX. Неинтересно.
I>>>CSS это способ конструирования UI.
I>·>И что?
I>Ты UX тащишь куда попало. Ощущение, что у тебя всё что связано с UI это "UX, тестировать не надо"
I>CSS сейчас используется для реализации функциональности, а не просто для раскраски.
I>Нет никакой разницы между "девелопер забыл добавить кнопку" и "написал не тот стиль и кнопка не видна"
"Кнопка не видна" проверяется через isDisplayed в selenium.

I>БОлее того, "кнопка ничего не делает" и "у кнопки не тот стиль" это абсолютно одно и то же — ФУНКЦИОНАЛ НЕ РАБОТАЕТ
И это элементарно детектится selenium-ом.

I>·>Вот тебе самый первый тест "сделать всё": Приложение можно запустить, у окна должен быть заголовок "редактор конфигурации сети Ethernet", нажать кнопку "exit" — приложение должно завершиться. И это уже можно показывать заказчику!
I>Никому такое не надо. UI-приложения таким способом никто не пишет и никогда писать не будет.
I>Скажем, у тебя вылазит такая проблема — UI подмораживается на секундочку во время тайпа.
Типичный UX, функция работает, но пользоваться ей неприятно.

I>Или такая — апликачка на старте иногда получает белый скрин или черный.
Но кнопки нажимаются? Это как?

I>Таких кейсов я тебе миллион могу назвать.
I>Ты вспотеешь покрывать такое авто-тестами.

I>>>Тебе напомнить, чем я предлагаю детектить регрессию ?
I>·>Напомни. Юнит-тесты ты вроде не признаёшь. А без них остальные авто-тесты могут быть слишком долгими.
I>Ты по моему нихрена не читаешь
I>

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.
Вот допустим, "иногда получает белый скрин или черный." Вы это обнаружили, пофиксили, скажем, race condition в инициализации синглтонов. Сделали авто-тест, который что?

I>>>Я хочу знать, у кого из девелоперов больше реопенов, что бы знать, кому доверить ответственный таск.
I>·>У нас нет реопенов, откуда они возьмутся-то? А ответственный таск мы обычно доверяем паре, а то и нескольким.
I>Ну то есть все пишут без ошибок и ваши тесты ловят вообще всё. Я так и думал.
Реопен это регрессия. У вас же "РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ." Откуда тогда у вас реопены? Да ещё в статистически значимых количествах, что можно принимать решения о квалификации разработчика?

I>>>Это очевидно — автотесты не находят все баги. Всегда есть шанс, что ты внёс новый, критический для юзера кейс, который еще не покрыт тестом.
I>·>А что находит все баги? Что не оставляешь шанса внести новый критический кейс?
I>Успокойся. Речь о том, как найти новые кейсы, которые не предусмотрены тестами.
Да как угодно. Мы ищем обычно используя инфраструктуру поддержки авто-тестов.
Речь же должна идти к тому, как можно избавляться от кейсов, которые не предусматриваются тестами. А судя по тому, что ты рассказываешь, у вас процесс обратный — сервера тестируете через UI, счётчики визуализируете для упрощения ручного тестирования...

I>>>Такой статистики недостаточно. Нужно знать зачастую, что юзер делал последние пол-часа или больше, да что бы порядок сообщений не потерялся, и что бы всё это памяти не съело и тд и тд
I>·>пиши в сеть, сохраняй на терабайтный винт.
I>Не надо ни сети, ни терабайтных винтов. Есть решения проще, дешевле и надёжнее.
Какие?

I>·>И мы вроде начали с системы скриптования тестов. И сколько она добавит оверхеда? Хоть сотая доля процента наберётся?
I>А ты не фантазируй, скачай например HP QTP да посмотри сам. Ну или тулы навроде. Они или кривые и мало чего ловят, или встраиваются в процесс и создают оверхед.
Ой. Но я ж не знал, что так всё плохо с тулзами, что вам приходится использовать софт от HP

Приношу свои соболезнования.

I>>>·>Большинство это 16 бит или 32? По-моему уже даже мобильные платформы 64bit попёрли.
I>>>Мы про текущее положение дел. Большинство — 32 бита. 64 пока что кот наплакал.
I>·>Мы вроде об авто-тестах... Для стресс-тестов уж можно на одну 64-битную железяку раскошелиться.
I>Не смешно. Проблемы которые вылезут здесь, совсем необязательно вылезут в штатном режиме. А вот с большой вероятностью вылезут проблемы, например, из за неуёмного свопа.
Опять ты как-то странно считаешь. С 4-байтным пикселем это всего 800мег. Откуда своп? Вообще 20к*10к это не что-то сверхестественное. Попсовый IMAX это 10k*7k, что всего лишь в 3 раза меньше моих от балды названных цифр. Так что пока тут только ты на порядки ошибаешься.

I>>>Человеку не нужно пялиться в скрины 20к на 10к. Так что твоя идея снова экономически несостоятельная.
I>·>Мы о тестах или опять о космических кораблях?
I>Я — о тестах, а ты, судя по битмапам 20к на 10к, о сферических конях в вакууме.
Не важно. Ты хочешь сказать, что для UI не делают тесты, которые человеку сложнее проанализировать, чем компьютеру? Или ты можешь гарантировать, что никто никогда в мире не рендерил картинки 20к*10к?

I>>>Важно, что компьютер не умеет находить _новые_ баги.
I>·>Компьютер ничего не умеет. Что скажешь, то и будет делать.
I>В сотый раз повторяю — покажи тест, который находит ранее неизвестный кейс, последовательность и тд.
Покажи такой мануальный тест вначале.

I>>>В пятрый раз повторяю — покажи этот чудесный функциональнгый тест, который одинаково хорошо работает как с радиобатонами, так и с explorer-like UI.
I>·>Функциональный тест UI тестирует функционирование UI. Радиобатоны и explorer-like это UI и они должны ожидаемо функционировать. В чём проблема писать тесты для них?
I>Итак — ответа нет. Ты хорошо понимаешь, что тесты UI на радиобатонах все до одного надо выбросить, а новые писать с нуля ?
Собственно как и сам код — код радиобатонов придётся выбросить, написать новый. Чем тесты хуже кода, они священно-коровны?

I>·>Я не давал такие советы. Это ты откуда-то сам взял. Я давал совет: не меняйте так, чтобы ломалось слишком много.
I>Еще раз — никого не интересуют твои тесты. Юзер заплатит не за них, а за тот функционал который решит его проблему.
I>Как только выяснили, что старый UI не раскрывает все возможности функционала, значит его нещадно выбрасывают и всем насрать, сколько тестов летит в мусорку.
I>На самом деле не всем — челы вроде тебя будут до посинения защищать свои тесты: "не трогайте, не надо, придумайте другой выход, я писал тесты два года и восемь месяцев и только-толко начал подходить к концу"
Так у вас code ownership? Отучайтесь. Тогда понятия "мои тесты" не будет. Тест это инструмент разработки, а не средство самовыражения.
Да ещё и тесты пишете постфактум.
Используете самые корявые практики, не удивительно, что так всё плохо.

I>·>Ищем компромисс же.
I>А юзера ты попросишь войти в твоё положение ? Ему то по барабану твои компромиссы. Если есть классная рисовалка, которая не вписывается в твою стройную концепцию, он купит решение именно на её основе. А тестов может и не быть, ибо "исторически сложилось".
I>Есть аналитика-визуализация, котоаря решает его проблему — он купит именно её, а у тебя будет геморрой с тестами, ибо вот так вот её написали те, другие, в соседнем городе.
I>И вот выходит, что твои компромиссы == оправдания.
Если кастомеру пофиг на качество (где вы таких находите?! Дайте двух!!), то вам крупно повезло, и тут можно внедрить передовую методологию разработки "х/як, х/як и в продакшен", но желательно от имени другой компании, чтобы свою репутацию не поганить.

I>>>Логическая ошибка. Если умеют то не надо править тест. А если не умеют — надо.
I>·>Эээ. В чём ошибка? Умеют — справятся, не умеют — научим. Но одно дело учить тест, который потом будет всегда работать, а другое дело учить тестеров, которые бывают увольняются, нанимаются и т.п.
I>Ты так и не показал тест, который находит неучтенный кейс.
А я и не обещал.

I>>>Значит возвращаемся к случаю "радиобатоны -> explorer-like UI"
I>·>Ок. Как я понимаю сценарий: есть форма с радиобатонами. Фич-ревест — переделать её в explorer like UI.
I>·>Как мы действуем: Смотрим сущестующе тесты радиобатонного UI. Каждый тест — некий юзкейс. Тестеры изучают каждый из них и пишут новый тест, аналогичный каждому сценарию. Очевидно, маппинг будет не 1к1, можно будет заметить, что некоторые сценарии могут измениться, какие-то вовсе исчезнуть, какие-то новые появиться. Все эти новые тесты помечаются в коде как WiP. В это же время девы добавляют feature toggle (булевый флажок, который будет определять публичность фичи). По умолчанию true, в prod — false. Флажок так же определяет какой из наборов тестов будет выполняться — старый или новый. Затем собственно начинают рисовать новый UI, постепенно снимая пометки WiP с тестов. Когда тестеры заявят, что все тесты написаны, а в коде не останется WiP, можно поменять флажок в true и следующий ближайший публичный релиз увидит новую фичу. После какого-то времени, если фича всем понравилась и всё прошло хорошо, удаляем флажок и все участки кода для значения false. Вуаля. И никаких упавших тестов вообще. Релиз новой фичи заключается в изменении одной строчки кода с false на true.

I>И это отстой, потому что кастомер как правило хочет увидеть результат сразу. Старые тесты никому не нужны. А результат нужен сразу, что бы решить, продлжать или не продолжать.
Как он может увидеть сразу, если новую форму надо делать, скажем, два месяца? Попробуйте ему предложить, чтобы он полетал с околосветовой скоростью. Если он хочет видеть промежуточные результаты асап — дайте ему доступ к билду с флажком = true, который билдится после каждого коммита.

I>А уже потом — новые тесты.
Ещё раз. Тесты пишутся одновременно с кодом.

I>>>·>Просто потому, что они могут это себе позволить.
I>>>Уже давно не могут. Нынче у них имидж тухлый.
I>·>По сравнению с кем?
I>По сравнению с тем, какой у них раньше имидж был.
"с кем", а не "когда". А пока звучит как "трава была зеленее".

I>>>Здесь, в кратце, надо подойти к QA-автоматчиками и сказать: "Ребята, вы молодцы !!! Выбрасывайте нахрен все ваши тесты по этой фиче"
I>·>Да пожалуйста, но только после того как замена пройдёт полностью успешно.
I>"Да, пожалуйста" — а чуть раньше ты сказал "а давайте не будем менять вот так вот радикально".
И? Выбрасываем старое, только когда новое полностью готово. Эволюция, а не революция.

I>>>Элементарно, обычные баги разработки, крайне вырожденные случаи. Когда всё намешано — такое вылазит на раз.
I>>>Ты наверное хочешь намекнуть, что _ваши_ автотесты такого никогда не пропускают ?
I>·>Если только какой-нибудь gson/jackson сглючит только. Иначе как ещё можно сформировать невалидный json, да ещё в зависимости от клиента...
I>Элементарно. json подходит по схеме, но не подходит по содержанию. Вот и всё. Теперь смотрим, что ушло на сервер и что пришло. Если клиент А отослал валидные данные,а сервер клиенту Б дал невалидные — проблема в сервере. и тд.
I>Вот так работают тестировщики.
А как же формальные модели? Вроде и CSS нет, owner draw нет, 3rd party нет, у сервера даже UI нет, но тестируете всё так же — ручками.

I>>>Банальный if не работает, когда билд-сервер используется совместно. Один билд удалился, другой в это время сожрал 1гб памяти. Твой if слился.
I>·>Как это? В смысле ты меряешь погоду на марсе и общее место на диске? При этом пуская несколько билдов одновременно на том же диске? Так не надо так делать, очевидно.
I>Это просто один из возможных случаев. Есть вагон таких же. Например, операционая система решит удалить временные файлы и тд и тд.
Опять пошли какие-то неизвестные артефакты. Возможных случаев не так много.

I>>>Для разработки/тестирования — web scarab, fiddler и тд и тд
I>·>А причём тут веб? Сеть вебом не ограничивается. Интересно как ты фиддлером будешь ловить udp трафик. А для веба селениум есть, гораздо мощнее чем с проксями мучиться.
I>Я привел пример для веб. Селениум так селениум. Покажи на этом селениуме как найти автотестами пропущенный девелопером кейс.
А автотесты кем написаны? Надеюсь, что тестером, который по кейсам нарисовал автотесты. Тогда процесс следующий: исполнить все автотесты и посмотреть какие упадут. Упавший тест укажет на пропущенный девелопером кейс.

Здравствуйте, IB, Вы писали:

>>А разве можно что-то прислонить, чтобы такая ситуация возникнуть не могла в принципе?
IB>В принципе — вряд ли, а свести вероятность до приемлемого минимума, я думаю вполне возможно.
Какие есть способы, кроме упомянутого мною, которые могут значительно снизить вероятность?

>>Допустим, я это и так прекрасно знаю — любой инструмент имеет границы применимости. И что делать? Тут предлагали ассерты, ручное тестирование и прочие смехотворные вещи, которое оставляет ещё большее пространство для ошибок. Так что делать-то? Ползти на кладбище?
IB>Вот вы сейчас опять непонятно с кем спорите. Я пока что ничего не предлагал, более того, я даже не предлагал ваши тесты выкинуть как не нужные. Они нужны, прекрасно справляются со своей работой и вообще замечательны, просто их недостаточно.
Недостаточно кому? Недостаточно для чего? Что сделать, чтобы стало достаточно?

>>Ситуация напоминает: мы тут построили сарай, а он развалился от неизвестного артефакта — шурупы повыпадали. Я говорю, что надо было взять отвёртку вместо кувалды, а мне тут начинают доказывать что отвёрткой сваи забивать невозможно, да и собранный сарай даже с использованием отвёртки может развалиться — вдруг ураганом снесёт или банально в пожаре сгорит.
IB>Если уж опускаться до аналогий, то скорее вы утверждаете, что отвертки достаточно, а вам говорят, что нет, поскольку в нашей конструкции присутствуют не только саморезы.
Пока я видел только три варианта: "Автотесты", "Ручные тесты", "Ручные и автотесты". Я считаю, что первого варианта достаточно, если авто-тесты огранизованы с умом. Если я что-то упустил, прошу напомнить.

>>Я предлагаю замену ручного тестирования автоматическим тестированием, чтобы сабжы практически не встречались, а мне тут говорят, что мол CSS, мол курсор не рисуется. Что за бред?
IB>Нечего заменять. Представьте ситуацию — все что теоретически можно и имеет смысл покрывать автотестами — уже покрыто, однако этого недостаточно.
Представил. И что?

>>Я не понимаю что вы хотите сказать. Или просто доказать, что у нас авто-тестирование на самом деле не работает?
IB>Я пытаюсь сказать, что только автотестов может быть недостаточно для закрытия этой проблемы.
А что сможет добиться достаточности?

>>Во-первых, всё никогда не будет отлавливаться. Ты требуешь теоретически невозможного.
IB>

Это не я требую, это ваша же фраза. Опять мне вас цитировать?
Давай.

>>Во-вторых, основные же не от балды, а от критичности для бизнеса. Критически важные сценарии — покрываются.
IB>Как я уже проиллюстрировал — критический баг может вылезти и не в критически важном сценарии, и этот баг может быть не совместим с публичным релизом продукта.
И что же делать?

>>А тут сразу возникает два вопроса: Достаточной для чего?
IB>Мы уже договорились — для того чтобы считать качество продукта приемлемым для публичного релиза.
Ок. Хорошо. А как определить, измерить, что качество продукта приемлимо для публичного релиза?

>> А что даёт бОльшую гарантию?
IB>Комплексный подход. Чтобы минимизировать вероятность таких ошибок, важно грамотно выстроить весь цикл, начиная от сбора и постановки требований, создания тестплана, настройки окружения, работа с кодом — архитектура, ревью, управление выпусками и только в самом конце, ручное и автоматическое тестирование.
Вот в этом и заключается наше несогласие. Я считаю, что автоматическое тестирование должно быть на первом месте. И всё остальное — требования, окружение, код, етс должно происходить с оглядкой и учётом автоматического тестирования. И тогда ручное тестировние (кроме UX) будет не нужным, более того, эффект от него будет отрицательным — требует деньги+время, а выхлоп околонулевой.
Ты ничего не предложил вообще, а Ikemefula всё [не]осознанно тянет к ручному тестированию. Ваяли-ваяли, а потом ВНЕЗАПНО выяснилось, что оказывается нужно как-то обеспечивать качество и начали сувать костыли для визуализации счётиков, запуска SQL-скриптов мышой, фиддлера, положидевайснаподоконник.com™ и т.п., чтобы сделать ручное тестирование хоть сколько-нибудь адекватным.

IB>>>цитата 1 — ""тест" тоже существует, который ты заставил меня написать"
IB>>>цитата 2 — "как такового теста, который ты принялся называть тестом — нет"
IB>>>так все-таки, существует или нет?
>>Ещё раз. Зависит от того, что ты вкладываешь в значение термина. Ещё раз. Прочитай ОЧЕНЬ внимательно, приглядываясь к каждому слову и символу:
IB>Тут как не читай, что вдоль, что поперек. В одной фразе вы говорите, что тест у вас тоже есть, причем именно такой, который вы мне здесь написали, а потом говорите, что под тестом вы на самом деле понимаете, что просто CI падает, а собственно теста нет.
IB>Цитаты выше я специально сохранил, чтобы вы перепроверить могли.
Да тест существует, в смысле такой подход можно использовать. Но мы не используем.

>>Написание ещё и тестирующего кода — будет тупым повторением того, что уже и так есть в puppet-скриптах и используемом железе.
IB>То есть вы ответственность за часть тестов переложили на админов. Не самый удачный ход, если мне позволено покритиковать, так как это фактически нарушает SRP. У админов свои задачи, не всегда напрямую связанные со стабильностью работы вашего продукта, и вполне может быть случай, когда им понадобится увеличить размер диска для своих целей, а вы об этом узнаете только после релиза, когда все свалится на продакшене.
Нет у админов своих целей. Мы задаём цели.
Более того, у нас есть ещё естественный ограничитель — железо прода более производительное, чем тестовое. А значит более дорогое, а значит чисто из экономии тестовое железо будет ограниченее: тяжело в тестировании, легко в бою.

>>Некоторые сервисы пишут разные данные на диск и поэтому расходуемое место отличается до и после запуска. Плюс почти все сервисы пишут логи. Притом явно контролировать — кто и сколько — практически невозможно, да и бессмысленно. До тех пор, пока они остаются в рамках приличия — пусть пишут.
IB>Ну так и задайте одну константу, ограниченную этими рамками приличия.
Она и задаётся, но не в коде, а в puppet/nagios. Зачем дублировать?

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, consign, Вы писали:

C>>Казалось бы, и при чем здесь сортировка гномиков?

vsb>Это факап тестировщиков, менеджера проекта, девопсов, кого угодно, но уж точно не программистов.
Вот прочитал я почти всю ветку и хочу задать один вопрос: А как вы предлагаете тестировать что-то вроде CS:GO? Ну, или, любую другую многопользовательскую игру? Сервер, да, он тестами покрывается. А клиент? А разные видяхи? А... И еще много других вопросов.

Здравствуйте, Andrew Grega, Вы писали:

C>>>Казалось бы, и при чем здесь сортировка гномиков?

vsb>>Это факап тестировщиков, менеджера проекта, девопсов, кого угодно, но уж точно не программистов.
AG>Вот прочитал я почти всю ветку и хочу задать один вопрос: А как вы предлагаете тестировать что-то вроде CS:GO? Ну, или, любую другую многопользовательскую игру? Сервер, да, он тестами покрывается. А клиент? А разные видяхи? А... И еще много других вопросов.

Берёте модуль и пишете на него юнит-тесты. При чём тут видяхи?

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Andrew Grega, Вы писали:

C>>>>Казалось бы, и при чем здесь сортировка гномиков?

vsb>>>Это факап тестировщиков, менеджера проекта, девопсов, кого угодно, но уж точно не программистов.
AG>>Вот прочитал я почти всю ветку и хочу задать один вопрос: А как вы предлагаете тестировать что-то вроде CS:GO? Ну, или, любую другую многопользовательскую игру? Сервер, да, он тестами покрывается. А клиент? А разные видяхи? А... И еще много других вопросов.

vsb>Берёте модуль и пишете на него юнит-тесты. При чём тут видяхи?
Видяхи здесь при том, что для игры очень важно клиентское окружение. А оно может быть разным. И ты протестировал клиент на 128 разных железных конфигах, а вот при 129, которой у твоих тестеров не было, проблема вылезла...
И при чем здесь модуль? И что Вы имеете ввиду под этим словом?
Я просто о чем. Далеко не всегда тесты можно автоматизировать. Более того, возьмусь утверждать, что в реальной жизни автотесты — это недостижимый рай. Все об этом говорят, но никто их в живую не видел.
Утрирую, конечно. У самих на проекте автотесты есть, но, только на серверную часть. Клиент (игровой) тестится только руками и альтернативы этому нет.

Здравствуйте, ·, Вы писали:

I>>Может. Нет противоречия. _Типичный_ exploratory это ручной. Из этого не следует, что все exploratory исключительно ручные.
·>Типичность варьируется, вещь субъективная. Может у для вас это типично, ибо традиция, низкая квалификация тестеров|разработчиков, бедность или жадность. Факт в том, что бОльшую часть можно автоматизировать.

Есть другой факт — ты пока еще ни раз не привел даже описание, как автотесты могут найти новый баг.

I>>Объясни внятно — каким образом девелопер напишет тест на ту часть, которую он упустил из рассмотрения ?
·>Если что-то упустили из рассмотрения, то оно и вручную не будет протестировано.

Неверно, QA не обязан следовать жостким процедурам. В UI зачастую QA говорит "приемлемо" и всё.

I>>Потому что первый вариант больше никому не нужен.
·>Если не нужен — удали код вместе с тестом. Останется один тест. Зачем тестировать то, что больше никому не нужно?

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

I>>А то ведь либа может пилиться где нибудь за Уралом, а навигатор, скажем, в Москве.
·>Да пофиг. У нас код пилится из разных полушарий... Но наш код мы не считаем 3rd party.

Чего вы считаете, никому не интересно. Ты можешь получать суппорт по либе из другого полушария гарантировано в течении получаса ? Если да, то хочется знать, каким таким чудом, наверняка все умеют не спать 24/7 и любой дворник в курсе всех нюансов. Если нет, то у вас ничем не лучше, чем в 3rd party.

I>>В одном месте скрипты навроде "очистить базу", в другом — UI для тестирования. И то и другое вызывается мышом.
·>Вот о чём и говорю. Вместо того, чтобы и то и другое вызывать кодом, вы тащите в процесс тестирования дополнительные мышевозилки.

Ты пока еще не привел, как же кодом найти новый баг.

I>>

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.
·>Автоматически возится мышь? Почему ты уверен, что мышевозилка работает ровно так же, как тот автоматический тест?

Ты уже ратуешь за ручные тесты ? Поздравляю ! Теперь осталось уяснить значение "В ОСНОВНОМ"
Вообще, `мышевозилка` меняется постоянно. "Авто-тесты покрывают исключительно устоявшийся функционал. "

I>>Во вторых, ты забыл что надо пофиксить все красные, а не просто посмотреть
·>Ты вроде сказал что "посмотрев глазами станет очевидно, что всё ок".

Правильно — глазам я доверяю, а твоим тестам — нет. Визуально — всё в порядке. А вот тесты красные.

I>>Во третьих, ты забыл что зеленые тоже возможно придется фиксить, потому что новый девайс == новые неучтенные кейсы.
·>Зелёные говорят, что работает ровно точно так же. Что может быть неучтённого?

Опаньки ! И ты снова утверждаешь, что тесты ловят вообще всё. Браво !
Например три твоих теста для кнопки показывают, что она видна, имеет координаты нужные, нажимается. А на новом девайсе у ней стиль некорректный и глазом эта кнопка вообще не видна. Глазом видно, что проблема есть.
И это не UX. Это ты коряво написал и тесты, и функциональность.

I>>В реальных ситуациях ручное применяется в обязательном порядке. Никто не отдаёт прогу в релиз, если она прошла автоматические тесты.
·>Не понял. Так ручные или автоматические?

А ты попробуй перечитай. Если ручный — обязательные, то релиз с автоматическими без ручных состоится или нет ?

>>Никто и никогда, кроме отмороженых на всю голову индусо-контор.
·>Типа яндекса?

И в яндексе такого нет, не сочиняй.

I>>Ну вот покажи адаптацию для случая "радиобатоны -> explorer-like UI"
·>Тесты не адаптируют. Что показать-то??

Твоё скромное "тесты изменяют" в данном случае "тесты выбрасывают и пишут новые"
Как часто ты сможешь проделывать эти фокусы ?

I>>"измени" это значит выбросить всё и написать заново.
·>Иногда да, допустим. И что?

Не иногда, а постоянно и это норма. Это же не серверный АПИ — ожидаем логинг-пароль в таком то формате, отвечаем 200 + токен в хидере.
В UI будет скорее "юзер должен иметь возможность работать с персональными данными и что бы эти данные никто кроме него не видел"

I>>Это небольшой набор частных случаев. Покажи мне, как IDEA сможет устранить дублирование в таком случае — есть 10 похожих методов, надо заменить тело каждого на вызов одного универсального с разными параметрами.
·>Да запросто — постоянно так делаю. Используешь extract|inline parameter|method|variable рефакторинги, изменение логических условий (например "a || b --> !(!a && !b)"), invert if statement и т.п. несколько раз подряд.

Ну то есть куча рукопашных действий. А начинал так хорошо — `IDEA всё умеет`.
`умеет` это вот так — выделил дублирование, IDEA сама все сделает.

I>>Наблюдаемое поведение — это _вызов_ метода
I>>Место вызова — не есть поведение.
I>>Ты хочешь не только вызов детектить, но и само место. То есть, у тебя по определению НЕ юнит тест. И никогда им не будет.
·>Ничего не понял.

"метод А коллбека будет вызван..." — поведение
"из метода run вызовем колбек метод А" — сравни разницу. Если ктото перенесет вызов колбека наверх, скажем после вызова run или перед вызовом, то поведение не изменится, а твой тест — упадёт, потому что мок будет ожидать вызова из метода run.

I>>Простой для кого ? Для тебя, для джуниора который будет фиксить, для новчика в проекте, который пришел совсем из другой области, для человека, у которого в 10 раз больше опыта чем у тебя ?
·>Ну, допустим, простой для значительной части команды. Т.е. в любое время можно найти кого-то, для кого этот код кажется простым.

Если код простой для значительной части команды, значит команда занимается делом ниже своей квалификации, т.е. "художник работает маляром".

I>>Нет никакой разницы между "девелопер забыл добавить кнопку" и "написал не тот стиль и кнопка не видна"
·>"Кнопка не видна" проверяется через isDisplayed в selenium.

а ты поинтересуйся, как это реализуется в селениуме.

I>>БОлее того, "кнопка ничего не делает" и "у кнопки не тот стиль" это абсолютно одно и то же — ФУНКЦИОНАЛ НЕ РАБОТАЕТ
·>И это элементарно детектится selenium-ом.

Селениум детектит только кое какие свойства. Он не может сказать "форм выглядит не так, как должна".

I>>Скажем, у тебя вылазит такая проблема — UI подмораживается на секундочку во время тайпа.
·>Типичный UX, функция работает, но пользоваться ей неприятно.

У тебя все неудобное это UX.

I>>Или такая — апликачка на старте иногда получает белый скрин или черный.
·>Но кнопки нажимаются? Это как?

Легко. Движок кривой. Покажи тест.

I>>Ты по моему нихрена не читаешь
I>>

БОЛЬШИМИ БУКВАМИ — РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ.
·>Вот допустим, "иногда получает белый скрин или черный." Вы это обнаружили, пофиксили, скажем, race condition в инициализации синглтонов. Сделали авто-тест, который что?

Ты мне расскажи, что это за тест будет. Я ведь именно этот вопрос и задаю.

I>>Ну то есть все пишут без ошибок и ваши тесты ловят вообще всё. Я так и думал.
·>Реопен это регрессия. У вас же "РЕГРЕССИЯ ДЕТЕКТИТСЯ В ОСНОВНОМ АВТОМАТИЧЕСКИ." Откуда тогда у вас реопены? Да ещё в статистически значимых количествах, что можно принимать решения о квалификации разработчика?

Реопен потому, что работу девелопера проверяет другой человек, иногда — несколько.

I>>Успокойся. Речь о том, как найти новые кейсы, которые не предусмотрены тестами.
·>Да как угодно. Мы ищем обычно используя инфраструктуру поддержки авто-тестов.

Покажи уже эту пульку.

·>Речь же должна идти к тому, как можно избавляться от кейсов, которые не предусматриваются тестами.

Это легко — астрономическое число тестов, а лучше даже бесконечное, решит эту проблему.

>А судя по тому, что ты рассказываешь, у вас процесс обратный — сервера тестируете через UI, счётчики визуализируете для упрощения ручного тестирования...

Я говорю исключительно про клиентские проблемы, а тебе мерещится сервер.

I>>·>пиши в сеть, сохраняй на терабайтный винт.
I>>Не надо ни сети, ни терабайтных винтов. Есть решения проще, дешевле и надёжнее.
·>Какие?

В зависимости от приложения. Иногда можно просто в файл писать напрямую. Иногда подключается готовый сервис на устройстве. И тд.

I>>А ты не фантазируй, скачай например HP QTP да посмотри сам. Ну или тулы навроде. Они или кривые и мало чего ловят, или встраиваются в процесс и создают оверхед.
·>Ой. Но я ж не знал, что так всё плохо с тулзами, что вам приходится использовать софт от HP

Приношу свои соболезнования.

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

I>>Не смешно. Проблемы которые вылезут здесь, совсем необязательно вылезут в штатном режиме. А вот с большой вероятностью вылезут проблемы, например, из за неуёмного свопа.
·>Опять ты как-то странно считаешь. С 4-байтным пикселем это всего 800мег. Откуда своп?

В самом деле, одной транзакцией откусить 20% всей памяти на девайсе или 40-60 от свободной на том же девайсе.

В самом деле, откуда своп ? А представь, фрейм надо рисовать не менее 10-20 раз в секунду и собирать его из 5-10 битмапин того же разрешения ?

в 32х разрядах даже в десять раз меньшие цифры дают OutOfMemory, а 64 бита — жесточайший своп.

>Вообще 20к*10к это не что-то сверхестественное. Попсовый IMAX это 10k*7k, что всего лишь в 3 раза меньше моих от балды названных цифр. Так что пока тут только ты на порядки ошибаешься.

Для UI винды и андроида это более чем сверхестественное. Ты в курсе, что оптимизациями не только ты занимаешься ?

I>>Я — о тестах, а ты, судя по битмапам 20к на 10к, о сферических конях в вакууме.
·>Не важно. Ты хочешь сказать, что для UI не делают тесты, которые человеку сложнее проанализировать, чем компьютеру? Или ты можешь гарантировать, что никто никогда в мире не рендерил картинки 20к*10к?

Рендеринг картинок и UI это две большие разницы. UI оптимизирован по самые `не хочу`. Это значит, что кейсы которые не встречаются в реале, могут быть сколь угодно медленными, если реализация позволяет ускорить основные.

I>>·>Компьютер ничего не умеет. Что скажешь, то и будет делать.
I>>В сотый раз повторяю — покажи тест, который находит ранее неизвестный кейс, последовательность и тд.
·>Покажи такой мануальный тест вначале.

обычный exploratory. Если ты не в курсе, для этих тестов нет заранее заготовленой последвательности.

I>>Итак — ответа нет. Ты хорошо понимаешь, что тесты UI на радиобатонах все до одного надо выбросить, а новые писать с нуля ?
·>Собственно как и сам код — код радиобатонов придётся выбросить, написать новый. Чем тесты хуже кода, они священно-коровны?

Ничем. Требований почти нет да и те меняются постоянно. Отсюда ясно, что автотесты нужны только для устоявшегося функционала.

I>>На самом деле не всем — челы вроде тебя будут до посинения защищать свои тесты: "не трогайте, не надо, придумайте другой выход, я писал тесты два года и восемь месяцев и только-толко начал подходить к концу"
·>Так у вас code ownership? Отучайтесь. Тогда понятия "мои тесты" не будет. Тест это инструмент разработки, а не средство самовыражения.

У нас нет овнершипа кода, твоя телепатия не работает.

·>Да ещё и тесты пишете постфактум.

Твоя телепатия снова не работает.

·>Используете самые корявые практики, не удивительно, что так всё плохо.

И здесь твоя телепатия не работает.

I>>Есть аналитика-визуализация, котоаря решает его проблему — он купит именно её, а у тебя будет геморрой с тестами, ибо вот так вот её написали те, другие, в соседнем городе.
I>>И вот выходит, что твои компромиссы == оправдания.
·>Если кастомеру пофиг на качество (где вы таких находите?! Дайте двух!!),

Кастомер сам устанавливает качество согласно своим бюджетам, потребностям, возможностям и тд.
Вот от этого и отталкиваемся.

I>>Ты так и не показал тест, который находит неучтенный кейс.
·>А я и не обещал.

Ты зато постоянно повторяешь "автотестами это легко"

I>>И это отстой, потому что кастомер как правило хочет увидеть результат сразу. Старые тесты никому не нужны. А результат нужен сразу, что бы решить, продлжать или не продолжать.
·>Как он может увидеть сразу, если новую форму надо делать, скажем, два месяца?

Если не делать из тестов священную корову, то все получается, хоть каждый день показывай.

I>>А уже потом — новые тесты.
·>Ещё раз. Тесты пишутся одновременно с кодом.

Это только когда требования наперёд известны. Когда такого нет, можно использовать только юнит-тесты и то не для любого кода.

I>>"Да, пожалуйста" — а чуть раньше ты сказал "а давайте не будем менять вот так вот радикально".
·>И? Выбрасываем старое, только когда новое полностью готово. Эволюция, а не революция.

Это не эволюция, это стояние на месте. UI нужен только тогда, когда им ктото пользуется. Новая версия означает, что старый UI больше не нужен. Потому делается по быстрому затычка, что бы QA могли тестировать новые возможности приложения, а уже потом затычка меняется на полноценный UI.

I>>Элементарно. json подходит по схеме, но не подходит по содержанию. Вот и всё. Теперь смотрим, что ушло на сервер и что пришло. Если клиент А отослал валидные данные,а сервер клиенту Б дал невалидные — проблема в сервере. и тд.
I>>Вот так работают тестировщики.
·>А как же формальные модели?

Формальные модели для разработчиков. И вообще, я про клиент, а не сервер. Ты уже который раз хочешь словить меня на том, что апи сервера тестируется руками.

>>Это просто один из возможных случаев. Есть вагон таких же. Например, операционая система решит удалить временные файлы и тд и тд.
·>Опять пошли какие-то неизвестные артефакты. Возможных случаев не так много.

Это норма. В твоём случае ты проблему качества переложил на админов CI.

I>>Я привел пример для веб. Селениум так селениум. Покажи на этом селениуме как найти автотестами пропущенный девелопером кейс.
·>А автотесты кем написаны? Надеюсь, что тестером, который по кейсам нарисовал автотесты.

Правильно, по спеке. Только я уже говорил — спека кривая донельзя и в ней только правильный путь юзера. Это у вас область, где спекой можно всё закрыть. Представь, в других областях может быть иначе.

Здравствуйте, ·, Вы писали:

>Какие есть способы, кроме упомянутого мною, которые могут значительно снизить вероятность?
Я уже написал.

>Недостаточно кому? Недостаточно для чего?
Мы уже наверное по тридцатому разу пошли, мне в принципе не сложно повторить, но уже скучно.

>Что сделать, чтобы стало достаточно?
Опять таки, уже написал.

>Пока я видел только три варианта: "Автотесты", "Ручные тесты", "Ручные и автотесты". Я считаю, что первого варианта достаточно, если авто-тесты огранизованы с умом.
Вы ошибаетесь.

>Если я что-то упустил, прошу напомнить.
Вся наша ветка просто наполнена примерами и иллюстрациями, показывающими, что именно вы упустили. Учитывая вашу феноменальную забывчивость еще раз это цитировать бесполезно, поэтому если вам действительно интересно — не сочтите за труд, перечитайте ветку еще раз.

IB>>Я пытаюсь сказать, что только автотестов может быть недостаточно для закрытия этой проблемы.
>А что сможет добиться достаточности?
Уже написал.

>>>Во-первых, всё никогда не будет отлавливаться. Ты требуешь теоретически невозможного.
IB>>

Это не я требую, это ваша же фраза. Опять мне вас цитировать?
>Давай.
Легко: "Поэтому, чисто по построению подход отлавливает всё." (с) У вас какая-то фантастическая способность противоречить самому себе, а потом с легкостью это забывать. Я вас уже раз в четвертый, наверное, ловлю — надоело. Научитесь за свои слова отвечать уже.

>И что же делать?
Уже написано.

>Ок. Хорошо. А как определить, измерить, что качество продукта приемлимо для публичного релиза?
Формально? Никак. Прохождение автотестов — необходимый критерий, но недостаточный. Решение о готовности продукта в релиз с точки зрения качества — принимает QA ответственный за продукт.

>Вот в этом и заключается наше несогласие. Я считаю, что автоматическое тестирование должно быть на первом месте. И всё остальное — требования, окружение, код, етс должно происходить с оглядкой и учётом автоматического тестирования.
Вы заблуждаетесь, не надо делать из автотестов культа — они не панацея. Я даже допускаю, что такой подход может быть оправдан на ваших продуктах, но в общем случае он ведет к весьма неприятным сюрпризам.
О, я кажется понял причину вашего заблуждения. Вы тут с таким апломбом рассказываете про чудеса автотестов, просто потому, что даже если похожая проблема случится у вас в продакшене, то ничего страшного все равно не произойдет, и клиенты об этом даже не узнают. В продакшене сработает алерт при уменьшении дискового лимита, саппорт инженер быстро почистит логи, чтобы сервер дальше жил, а менеджер засунет шкворень разработчикам и тестерам, и у вас таки появится новый тест на рост логов.

>И тогда ручное тестировние (кроме UX) будет не нужным, более того, эффект от него будет отрицательным — требует деньги+время, а выхлоп околонулевой.
Как наивно... Мы вот как раз закончили выпуск продукта с весьма скудным UI, в котором буквально три кнопки. Так вот, попытка покрыть его автотестами заняла больше времени, чем собственно разработка и большой пользы в итоге не принесла. Если бы там можно было обойтись автотестами — мы были бы счастливы, но увы.

>Ты ничего не предложил вообще,
И не должен был. В очередной раз напоминаю, что выработка решения проблемы яндекса — не является темой этой конкретной дискуссии. В этой ветке вы впряглись показать нам, что автотестов достаточно, для решения этой проблемы. Пока безуспешно.
Решение же проблемы в общем виде — тема отдельной дискуссии.

>Ваяли-ваяли, а потом ВНЕЗАПНО выяснилось, что оказывается нужно как-то обеспечивать качество и начали сувать костыли для визуализации счётиков, запуска SQL-скриптов мышой, фиддлера, положидевайснаподоконник.com™ и т.п., чтобы сделать ручное тестирование хоть сколько-нибудь адекватным.
Вы опять сами с собой спорите?

>Да тест существует, в смысле такой подход можно использовать. Но мы не используем.
Жалкая попытка, ну да ладно.

>Нет у админов своих целей. Мы задаём цели.
Даже как-то странно вам это объяснять. Если это именно амдины, а не инженеры QA у которых первый приоритет тестировать качество продукта, то у них естественно есть свои цели и вы конечно же о них узнаете, но будет уже поздно.

>Она и задаётся, но не в коде, а в puppet/nagios. Зачем дублировать?
SRP — если одна константа служит разным целям, то рано или поздно эти цели разойдутся и для одной из задач значение константы станет неверным.

От:	IB	http://rsdn.ru
Дата:	23.09.15 14:19
Оценка:	+1

	От:	·
	Дата:	24.09.15 10:48
	Оценка:

	От:	·
	Дата:	24.09.15 13:16
	Оценка:

От:	IB	http://rsdn.ru
Дата:	24.09.15 15:21
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	24.09.15 18:09
Оценка:

	От:	Venom
	Дата:	25.09.15 04:55
	Оценка:

	От:	Patalog
	Дата:	25.09.15 05:30
	Оценка:

	От:	vsb
	Дата:	26.09.15 20:57
	Оценка: