Здравствуйте, Codealot, Вы писали:
N>>А это уже вопрос, насколько ты пытаешься обеспечить тесты, а насколько — реальные спецификации.
C>Я — реальные спецификации. В отличие от.
По спецификации может быть и миллиард вариантов использования, ты протестировал выбранную сотню. А за её пределами тут же всё начало падать.
N>>Ну так нефиг заведомой ерундой интересоваться.
C>Вопрос не ко мне.
Больше не к кому, ты ж поставил ребром с самого начала.
Здравствуйте, netch80, Вы писали:
C>>Ты еще скажи, что полное отсутствие багов обеспечивается выполнением спецификаций по каждому компоненту. N>Не утрируй, да не утрируем будешь (c)
Не юли.
N>Уже писал, что моки и взаимодействие с ними проверить в десятки раз легче и дешевле, чем влезть во взаимодействие компонент в интеграционном месте. N>Чем проще, тем меньше места для ошибки, меньше замыливается глаз, легче запускается отдельно, и всё такое.
И бесполезнее. Ты не знаешь, что твои моки соответствуют реальности. И не можешь узнать.
Ну во первых, предыдущий оратор говорил о цене за запуск, а не за год. Небольшая такая разница.
N>Например 1000000$/год = 114$/час = 318.3 инстанса каких-нибудь AWS t3.x2large в Бомбее. Это небольшие инстансы по нынешним временам, 8 хартов и 32GB оперативки, совсем копейки. (Я ещё диск и I/O не считал, цена может удвоиться как минимум. Пока подсчитаем только CPU.)
Если купить, то такое железо не дотянет даже до $800. И проработает много лет.
Нет покоя долбанутым.
Здравствуйте, Codealot, Вы писали:
C>Ну во первых, предыдущий оратор говорил о цене за запуск, а не за год. Небольшая такая разница.
"Запуск интеграционных тестов" это долговременное свойство процесса разработки. Смысл "один запуск", "каждый запуск" в прочтение внёс ты сам, непонятно зачем.
N>>Например 1000000$/год = 114$/час = 318.3 инстанса каких-нибудь AWS t3.x2large в Бомбее. Это небольшие инстансы по нынешним временам, 8 хартов и 32GB оперативки, совсем копейки. (Я ещё диск и I/O не считал, цена может удвоиться как минимум. Пока подсчитаем только CPU.) C>Если купить, то такое железо не дотянет даже до $800. И проработает много лет. C>Нет покоя долбанутым.
Теперь ещё подсчитай цену аренды/владения местом, электричества (качественного), охлаждения, охраны, толкового админа, и так далее. -Это неоднократно мерялось и был вывод, что для "первого мира" цена AWS и аналогов при покупке на 2-3 года вперёд (у Амазона есть такие варианты покупки) соответствует 1:1 тому, что если бы строили собственный ДЦ или даже просто набор стоек, а при покупке "по требованию" где-то в 2 раза дороже (о чём я и написал). Спотовые можно получить дешевле, но нет гарантии, что никто не прервёт (хотя именно запускать еженощную полную интеграцию на них — достаточно неплохой вариант).
наконец, твое "много лет" может устареть по множеству причин. На одной из прошлых работ было так: надо было ускорить некоторый реально критический путь (до микросекунд), заказчик владел в количестве до чёрта и больше толстыми серверами (типа 4*Xeon, 96GB RAM и прочее), но... Nehalem based. Кто возился с performance counters, знает, что в Nehalem их реально нихера, более-менее нормальный комплект начал появляться в Sandy Bridge, а лучше было брать следующее (дело было лет 6+ назад). И я так и не добился нормальной базы, оптимизировал реально наугад. С наёмными серверами (даже голым железом) такого нет, перестал арендовать и всё.
Здравствуйте, Codealot, Вы писали:
C>>>Ты еще скажи, что полное отсутствие багов обеспечивается выполнением спецификаций по каждому компоненту. N>>Не утрируй, да не утрируем будешь (c)
C>Не юли.
О, КСВ в действии.
N>>Уже писал, что моки и взаимодействие с ними проверить в десятки раз легче и дешевле, чем влезть во взаимодействие компонент в интеграционном месте. N>>Чем проще, тем меньше места для ошибки, меньше замыливается глаз, легче запускается отдельно, и всё такое.
C>И бесполезнее. Ты не знаешь, что твои моки соответствуют реальности. И не можешь узнать.
Здравствуйте, Codealot, Вы писали:
_>>и вместо того чтобы пофиксить проблему, ты предлагаешь продолжить забивать на нее. ну молодец, чо...
C>Вообще ничего подобного я не предлагал, не высасывай из пальца.
ну то есть юнит-тесты с моками нужны и ты так всегда знал и считал а то я уж подумал "очередной джуниор все знающий разбушевался"
вопрос закрыт
Здравствуйте, netch80, Вы писали:
N>Это бывает в двух случаях:
N>1) Да, не сделали межкомпонентный интеграционный тест. Заметь, я ни разу не говорил, что он не нужен. Но я говорил, что с моками тест лучше определяет основную часть проблем.
По моему моки большей частью признак неверного дизайна, или неверно выбранного уровня тестирования. Мок принципиально поведенческий тест, что дает сильно слабые гаратии.
Моками можно тестировать сложные кейсы взаимодействия. Но общее правило такое, что если можно написать без моков, то стоит писать именно так. Проверка на value, или на state дает куда больше гарантий, чем assert(x).to.be.called.with.
Что бы тестировать самые разные варианты ответа сервера, нам приемник результата нужно оформить как функцию, тогда в нее можно хоть миллион вариантов подкинуть и проверить все.
Здравствуйте, baxton_ulf, Вы писали:
_>ну то есть юнит-тесты с моками нужны и ты так всегда знал и считал а то я уж подумал "очередной джуниор все знающий разбушевался" _>вопрос закрыт
Здравствуйте, netch80, Вы писали:
N>"Запуск интеграционных тестов" это состояние процесса. Смысл "один запуск", "каждый запуск" в прочтение внёс ты сам, непонятно зачем.
Либо оратор крайне странно выразил свои мысли, либо ты мутишь воду.
N>Теперь ещё подсчитай цену аренды/владения местом, электричества (качественного), охлаждения, охраны, толкового админа, и так далее.
Решается покупкой стоек в колокейшене, если совсем уж лень.
N>Это неоднократно мерялось и был вывод, что для "первого мира" цена AWS и аналогов при покупке на 2-3 года вперёд (у Амазона есть такие варианты покупки) соответствует 1:1 тому, что если бы строили собственный ДЦ или даже просто набор стоек
А бабло, которое позволяет облачным провайдерам грести его лопатой, очевидно берется из тумбочки.
N>С наёмными серверами (даже голым железом) такого нет, перестал арендовать и всё.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, baxton_ulf, Вы писали:
_>>ну то есть юнит-тесты с моками нужны и ты так всегда знал и считал а то я уж подумал "очередной джуниор все знающий разбушевался" _>>вопрос закрыт
C>Чувак, твоя "логика" просто чудовищна.
Здравствуйте, Ikemefula, Вы писали:
N>>Это бывает в двух случаях:
N>>1) Да, не сделали межкомпонентный интеграционный тест. Заметь, я ни разу не говорил, что он не нужен. Но я говорил, что с моками тест лучше определяет основную часть проблем.
I>По моему моки большей частью признак неверного дизайна, или неверно выбранного уровня тестирования. Мок принципиально поведенческий тест, что дает сильно слабые гаратии.
Чем они слабые?
И какое это имеет значение в пределах данного обсуждения, где ТС предлагал такие же поведенческие тесты, но на верхнем уровне интеграции?
I>Моками можно тестировать сложные кейсы взаимодействия. Но общее правило такое, что если можно написать без моков, то стоит писать именно так. Проверка на value, или на state дает куда больше гарантий, чем assert(x).to.be.called.with.
Смотря чего ты хочешь добиться. Например, какой именно запрос был отправлен на сервер, ты не увидишь в состоянии тестируемого клиента — следа не осталось. А это постоянно нужно проверять.
I>Что бы тестировать самые разные варианты ответа сервера, нам приемник результата нужно оформить как функцию, тогда в нее можно хоть миллион вариантов подкинуть и проверить все.
Гм. Попытался себе представить как функцию работу софтсвича из любимого проекта. Там только слоёв протокола пять штук, а ещё и собственная логика поверх всего этого...
Здравствуйте, Codealot, Вы писали:
N>>"Запуск интеграционных тестов" это состояние процесса. Смысл "один запуск", "каждый запуск" в прочтение внёс ты сам, непонятно зачем. C>Либо оратор крайне странно выразил свои мысли, либо ты мутишь воду.
Либо ты не знаком с соответствующей практикой, либо и не пытался понять, что писал оппонент.
Я с ним не согласен почти во всём, но тут он говорил дело.
N>>Теперь ещё подсчитай цену аренды/владения местом, электричества (качественного), охлаждения, охраны, толкового админа, и так далее. C>Решается покупкой стоек в колокейшене, если совсем уж лень.
За ту же цену.
N>>Это неоднократно мерялось и был вывод, что для "первого мира" цена AWS и аналогов при покупке на 2-3 года вперёд (у Амазона есть такие варианты покупки) соответствует 1:1 тому, что если бы строили собственный ДЦ или даже просто набор стоек C>А бабло, которое позволяет облачным провайдерам грести его лопатой, очевидно берется из тумбочки.
1. Дочитывай до конца. Я там про инстансы "по требованию" не зря писал. За удобство берут больше, и в данном случае переплата колоссальна.
2. На долгосрочных покупках — облачники экономят за счёт унификации администрирования в крупных масштабах.
N>>С наёмными серверами (даже голым железом) такого нет, перестал арендовать и всё. C>После того как ты заплатил на 2-3 года вперед?
Мне не нужно было долго тестировать, хватило бы пары недель.
Здравствуйте, vsb, Вы писали:
C>>В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно. C>>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает. C>>Я чего-то не понимаю?
vsb>Скорость выполнения. У меня интеграционный тест запускается секунд 10 (поднимается в докере БД, стартует спринг, создаётся схема, данные), далее каждый тест выполняется около 1 секунды. vsb>С моками юнит-тест выполняется микросекунды. То бишь гораздо проще тестировать весь функционал в юнит-тестах. А функциональные тесты на самые основные сценарии, просто чтобы проверить, что ничего в целом не сломалось.
Э-э… Как вообще скорость выполнения может быть критерием для тестов? Это ж как под фонарём искать.
Здравствуйте, Codealot, Вы писали:
MD>>Вот такой сценарий вплоне можно покрыть моками через генерацию соответствующего data stream:
C>Интеграционными тестами тоже.
Если под интеграционными тестами подразумевается запуск из командной строки, то так и надо, ИМХО. Зачем читать data stream из файла через какой-то мок, когда соответствующий код уже встроен в приложение и его тоже надо тестировать?
Здравствуйте, Codealot, Вы писали:
C>Ну во первых, предыдущий оратор говорил о цене за запуск, а не за год. Небольшая такая разница.
N>>Например 1000000$/год = 114$/час = 318.3 инстанса каких-нибудь AWS t3.x2large в Бомбее. Это небольшие инстансы по нынешним временам, 8 хартов и 32GB оперативки, совсем копейки. (Я ещё диск и I/O не считал, цена может удвоиться как минимум. Пока подсчитаем только CPU.)
C>Если купить, то такое железо не дотянет даже до $800. И проработает много лет. C>Нет покоя долбанутым.
Между прочим, Google way!
Когда Гугл заказывал первые сервера, они просто купили у одного местного мужика кучу персоналок со скидкой. Когда мужик осознал, сколько он заработал на этой сделке века (примерно 0), он настолько разъярился, что просто выгрузил компьютеры на парковке возле их офиса и уехал. (Не исполнять контракт он уже не мог).
А когда они доплыли до бомбейских облаков, у них уже на каждый потраченный миллион приходилось намного больше заработанных миллионов.
Почему-то вот не стали они начинать свой путь с экономии путём написания моков.
Здравствуйте, Codealot, Вы писали:
N>>За ту же цену.
C>Вот сейчас ты вообще бред написал. Даже и близко не за ту же.
Аргументация уровня "бог". Попробовать сам сравнить не хочешь?
N>>Мне не нужно было долго тестировать, хватило бы пары недель. C>Для краткосрочного использования облако вполне имеет смысл, кто бы спорил.
а то я уж подумал "очередной джуниор все знающий разбушевался" 
