Я настолько засомневался в своей правоте, что даже в гугл обратился. И знаете, всё-таки, это — soft assert https://stackoverflow.com/questions/19091526/how-soft-assertions-work#25068591
Только в данном случае не важно, как мы это называть будем.
Тест должен падать сразу же, как только обнаружена ошибка. Вернёмся к длинным тестам и JS ошибкам (как пример). Если обнаружена JS ошибка важно знать где, когда, после какой операции с какими параметрами была ошибка. В идеале — запись скриншотов, состояния DOM (если web), видео. Короче, вообще всё.
А если вы собрали ошибочки и положили их в хранилище, то потом такие ошибки разбирать удовольствием не назовёшь.
Лично мне кажется, что soft assert — это плохой паттерн. Но иногда лучше плохой паттерн, чем полное отсутствие тестов. Если вам привычнее и вы умеете этим эффективно управлять — отлично!
Не бейте меня палкой, пожалуйста, но я не вижу как поиск элемента по тексту / подписи поможет с описанными проблемами.
Во-первых, у кнопки может вообще не быть осмысленного текста. У неё есть только иконка. Вот такой вот "венец" юзабилити на сайте.
Во-вторых,…
Например, на форме-опроснике есть кнопка Сontinue, по нажатию на которую показывается новый вопрос. Нам точно так же после её нажатия надо убедиться, что мы не стали заложниками stale element error и кнопка Continue — новая, а старая не пропала.
Вот если вы каждый раз переполучаете элемент заново и нигде не храните на него ссылок, то это, конечно сработает. До поры до времени, пока вы не начнёте хранить ссылки.
Ещё это называется soft assert. Про них столько копий сломано, что можно отдельную (но скучную) статью писать. Лично мне они кажутся каким-то переусложнением теста — сколько с ними не работал, они постепенно "вымывались" из проектов.
Если есть ошибка, то тест должен упасть. Если есть что-то "не совсем ошибка, но хорошо бы знать", то надо разобраться с критериями того, что считать ошибкой в данной конкретной конфигурации тестов. Например, для проверки работоспособности приложения в принципе можно игнорировать ошибки в JS-консоли браузера (если при этом всё работает), но если мы выпускаем новую версию, то эти ошибки достойны того, чтобы прервать тест.
Сугубо моё личное мнение.
Иметь актуальную внутреннюю документацию крайне непросто, особенно если продукт не продаётся и нет специального отдела документации.
Её надо поддерживать. Надо поддерживать экспериментальные технологии. Нужно поддерживать связность документации — через mind maps и через гиперссылки. Нужно вообще УМЕТЬ писать документацию (это не каждому дано).
из коробки не завелось с ошибкой: docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/docker-entrypoint.sh\": permission denied": unknown.
Или произнося «the high street» говорящий подразумевает конкретно главную улицу города?
да. High Street это и устоящее название таких улиц (т.е. имя собственное), и обозначение подобных улиц с другим названием. Picadilly street в Лондоне — это high street. Но не The High Street, которая вообще где-то совсем на западе.
Думайте в категориях того, насколько определённо вы хотите выразить существительное.
мальчик вошёл в комнату
этот мальчик вошёл в комнату
мальчик вошёл в какую-то комнату
какой-то мальчик вошёл в эту комнату
в комнату вошёл мальчик
по-русски перестановка и несколько служебных слов играют роль категорий определённости / неопределённости, а в германских языках (не в последнюю роль из-за фиксированного порядка слов) эту роль играют артикли.
По-моему, две самых популярных ошибок в английском языке:
1) отстуствие глагола "to be" во фразе типа "I okay" (вместо I'm okay) и "he going to… " (вместо he's going to)
2) неправильная форма третьего лица единственного числа у глаголов — he rides, she sings, it walks и т.п.
Ошибки ужасно примитивные, но их совершает невероятное количество русскоязычных :)
Лично мне больше нравится "перевёрнутая" пирамида тестов, она же "тесты в вафельном стаканчике". Как-то более естественно воспринимается "просеивание", чем карабканье вверх.
Я настолько засомневался в своей правоте, что даже в гугл обратился. И знаете, всё-таки, это — soft assert https://stackoverflow.com/questions/19091526/how-soft-assertions-work#25068591
Только в данном случае не важно, как мы это называть будем.
Тест должен падать сразу же, как только обнаружена ошибка. Вернёмся к длинным тестам и JS ошибкам (как пример). Если обнаружена JS ошибка важно знать где, когда, после какой операции с какими параметрами была ошибка. В идеале — запись скриншотов, состояния DOM (если web), видео. Короче, вообще всё.
А если вы собрали ошибочки и положили их в хранилище, то потом такие ошибки разбирать удовольствием не назовёшь.
Лично мне кажется, что soft assert — это плохой паттерн. Но иногда лучше плохой паттерн, чем полное отсутствие тестов. Если вам привычнее и вы умеете этим эффективно управлять — отлично!
Не бейте меня палкой, пожалуйста, но я не вижу как поиск элемента по тексту / подписи поможет с описанными проблемами.
Во-первых, у кнопки может вообще не быть осмысленного текста. У неё есть только иконка. Вот такой вот "венец" юзабилити на сайте.
Во-вторых,…
Например, на форме-опроснике есть кнопка Сontinue, по нажатию на которую показывается новый вопрос. Нам точно так же после её нажатия надо убедиться, что мы не стали заложниками stale element error и кнопка Continue — новая, а старая не пропала.
Вот если вы каждый раз переполучаете элемент заново и нигде не храните на него ссылок, то это, конечно сработает. До поры до времени, пока вы не начнёте хранить ссылки.
Ещё это называется soft assert. Про них столько копий сломано, что можно отдельную (но скучную) статью писать.
Лично мне они кажутся каким-то переусложнением теста — сколько с ними не работал, они постепенно "вымывались" из проектов.
Если есть ошибка, то тест должен упасть. Если есть что-то "не совсем ошибка, но хорошо бы знать", то надо разобраться с критериями того, что считать ошибкой в данной конкретной конфигурации тестов. Например, для проверки работоспособности приложения в принципе можно игнорировать ошибки в JS-консоли браузера (если при этом всё работает), но если мы выпускаем новую версию, то эти ошибки достойны того, чтобы прервать тест.
Сугубо моё личное мнение.
Иметь актуальную внутреннюю документацию крайне непросто, особенно если продукт не продаётся и нет специального отдела документации.
Её надо поддерживать. Надо поддерживать экспериментальные технологии. Нужно поддерживать связность документации — через mind maps и через гиперссылки. Нужно вообще УМЕТЬ писать документацию (это не каждому дано).
Splunk — это прекрасно. Это офигенный поиск и агрегация. Удобные отчёты. Но. Очень. Дорого.
правда — работает :)
спасибо
из коробки не завелось с ошибкой:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/docker-entrypoint.sh\": permission denied": unknown.¯_(ツ)_/¯
Вы, конечно, правы. Если есть возможность сделать хорошо — нужно делать хорошо.
Мне кажется, что автор имел в виду не прямо вот дословно атрибут ID, а некоторый уникальный идентификатор. Например, data-id или data-qa-id.
Это просто праздник какой-то!
Demons Souls только на PS3. А сколько я на него часов убил… Ууу…
Кстати, вполне разумное замечание. Но какой-то уникальный идентификатор все равно должен быть. Например, dataset атрибуты или список классов
да. High Street это и устоящее название таких улиц (т.е. имя собственное), и обозначение подобных улиц с другим названием. Picadilly street в Лондоне — это high street. Но не The High Street, которая вообще где-то совсем на западе.
Думайте в категориях того, насколько определённо вы хотите выразить существительное.
по-русски перестановка и несколько служебных слов играют роль категорий определённости / неопределённости, а в германских языках (не в последнюю роль из-за фиксированного порядка слов) эту роль играют артикли.
The Netherlands, насколько я помню, ещё одно из таких исключений.
Вы правы. Мой комментарий имел бы смысл, если бы я выбрал правильную картинку, где вверху конуса юнит-тесты. Фейспалм и позор мне.
По-моему, две самых популярных ошибок в английском языке:
1) отстуствие глагола "to be" во фразе типа "I okay" (вместо I'm okay) и "he going to… " (вместо he's going to)
2) неправильная форма третьего лица единственного числа у глаголов — he rides, she sings, it walks и т.п.
Ошибки ужасно примитивные, но их совершает невероятное количество русскоязычных :)
Лично мне больше нравится "перевёрнутая" пирамида тестов, она же "тесты в вафельном стаканчике". Как-то более естественно воспринимается "просеивание", чем карабканье вверх.
(источник картинки)
Ну так пить надо из-под крана, а не из раковины.
У питьевых фонтанов на улицах городов иногда вообще раковин нет — и ничего :)
Я вас не понимаю. Вода вытекает из крана. Чистота раковины никак не влияет на пригодность воды для питья.