Но если у человека не развитая эмпатия, то как его заставить-то или «научить» сочувствовать да прощать?
На мой личный взгляд, руководитель без развитой эмпатии — плохой руководитель. Ставить в пример Стива Джобса не надо :) А если мы говорим о том человеке, которому прощают его ошибки, и у него не развита эмпатия… И он этим пользуется… Ну так очевидно, что такой человек в коллективе работать не может. Он может быть прекрасным специалистом, но ему нужна какая-то особая работа, особый отдел из одного человека, с очень чётко обозначенными задачами. Это моё личное мнение.
То что стоит входить в положение — это часть общественной этики, а не личное изобретение Badoo
Совершенно верно. Разве то, что это — прописная истина, делает её какой-то менее важной? У нас в культуре нет табу на прописную истину :)
Ну, вообще-то считается, что стоит прощать ошибки и оплошности тем, кто находится в стрессе из-за личных обстоятельств (ребёнок родился, переезд, что-то случилось).
У них настолько маленькая команда, что их встретить на каких-то конференциях вообще нереально, похоже. А ведь они многое чего могли рассказать!
(сразу же вспоминается одна из серий Silicon Valley)
нет, коллега никуда не попадал, это первая машина в UK. Индекс — возможно. Но как пишут на многих сайтах, то большее влияние может оказать сфера занятости.
во-первых, в британии требуется получение местных водительских прав (а не обмен) и российский стаж и no claim period не учитывается
во-вторых, через пару-тройку лет страховка должна стать как раз примерно эти же 400 евро
"Я вам не скажу за всю Одессу", но у нас с коллегами какие-то фантастические различия в цене страховки на машину. То есть, у коллеги и машина дешевле, и стаж — 10 лет, но ему не предлагают ниже 1200. У меня машина дороже, стаж — 3 года (да, права российские в первый год были), но страховка 700.
Я подозреваю, что надо "правильно" анкету заполнять :)
Я как раз один из таких ушибленных лондонских велосипедистов.
В штормовой ветер тяжело. И опасно, даже пешком.
Но ветер и температура, на самом деле, не представляют серьёзных проблем. А вот внезапно выпавший снег — это да. Его не убирают, он сам растает через пару дней, но в эти дни ездить нельзя.
Ещё один недостаток: ошибка может быть в генерации тестовых данных.
Я не защищаю такой подход, но он вполне может существовать на временной основе, пока не сделают генерилку данных. В нем нет каких-то фундаментально-неверных подходов.
Я согласен с вами, что такой подход рабочий. Но нет ничего более постоянного, чем что-то временное :)
Некоторая ошибочность подхода (не фатальная) в том, что вы тестируете гораздо больше, чем вам надо. Просто "а почему бы и нет?" Раз вас пока это устраивает — исползуйте на здоровье :)
Нсли чистить не в рамках теста, а в рамках другой задачи (да хоть бы и автоматическим заданием в планировщике очередей), то скорость прохождения тестов не вырастет.
Чистилка не особо нужна, если каждый раз использовать эталонную базу (восстанавливать из докера / хранить слепок / всё что угодно).
Понятное дело, что вы сейчас говорите о каком-то реальном проекте, где это ну оооочень сложно реализовать уже. А вам тут о каком-то академическом примере талдычут. Ну так вот придёте как-нибудь на новый проект, где ещё код весь костылями не оброс и успеете туда прикрутить "чуть лучший" подход к тестированию.
Ваш случай граничный. Сложно придумать контраргумент. Возможно, даже и не нужно, ведь есть "допустимое зло" :)
Из тех условий, что вы приводите, рандомная генерация ключей единственное что не позволит воспроизвести какую-нибудь ошибку в БД или хранимых процедурах в БД.
Но это уже домыслы.
Без них в тестах нельзя. Даже в юнит-тестах всё равно нужно делать эмуляторы зависимостей (моки, стабы и т.п.), просто они делаются по-другому. И гораздо дешевле.
конечно! это приёмные тесты. Просто часто делают перекос в эту сторону и становится "1000 тестов на селениуме и 1000 юнит-тестов".
Без них в тестах нельзя. Даже в юнит-тестах всё равно нужно делать эмуляторы зависимостей (моки, стабы и т.п.), просто они делаются по-другому. И гораздо дешевле.
Ну моки и эмуляторы, всё-таки, разные вещи :) Я имел в виду именно эмуляторы в низкоуровневых тестах
Обычно, когда агрегатор падает в тестовой среде, нам говорят «да, в тестовой среде мы его обновляем, это займёт неделю.
Если у вас релиз, который не затрагивает интеграцию с агрегатором, то всё верно, согласен с вами, так и делается. А если переделана вся интеграция, то на ооооочень не хочется складывать все яйца в одну корзину "мы тут и интерацию написали, а ещё и пару багов в собственном эмуляторе пэйпала поправили". Ага. Так я и поверим им, что пару багов не добавили.
Рандом как раз в тестах, просто во входных данных. Получается, что чистая функция "тест" обёрнута в обычную функцию "тест + входные данные" + рандомное время для извлечения тестовых данных.
Конечно, всегда есть некоторая рандомизация (да хотя бы время, в которое скрипт запустили — вдруг фирма уже прекратила существование и уже отправилась в архив), но и от неё надо стараться избавиться.
А создание ненастоящих фирм можно делать отдельным процессом, который будет контролировать наполненность тестовой фермы тестовыми сущностями. Так нагрузка будет не на тесты.
Рандом в тестах почти всегда зло. Хотя бы потому что повторить такой тест невозможно (если у вас нет ключика, который фиксирует состояние… но тогда это другой тест).
Покапитаню: Классы эквивалентности пробовали применять?
Покапитаню2: С выборкой "случайной" фирмы вы тестировали несуществующий кейз. Клиент может запросить "случайную фирму" (а-ля "фирма дня"?) Если нет, то и тесты (массово) такой подход не должны использовать.
Меня сейчас закидают тряпками, но я, всё же, выскажусь.
Все эти UI-тесты с эмуляторами реальных сервисов — это прекрасно. Но в 99% случаев не нужны, так как они могут спокойно проверяться без UI (селениум меняется на jasmine), calabash… ещё на что-нибудь другое. Не эмулируйте сервисы вообще, обходитесь в тестах без них.
UI-тесты (селениум, калабаш, эспрессо) — это финальный шаг, интеграционные тесты, их должно быть очень мало. Но именно они могут быть нестабильными. Главное, чтобы они были понятными и выдавали очевидные сообщения.
Пример: вы проверяете как работают платежи в релизной версии приложения и внезапно агрегатор выдаёт вам таймаут — что вы бы ожидали от автоматизированного сценария?
Лично я вижу два выхода:
1) сказать "ой, ну это не наша ошибка, наше приложение ведь нормально отработало"… и это будет flaky тест, только который вы выполнили руками
2) пусть упадёт автоматический сценарий, который сообщит вам, что отвалился платёжный гейт и проверить сценарий не представляется возможным. Хотите довериться своему всемогущему эмулятору, который показывал, что платёж будет проходить? Оцените риски и (не)релизьтесь. Не хотите? Подождите, когда гейт заработает и проверьте отвалившиеся сценарии.
Flaky — это не так плохо. Плохо — когда непонятно, почему flaky.
Конечно это специфика проекта. Например, у инстаграма основные кнопки без подписей.
Вообще про то, как писать эффективные локаторы много спорят. Вот, например, на selenium conf доклад был: https://www.slideshare.net/orenrubin/statistical-element-locator-by-oren-rubin-seleniumconf-uk-2016 Там ещё в кулуарах очень много разговоров было про то, как не сделать из такой штуки бегемота, но быстрого носорога :)
А пример про формочку — да, я его не очень сильно "придумывал", поэтому там легко решается проверкой другого вопроса. Ну так придумайте не опросник, а форму, в которой может ничего не изменяться, а что-то исчезать или появляться (например, фотография с одним и тем же адресом может меняться. или вообще flash-контент).
На мой личный взгляд, руководитель без развитой эмпатии — плохой руководитель. Ставить в пример Стива Джобса не надо :) А если мы говорим о том человеке, которому прощают его ошибки, и у него не развита эмпатия… И он этим пользуется… Ну так очевидно, что такой человек в коллективе работать не может. Он может быть прекрасным специалистом, но ему нужна какая-то особая работа, особый отдел из одного человека, с очень чётко обозначенными задачами. Это моё личное мнение.
Совершенно верно. Разве то, что это — прописная истина, делает её какой-то менее важной? У нас в культуре нет табу на прописную истину :)
Ну, вообще-то считается, что стоит прощать ошибки и оплошности тем, кто находится в стрессе из-за личных обстоятельств (ребёнок родился, переезд, что-то случилось).
У них настолько маленькая команда, что их встретить на каких-то конференциях вообще нереально, похоже. А ведь они многое чего могли рассказать!
(сразу же вспоминается одна из серий Silicon Valley)
Автор комментария — человек с ограниченными возможностями (посмотрите его посты)
нет, коллега никуда не попадал, это первая машина в UK. Индекс — возможно. Но как пишут на многих сайтах, то большее влияние может оказать сфера занятости.
во-первых, в британии требуется получение местных водительских прав (а не обмен) и российский стаж и no claim period не учитывается
во-вторых, через пару-тройку лет страховка должна стать как раз примерно эти же 400 евро
"Я вам не скажу за всю Одессу", но у нас с коллегами какие-то фантастические различия в цене страховки на машину. То есть, у коллеги и машина дешевле, и стаж — 10 лет, но ему не предлагают ниже 1200. У меня машина дороже, стаж — 3 года (да, права российские в первый год были), но страховка 700.
Я подозреваю, что надо "правильно" анкету заполнять :)
Я как раз один из таких ушибленных лондонских велосипедистов.
В штормовой ветер тяжело. И опасно, даже пешком.
Но ветер и температура, на самом деле, не представляют серьёзных проблем. А вот внезапно выпавший снег — это да. Его не убирают, он сам растает через пару дней, но в эти дни ездить нельзя.
Ещё один недостаток: ошибка может быть в генерации тестовых данных.
Я согласен с вами, что такой подход рабочий. Но нет ничего более постоянного, чем что-то временное :)
Некоторая ошибочность подхода (не фатальная) в том, что вы тестируете гораздо больше, чем вам надо. Просто "а почему бы и нет?" Раз вас пока это устраивает — исползуйте на здоровье :)
Нсли чистить не в рамках теста, а в рамках другой задачи (да хоть бы и автоматическим заданием в планировщике очередей), то скорость прохождения тестов не вырастет.
Чистилка не особо нужна, если каждый раз использовать эталонную базу (восстанавливать из докера / хранить слепок / всё что угодно).
Понятное дело, что вы сейчас говорите о каком-то реальном проекте, где это ну оооочень сложно реализовать уже. А вам тут о каком-то академическом примере талдычут. Ну так вот придёте как-нибудь на новый проект, где ещё код весь костылями не оброс и успеете туда прикрутить "чуть лучший" подход к тестированию.
Ваш случай граничный. Сложно придумать контраргумент. Возможно, даже и не нужно, ведь есть "допустимое зло" :)
Из тех условий, что вы приводите, рандомная генерация ключей единственное что не позволит воспроизвести какую-нибудь ошибку в БД или хранимых процедурах в БД.
Но это уже домыслы.
конечно! это приёмные тесты. Просто часто делают перекос в эту сторону и становится "1000 тестов на селениуме и 1000 юнит-тестов".
Ну моки и эмуляторы, всё-таки, разные вещи :) Я имел в виду именно эмуляторы в низкоуровневых тестах
Если у вас релиз, который не затрагивает интеграцию с агрегатором, то всё верно, согласен с вами, так и делается. А если переделана вся интеграция, то на ооооочень не хочется складывать все яйца в одну корзину "мы тут и интерацию написали, а ещё и пару багов в собственном эмуляторе пэйпала поправили". Ага. Так я и поверим им, что пару багов не добавили.
Если используете один и тот же seed или можете восстановить цепочку, то не зло.
Рандом как раз в тестах, просто во входных данных. Получается, что чистая функция "тест" обёрнута в обычную функцию "тест + входные данные" + рандомное время для извлечения тестовых данных.
Конечно, всегда есть некоторая рандомизация (да хотя бы время, в которое скрипт запустили — вдруг фирма уже прекратила существование и уже отправилась в архив), но и от неё надо стараться избавиться.
А создание ненастоящих фирм можно делать отдельным процессом, который будет контролировать наполненность тестовой фермы тестовыми сущностями. Так нагрузка будет не на тесты.
Рандом в тестах почти всегда зло. Хотя бы потому что повторить такой тест невозможно (если у вас нет ключика, который фиксирует состояние… но тогда это другой тест).
Покапитаню: Классы эквивалентности пробовали применять?
Покапитаню2: С выборкой "случайной" фирмы вы тестировали несуществующий кейз. Клиент может запросить "случайную фирму" (а-ля "фирма дня"?) Если нет, то и тесты (массово) такой подход не должны использовать.
Меня сейчас закидают тряпками, но я, всё же, выскажусь.
Все эти UI-тесты с эмуляторами реальных сервисов — это прекрасно. Но в 99% случаев не нужны, так как они могут спокойно проверяться без UI (селениум меняется на jasmine), calabash… ещё на что-нибудь другое. Не эмулируйте сервисы вообще, обходитесь в тестах без них.
UI-тесты (селениум, калабаш, эспрессо) — это финальный шаг, интеграционные тесты, их должно быть очень мало. Но именно они могут быть нестабильными. Главное, чтобы они были понятными и выдавали очевидные сообщения.
Пример: вы проверяете как работают платежи в релизной версии приложения и внезапно агрегатор выдаёт вам таймаут — что вы бы ожидали от автоматизированного сценария?
Лично я вижу два выхода:
1) сказать "ой, ну это не наша ошибка, наше приложение ведь нормально отработало"… и это будет flaky тест, только который вы выполнили руками
2) пусть упадёт автоматический сценарий, который сообщит вам, что отвалился платёжный гейт и проверить сценарий не представляется возможным. Хотите довериться своему всемогущему эмулятору, который показывал, что платёж будет проходить? Оцените риски и (не)релизьтесь. Не хотите? Подождите, когда гейт заработает и проверьте отвалившиеся сценарии.
Flaky — это не так плохо. Плохо — когда непонятно, почему flaky.
Когда тесты идут рука об руку с кодом — это замечательно.
Главное из таких исключительных ситуаций не делать норму.
Мы друг друга поняли :)
Да, виноват. Хотел написать "тест должен упасть сразу же".
Конечно это специфика проекта. Например, у инстаграма основные кнопки без подписей.
Вообще про то, как писать эффективные локаторы много спорят. Вот, например, на selenium conf доклад был: https://www.slideshare.net/orenrubin/statistical-element-locator-by-oren-rubin-seleniumconf-uk-2016 Там ещё в кулуарах очень много разговоров было про то, как не сделать из такой штуки бегемота, но быстрого носорога :)
А пример про формочку — да, я его не очень сильно "придумывал", поэтому там легко решается проверкой другого вопроса. Ну так придумайте не опросник, а форму, в которой может ничего не изменяться, а что-то исчезать или появляться (например, фотография с одним и тем же адресом может меняться. или вообще flash-контент).