Здравствуйте, Codealot, Вы писали:
C>А бабло, которое позволяет облачным провайдерам грести его лопатой, очевидно берется из тумбочки.
Нет, оно зарабатывается за счет масштабов. Реальные системы не жрут постоянно фиксированное количество машин, у них есть автоскейлинг. Когда у тебя очень много разных проектов, нагрузка более менее выравнивается за счет того, что когда одному клиенту нужна нагрузка, у другого наоборот нагрузка спала. А со своим ДЦ автоскейлинг не имеет особого смысла, так как отдаунскейленые машины все равно скорее всего будут простаивать.
Здравствуйте, Ikemefula, Вы писали:
I>А как ты это моками решаешь? Моки нам нужны что бы в спагетти коде изоливать какой то путь. Можно пойти иначе — выделить этот путь в функцию и превратить тест в компонентный.
Здравствуйте, Shtole, Вы писали:
S>У меня был большой тест, который тормозил на ноуте, не давал оперативно коммититься, пришлось переносить его выполнение на удалёную машину. Но он реально пользу приносил и заменять его другим типом тестов по причине скорости я как-то не догадался.
Т.е. ежики плакали, кололись, но продолжали жрать кактус?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>А как ты это моками решаешь? Моки нам нужны что бы в спагетти коде изоливать какой то путь. Можно пойти иначе — выделить этот путь в функцию и превратить тест в компонентный.
НС>И почему вдруг компонентному тесту не нужны моки?
Потому, что дизайн компонента делается с учетом того, что его придется использовать, тестировать и тд.
Моки сами по себе дают слабые гарантии, их стоит использвать только если нет ничего лучше.
Соответсвенно для компонента есть value и state тест, который дает куда большие гарантии.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Потому, что дизайн компонента делается с учетом того, что его придется использовать, тестировать и тд.
НС>И если у компонента есть внешние зависимости, то ... ?
"дизайн компонента делается с учетом того, что его придется использовать, тестировать и тд"
Правило номер один — отказать
Правило номер два — см правило номер два
Внешних зависимостей может быть сколько угодно, проблемой являются бд, стораджи и подобные вещи. Странно, что компонент зависит от таких вещей.
Остальных зависимостей может быть сколько угодно, это не страшно.
т.е. у нас где то появляется какой нибудь контроллер, т.е. интеграционный код, который связывает всё вместе — компоненты, стораджи и тд. только связывает не пропихиванием ссылок, а просто через данные — выхлоп одного идет на вход другого.
Вот для этого контроллера уже понадобится интеграционный тест, и тут придется слегка понизить уровень тестирования при помощи моков-стабов, если дорого подключаться к бд.
Но на самом деле это просто компромисс — каких до дополнительных бенефитов это не дает. Просто потому, что с моками ты всегда тестируешь против той синтетики, которую сам же насовал в них. И раз это поведенческие тесты, то гарантии слабоватые. Например, без проверки на результат assert(x).to.have.been.called.once ничего внятного дает. т.е. факт в том, что тесты на моках надо все равно подкреплять через value/state
Здравствуйте, ·, Вы писали:
·>Ты результат запуска теста будешь четыре месяца ждать или таки замокаешь clock?
Я буду передавать дату как параметр метода который считает.
·>Эээ.. В чём проблема моком кинуть исключение при чтении 13-го байта?
Откуда кинуть и какое?
·>Т.е. мокать в самом языке плохо используя простенькую либу, а тащить некий подозрительный спец-софт и мокать где-то снаружи внезапно хорошо.
Да, это хорошо, потому что не создает лишние вмешательства в софт.
·>Читаю: "Я чего-то не понимаю?". Отвечаю: "Да".
Подчеркиваю для чукчеписателей. Ключевое слово — вместо.
Здравствуйте, Sinclair, Вы писали:
S>Да нет тут никакой точки. Спецификации — это очень слабое описание.
[...] S>Вот у вас есть, скажем, сервис, который выставляет два метода: S>А потом запускаете в прод — и выясняется, что реальный сервис при попытке загрузки аватара сразу после после регистрации пользователя даёт ошибку "пользователь не найден". Ну, потому что на том конце ребята сделали лоад балансинг и евеншуал консистенси. А ваш мок ничего подобного не делает, потому что в спецификации про это ничего нету.
1. Я в отличие от ТС не предлагаю или-или. Тесты должны быть обоих видов — и на компонент с моками для внешних зависимостей, и на полную интеграцию.
2. В этом конкретном случае, значит, спецификация врёт и от этого будут проблемы посерьёзнее, чем сломанный тест. Вот её и надо править.
Здравствуйте, Shtole, Вы писали:
S>>>Э-э… Как вообще скорость выполнения может быть критерием для тестов? N>>Время — деньги. Короче цикл от написания до тестирования — легче проходит изменение — быстрее разработка. Меньше задалбывается разработчик — меньше багов. S>Я имел в виду следующее. Если какой-то вид тестов не способен отловить в данном проекте ошибки, которые ловятся только этим видом тестов, он не нужен вообще. А если способен, то какая разница, как быстро они выполняются — всё равно без них никуда.
Это у вас получилось достаточное условие применения конкретных тестов. А для минимизации ресурсов опираться надо на необходимые условия. Не "какой способен", а без каких не обойтись.
И уже в этих пределах заниматься оптимизацией подхода (для которой и оказывается, что хоть интеграционные тесты верхнего уровня и нужны, но чем больше перевалить на нижние уровни, тем легче).
S>У меня был большой тест, который тормозил на ноуте, не давал оперативно коммититься, пришлось переносить его выполнение на удалёную машину. Но он реально пользу приносил и заменять его другим типом тестов по причине скорости я как-то не догадался.
Вполне возможно, если проверять по частям, этот тяжёлый тест можно было перенести, например, на ежесуточный запуск.
Здравствуйте, Codealot, Вы писали:
C>·>Ты результат запуска теста будешь четыре месяца ждать или таки замокаешь clock? C>Я буду передавать дату как параметр метода который считает.
В интеграционном тесте через специализированный софт?
Более того, взятие текущего времени может происходить несколько раз в процессе работы алгоритма, поэтому не всегда можно передать единственный таймстамп, а нужно передавать источник текущего времени.
C>·>Эээ.. В чём проблема моком кинуть исключение при чтении 13-го байта? C>Откуда кинуть и какое?
Ну смотришь спеку твоего Network API и там всё описано где какие исключения бросаются в каких ситуациях.
C>·>Т.е. мокать в самом языке плохо используя простенькую либу, а тащить некий подозрительный спец-софт и мокать где-то снаружи внезапно хорошо. C>Да, это хорошо, потому что не создает лишние вмешательства в софт.
Тесты тоже не вмешиваются в софт и выполняются отдельно. Если "писать легко тестируемый код" является для тебя "лишним вмешательством", то у меня для тебя плохие новости.
C>·>Читаю: "Я чего-то не понимаю?". Отвечаю: "Да". C>Подчеркиваю для чукчеписателей. Ключевое слово — вместо.
Во-первых, собрать приложение из хорошо протестированных компонентов — просто и относительно легко обеспечить "компилируется, значит работает", тестирование интеграции заключается в "при запуске приложение не падает".
Во-вторых, главная цель — тестировать бизнес-логику, а не интеграцию. Так что если ИТ и нужны, то их нужно на порядки меньше чем ЮТ с моками.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>>>По моему моки большей частью признак неверного дизайна, или неверно выбранного уровня тестирования. Мок принципиально поведенческий тест, что дает сильно слабые гаратии. N>>Чем они слабые? I>Да всем. Кроме того, что слабые, так еще и тесты выходят дорогими в силу хрупкости. Например, assert(x).to.be.called.with ничего не говорит про то, как мы обошлись с результатом, вернули его или нет. А раз так, то всё равно надо писать тест на value/state.
Факт возврата результата очевиден из факта самого вызова того метода, вызов которого проверяется. Вызов был — значит, он вернул результат.
Value/state может не существовать для того, что в остальном stateless. Вот я имитирую ответ от биллинга. В запросе было need_foo=1 — один ответ, не было — другой. Состояние появляется только если ставить тут мок, который будет записывать "ой, меня спросили".
N>>Смотря чего ты хочешь добиться. Например, какой именно запрос был отправлен на сервер, ты не увидишь в состоянии тестируемого клиента — следа не осталось. А это постоянно нужно проверять. I>Это надо делать в компонентных тестах, и гарантировать, что компонент обладает нужными свойствами. А в интеграционных нам не надо подсовывать мок — нам достаточно проверить, что нужный компонент вызывается.
1. И этот компонент должен отдать нужный ответ, а не просто зафиксировать "ой меня вызвали".
2. И чем это будет отличаться от assert_called_with?
I> И если мы получили ожидаемый результат, то значит этот компонент интегрирован правильно.
Кто с кем интегрирован? Твоя мысль перестала быть понятной.
I>>>Что бы тестировать самые разные варианты ответа сервера, нам приемник результата нужно оформить как функцию, тогда в нее можно хоть миллион вариантов подкинуть и проверить все. N>>Гм. Попытался себе представить как функцию работу софтсвича из любимого проекта. Там только слоёв протокола пять штук, а ещё и собственная логика поверх всего этого... I>А как ты это моками решаешь?
Disclaimer: я не знаю, в какой традиции у кого что называется "моком". Я тут понимаю это слово в предельно общем смысле. Эмулятор биллинга, который умеет отвечать на два запроса фиксированными ответами — мок. Эмулятор телефона, который умеет только принять сигнализацию — мок. Кому-то, может, важно, это стаб, прокси или эмулятор. Мне тут — нет.
Так вот — если свич вовремя позвонил на нужный телефон, передал нужные данные в сигнализации, передал нужные слова в описании медии и т.д. — то для теста почти верхнего уровня всё ok. На более низком своя специфика — может, я не буду проверять весь звонок, а буду проверять только установочную транзакцию. И так далее, по обстановке.
Ну и когда у меня таки толпа тьмущая уровней логики — рисовать функции на всё это... ну я мог бы, конечно, сделать, что какой-нибудь сессионный уровень использует мок вместо транзакционного, и в юнит-тестах местами так и делается — но обычно проще и при этом достаточно эффективно заложиться на то, что если нижний уровень проверен, то мы его и используем полностью. А если сложная ошибка, вызванная нижним уровнем, то это и так требует специального разбора.
I> Моки нам нужны что бы в спагетти коде изоливать какой то путь.
Ничего тут не понял.
I> Можно пойти иначе — выделить этот путь в функцию и превратить тест в компонентный. Слоев протокола пять штук — значит компонентных тестов должно быть так же 5 штук. Мне совсем неочевидно, зачем здесь нужны моки.
Что и как ты считаешь? Может, хотя бы 5 комплектов тестов?
А то количество сценариев типа "пока сессия думала над перепосылкой оффера в сторону A, ей прислали оффер-реквест со стороны B" по-нормальному вылазит за сотню, и проверить их в одном тесте нереально.
I>Моками мы можем закрыть тесты lifecycle, hooks, events и тд. Все остальное это "особый" дизайн, когда нет возможности написать простой компонентный тест, и начинаем изыскивать дикие вещи.
Ты превращаешь специфический опыт своего локального домена в высокую Обстракцию и в таком виде пытаешься доказать мне её эксклюзивную истинность для заведомо другого домена.
Здравствуйте, Ikemefula, Вы писали:
I>Правило номер один — отказать
В чем отказать? В тестировании?
I>Внешних зависимостей может быть сколько угодно, проблемой являются бд, стораджи и подобные вещи. Странно, что компонент зависит от таких вещей.
Как это? Связь определяется задачей. Если она нужна, значит она будет в каком то из компонентов.
I>т.е. у нас где то появляется какой нибудь контроллер
Контроллер это не компонент? Или этокомпонент, который не надо тестировать?
I>Вот для этого контроллера уже понадобится интеграционный тест,
Здравствуйте, Codealot, Вы писали:
C>·>Ты результат запуска теста будешь четыре месяца ждать или таки замокаешь clock? C>Я буду передавать дату как параметр метода который считает.
ну т.е. мокать компонент возвращающий текущую дату
C>·>Эээ.. В чём проблема моком кинуть исключение при чтении 13-го байта? C>Откуда кинуть и какое?
кинуть из мока. какое исключение нужно, такое и кидаешь
C>·>Т.е. мокать в самом языке плохо используя простенькую либу, а тащить некий подозрительный спец-софт и мокать где-то снаружи внезапно хорошо. C>Да, это хорошо, потому что не создает лишние вмешательства в софт.
тесты и моки не вмешиваются в софт
C>·>Читаю: "Я чего-то не понимаю?". Отвечаю: "Да". C>Подчеркиваю для чукчеписателей. Ключевое слово — вместо.
про "вместо" тебе уже отвечали, ты случаем сам не из этих "чукчеписателей" ?
I>>Внешних зависимостей может быть сколько угодно, проблемой являются бд, стораджи и подобные вещи. Странно, что компонент зависит от таких вещей.
НС>Как это? Связь определяется задачей. Если она нужна, значит она будет в каком то из компонентов.
я тоже как прочел перл выше, сразу представил этакий "сферический компонент в вакууме"
но все же думаю это просто легкая косноязычность и имелось ввиду, что компонент должен быть отделен от тех зависимостей какой то абстракцией. опять же не понятно почему это не надо тестировать
Здравствуйте, netch80, Вы писали:
S>>Я имел в виду следующее. Если какой-то вид тестов не способен отловить в данном проекте ошибки, которые ловятся только этим видом тестов, он не нужен вообще. А если способен, то какая разница, как быстро они выполняются — всё равно без них никуда. N>Это у вас получилось достаточное условие применения конкретных тестов. А для минимизации ресурсов опираться надо на необходимые условия.
Вы очень красиво и грамотно сформулировали. Я б так не смог. Но это не значит, что я с вами согласен
S>>У меня был большой тест, который тормозил на ноуте, не давал оперативно коммититься, пришлось переносить его выполнение на удалёную машину. Но он реально пользу приносил и заменять его другим типом тестов по причине скорости я как-то не догадался.
N>Вполне возможно, если проверять по частям, этот тяжёлый тест можно было перенести, например, на ежесуточный запуск.
Ну разумеется, я сначала попробовал реже тестировать (ежесуточный запуск). Потом стал маркировать его куски Full/Optional. Он стал быстрее. И стал хуже ловить проблемы.
Здравствуйте, Shtole, Вы писали:
N>>Вполне возможно, если проверять по частям, этот тяжёлый тест можно было перенести, например, на ежесуточный запуск.
S>Ну разумеется, я сначала попробовал реже тестировать (ежесуточный запуск). Потом стал маркировать его куски Full/Optional. Он стал быстрее. И стал хуже ловить проблемы.
Да, если часть тестов не запускать, они не будут ловить то, для чего были предназначены. Это банальность. Вопрос, что дальше с этой банальностью делать.
Мне очевидно, что надо держать баланс между быстрым комплектом тестов и (неизбежно медленным) полным комплектом. А вы что предложите практически ценного?
S>Вы очень красиво и грамотно сформулировали. Я б так не смог. Но это не значит, что я с вами согласен
Здравствуйте, netch80, Вы писали:
N>А вы что предложите практически ценного?
Я же написал, что сделал в этой ситуации я в первую очередь: изыскал дополнительные вычислительные ресурсы.
S>>Вы очень красиво и грамотно сформулировали. Я б так не смог. Но это не значит, что я с вами согласен N>И какие возражения?
В самом общем виде возражения сводятся к тому, что вы поставляете юзерам продукт, а не набор компонентов, которые друг друга тестируют в мок и в гриву, и если озабочены качеством, то и тестировать надо продукт. Это соображение имеет приоритет намного выше, чем сраный перфоманс исполнения. Сколько всего понавылезало таким путём, я мог бы (но не буду) долго перечислять, из самого эпичного — вскрытый таким путём недокументированный таймаут 30 секунд на очередь операций в одном из серверных майкрософтовсих продуктов (тогда он был не облачным). Это в корне поменяло архитектуру в середине разработки. И вот на этом фоне я читаю, как надо было перестать «жрать кактус» и перейти на моки. Чтобы, значить, с таким не столкнуться. P.S. И это не было нагрузочное тестирование, ни в каком смысле.
.
S>В самом общем виде возражения сводятся к тому, что вы поставляете юзерам продукт, а не набор компонентов, которые друг друга тестируют в мок и в гриву, и если озабочены качеством, то и тестировать надо продукт.
Это банальность. Только это часть правды.
S> Это соображение имеет приоритет намного выше, чем сраный перфоманс исполнения.
В каком контексте оно имеет приоритет выше? Опять же банальность — перед релизом нужно прогнать все возможные тесты. Вот только тесты гоняются не только перед релизом. А, скажем, при каждом коммите или просто при отладке разрабатываемого сервиса. В этом контексте тоже твое соображение имеет приоритет перед перфомансом?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В каком контексте оно имеет приоритет выше? Опять же банальность — перед релизом нужно прогнать все возможные тесты. Вот только тесты гоняются не только перед релизом. А, скажем, при каждом коммите или просто при отладке разрабатываемого сервиса. В этом контексте тоже твое соображение имеет приоритет перед перфомансом?
К слову. Вот свежий материал по автоматизации тестирования: https://habr.com/ru/post/652499/ Он безусловно интересный и полезный, но некоторые моменты меня убивают. Вот какой график строит автор:
Для автора польза (Net Value) меняется плавно. Такая вот у него модель в голове. И здесь я вижу схожие рассуждения. Netch пишет про баланс. Вы пишете про «перед релизом». А в реальности что значит найти такой трюфель, как я нашёл (я про таймаут, потребовавший переписывания)? Если он найден ближе к концу проекта, это означает, что УСЁ! Всем спасибо, все свободны. Проект закрыт, кина не будет.
Я даже не знаю, как изображать такие вещи на графике. Если степень освоения бюджета в этот момент ещё позволяет всё переписать, это значит, что график в этом месте внезапно асимптотически уходит вверх. Польза абсолютна. А если нет? Что тогда нарисовать? И как вообще изобразить то, что никакой сюрприз может и не найтись?
Вот в таком вот контексте.
S>>Я же написал, что сделал в этой ситуации я в первую очередь: изыскал дополнительные вычислительные ресурсы. НС>Ага, и в итоге приходим к этому
Если у вас настолько масштабный продукт, что это всё имеет смысл, расходы окупятся и будут, возможно, сильно меньше потенциальных потерь. Если не настолько масштабный, вам там же и ответили: есть способы дешевле на три порядка.
Всё это, на самом деле, больше относится к риск-менеджменту, чем программированию как таковому. Если у вас есть два компонента — например, бизнес-платформа от одного вендора и генератор отчётов от другого — без интеграционных тестов шансы вообще пройти этот квест сильно понижаются. Генератор отчётов может тормозить, но пользователя это устраивает, и в договоре не будет прописано, что поставляемый генератор должен отрабатывать за заданное время (на это ни вы, ни заказчик повлиять не можете никак), зато в договоре будет прописано, что отчёт должен быть сгенерирован официальным продуктом. А платформа может считать, что вы обязаны выполнять норматив. И на это вы в силу размеров вендора повлиять тоже не можете. Можете только писать с учётом этой особенности и надеяться, что других не обнаружится. В таких ситуациях отказываться от тормозных интеграционных тестов по причине тормознутости — ну, welcome to suicide squad.
Можно по-другому управлять рисками. Не использовать генератор отчётов, который стандарт в отрасли, не использовать платформу, которой заказчику все уши прожжужали. Писать всё своё. Но тогда другие проблемы появляются. Прежде всего, отсутствие желающих за это платить.
Здравствуйте, Shtole, Вы писали:
N>>А вы что предложите практически ценного? S>Я же написал, что сделал в этой ситуации я в первую очередь: изыскал дополнительные вычислительные ресурсы.
С какой частотой вы зовёте этот тест в его полном виде? На какие события?
S>В самом общем виде возражения сводятся к тому, что вы поставляете юзерам продукт, а не набор компонентов, которые друг друга тестируют в мок и в гриву, и если озабочены качеством, то и тестировать надо продукт. Это соображение имеет приоритет намного выше, чем сраный перфоманс исполнения.
Верно. Перед передачей юзерам надо пройти полный комплект тестов, включая интеграционные верхнего уровня. Но нужно ли это делать для каждого коммита? А если промежуточные рабочие коммиты?
S> Сколько всего понавылезало таким путём, я мог бы (но не буду) долго перечислять,
Верно. Обойдёмся без ненужных банальностей.
S> из самого эпичного — вскрытый таким путём недокументированный таймаут 30 секунд на очередь операций в одном из серверных майкрософтовсих продуктов (тогда он был не облачным). Это в корне поменяло архитектуру в середине разработки. И вот на этом фоне я читаю, как надо было перестать «жрать кактус» и перейти на моки. Чтобы, значить, с таким не столкнуться.
Здесь нет оснований для вывода, что "переход на моки" оттянул бы обнаружение проблемы. (Да, я ещё раз повторю, что позицию топикстартера "или одно, или другое" считаю обструктивной и некорректной.) На скорость обнаружения проблемы влияет скорее выбор между режимами разработки водопад/agile (применяю эти понятия в общем смысле), в случае "водопада" можно действительно не заметить до последнего момента.
