ПФ
Приёмочное тестирование — не плохая, а необходимая практика 😊
Size: a a a
2021 July 09
ПФ
Ну а в больших проектах миллионы юнитов, да
MK
Именно так.
MK
(И то, и другое и еще несколько систем)
VS
Зависит от бизнес-логики. В 99% случаев память не на java.lang.Thread будет потребляться, а на бизнес-логику.
Поэтому, если физически можно запустить 1000 тестов в параллель, то вряд ли важно в чём их запускать (в тредах или корутинах)
Вот пример: https://github.com/apache/jmeter/pull/540
Это pull request, который добавляет поддержку корутин в JMeter.
На моём ноутбуке (4core 8threads) разницы между 5’000-10’000 корутино-тредами нет.
Поэтому, если физически можно запустить 1000 тестов в параллель, то вряд ли важно в чём их запускать (в тредах или корутинах)
Вот пример: https://github.com/apache/jmeter/pull/540
Это pull request, который добавляет поддержку корутин в JMeter.
На моём ноутбуке (4core 8threads) разницы между 5’000-10’000 корутино-тредами нет.
MK
В компании принят подход, что юнит тесты, это для разработки. А норм тест, пишет специальный, отдельный человек и покрывает все юзкейсы системы рассматривая ее как блекбокс
MK
Тысячи тестов я не упоминал, я упоминал сотню
MK
На билд тачке не проверял. Проверял на личном локалхосте (i7700k, 32gb DDR4). Потребление памяти не смотрел, смотрел время прогона пачки "тестов". Время прогона смотрел некошерно, просто сравнивая currentTime() до и после "тестов".
На моей тачке после 40к тредов, время исполнения начинает стремится к бесконечности. До этого числа время исполнения практически идентично.
На моей тачке после 40к тредов, время исполнения начинает стремится к бесконечности. До этого числа время исполнения практически идентично.
MK
ПФ
Спасибо 😊
VV
@asm0dey Паша, а что там по статусу с задачей по внедрению поддержки котлина в ядро спарка?
ПФ
Они не хотят 😊 Наверное есл появится коммьюнити, которое будет кричать что им надо — они могут передумать, но пока тчо они не видят смысла. Можно пойти и написать в SPIP комментарий, мы будем рады
https://issues.apache.org/jira/browse/SPARK-32530
https://issues.apache.org/jira/browse/SPARK-32530
AN
Я тут поопрашивал людей, которые со скала-спарк бэкграундом. Они суперконсервативны. Работает - не трожжжжь и все такое. Так что надо свое компьюнити строить и переманивать самых активных. Как мне кажется надо сейчас серьезно поработать над Kotlin DataFrame. Очень перспективная штука, но я туда на днях залез, мне сильно не понравилось чего там внутри творится.
ПФ
Конечно, у них всё есть, это хороший повод быть консервативным
AN
Ну как все. А интеграция с другими тулами? Та же визуализация на котлин уже сравнялась со скалой и имеет все шансы обогнать в ближайшем будущем
ПФ
Визуализация тебе обычно нужна какая угодно, ты же не в пайплайн её встраиваешь
AN
Так вопрос на стыке же. Ты вот сейчас мыслишь одним пайплайном. А на самом деле главная боль у тебя не в пайплайне, а что делать с данными на выходе из пайплайна. Люди на pyspark сидят ради этого.
AN
Надо мыслить не инструментом и экосистемой. Именно на этом питон выигрывает
ПФ
Я вчера строил графики на альтаире на датасете, сделанном в спарке. Норм!
AN
Из скалы?