Поделитесь в комментариях: какие методики модульного тестирования используете вы?
Используем эти:
Высокоуровневые — проверка бизнес‑процесса системы и логики работы программы.
Как-то так вышло, эмпирически, что низкоуровневые тесты всё-таки гарантируют с меньшей степенью отсутствие багов. Высокоуровневые проверяют и то, что сценарий ОКъ, и низкоуровневые моменты.
Не отрицаю, что (1) нет, но пирамида тестирования перевёрнутая выходит в реальности: больше всего (3), есть (2), меньше всех (1).
До того, как я удалил ещё тогда Сбер, он жрал немыслимое кол-во места на телефоне (чуть менее 700 Мб). Подумать только, целый CD! Для меня это было достаточно зловредно :)))
У меня на проекте монорепо с 2019 года, однозначно, что есть свои плюсы. Есть и минусы, как-то: код пайплайнов становится никому непонятным, кроме автора.
П.С. У нас в монорепо в основном java, но есть и nodejs fe / be :)
Считается, что с зависимостями лучше работать через собственные абстракции. Если в какой-то момент придется заменить либу/внешний сервис A на B, то изменения будут только в адаптере, но не просочатся в остальной код.
И вот у меня дошли руки тоже это реализовать у себя :) Делюсь прогрессом.
Подход выбран близкий, но с отличиями в деталях. Поднимается контекст Spring, считаем sha256 от папки с миграциями liquibase, часть первых символов в hex это тег образа. Если образа нет, собираем: подняли стандартный контейнер postgresql, запустили миграции liquibase, стопнули контейнер, скопировали /var/lib/postgresql/data в отдельный .tar.gz, создаём на основе стандартного postgresql новый образ с нужным тегом, закидывая туда файлы в другую папку (/var/lib/postgresql-migrated/data) + обновлённый migrated-entrypoint.sh. Скрипт делает только перемещение в изначальную папку, и запуск оригинального docker-entrypoint.sh, это нужно для того, чтобы файлы в контейнере разместились на tmpfs.
При запуске одного произвольного теста время на поднятие контекста срезалось в два раза.
Как-то, уже наверное 15 лет назад, мы в НИИ купили себе стойку в комнату. Прям небольшой кабинет, 4 стола, 3-4 человека.
Сперва с одним сервером, постепенно выросли до 3. Для каждого сервера понемногу внизу стойки вставили по ИБП. Свитч. Напруга — был силовой щиток рядом, всё ОК. Чутт выше поставили полку, на неё МФУшка влезла :) Над стойкой кондёр на стену.
Цель — фундаментальные исследования, числомолотилка. В целом всё нормально было, кроме ещё одного фактора, который выше никто не отметил. Последний, третий supermicro, несмотря на толщину 2U, был ужасно шумный. Первый брали Интел, 4u, он был тих. Второй 1U, шумоват. А вот третий нас просто добил. В итоге включали вычисления на нём, только уходя домой.
Ну и оно до сих пор стоит и работает. Не представляю, сколько денег это бы сожрало при разных вариантах аренды.
Если держать в голове, что у нас его виртуальные треды, можно завести бесконечный тредпул, их плодить бесщадно на каждый запрос запрошенное N число, а в потоках блокироваться на семафоре. В зависимости от обсуждения с собеседующим можно семафор сделать или глобальный, если хочется честно лимитировать число запросов от нашего сервиса к целевому, или на внешний запрос, если "чуть более честно следовать букве ТЗ".
Если виртуальных тредов нет, можно поинтересоваться, не предполагается ли, что у нас всегда достаточно памяти под треды, и авось их тоже можно плодить.
В общем, мой коммент скорее про то, что перед реализацией можно ещё больше деталей уточнить, которые могут дать пространство для манёвра.
Мне кажется, я бы в такой ситуации сразу начал рисовать график запросов и доказывать, что лучше не батчи по 10, а семафором каким-нибудь ограничить, чтобы в моменте было не более 10. Сергей, не задавал такой вопрос? )
Терминал и Far это боль :)
Но если добавить фольги, кажется, должен получится хороший конденсатор )
Жаль, что ни слова про Новосибирск, вдруг тоже какие-нибудь интересные факты нашлись бы :)
Используем эти:
Как-то так вышло, эмпирически, что низкоуровневые тесты всё-таки гарантируют с меньшей степенью отсутствие багов. Высокоуровневые проверяют и то, что сценарий ОКъ, и низкоуровневые моменты.
Не отрицаю, что (1) нет, но пирамида тестирования перевёрнутая выходит в реальности: больше всего (3), есть (2), меньше всех (1).
До того, как я удалил ещё тогда Сбер, он жрал немыслимое кол-во места на телефоне (чуть менее 700 Мб). Подумать только, целый CD! Для меня это было достаточно зловредно :)))
А зачем таскать 300 Гб артефактами? Может надо что-то из них выпилить?
У меня на проекте монорепо с 2019 года, однозначно, что есть свои плюсы. Есть и минусы, как-то: код пайплайнов становится никому непонятным, кроме автора.
П.С. У нас в монорепо в основном java, но есть и nodejs fe / be :)
Прошу прощения, что комментарием (пишу с телефона), но Supplier, а не Suplier.
Ещё надо отметить переиспользование кусков SQL из разных файлов :)
Точно крутая технически штука, но почему она звучит как зло?)
Но, действительно, статья не отвечает на вопрос из заголовка...
Считается, что с зависимостями лучше работать через собственные абстракции. Если в какой-то момент придется заменить либу/внешний сервис A на B, то изменения будут только в адаптере, но не просочатся в остальной код.
Эта статья была написана как ответ на переписку в комментариях к моей статье: https://habr.com/ru/articles/742552/
И вот у меня дошли руки тоже это реализовать у себя :) Делюсь прогрессом.
Подход выбран близкий, но с отличиями в деталях. Поднимается контекст Spring, считаем sha256 от папки с миграциями liquibase, часть первых символов в hex это тег образа. Если образа нет, собираем: подняли стандартный контейнер postgresql, запустили миграции liquibase, стопнули контейнер, скопировали /var/lib/postgresql/data в отдельный .tar.gz, создаём на основе стандартного postgresql новый образ с нужным тегом, закидывая туда файлы в другую папку (/var/lib/postgresql-migrated/data) + обновлённый migrated-entrypoint.sh. Скрипт делает только перемещение в изначальную папку, и запуск оригинального docker-entrypoint.sh, это нужно для того, чтобы файлы в контейнере разместились на tmpfs.
При запуске одного произвольного теста время на поднятие контекста срезалось в два раза.
Ну, если бы не Майнкрафт, я бы не перешёл из плюсов в джаву :) Так что у меня к нему личная благодарность :)
Как-то, уже наверное 15 лет назад, мы в НИИ купили себе стойку в комнату. Прям небольшой кабинет, 4 стола, 3-4 человека.
Сперва с одним сервером, постепенно выросли до 3. Для каждого сервера понемногу внизу стойки вставили по ИБП. Свитч. Напруга — был силовой щиток рядом, всё ОК. Чутт выше поставили полку, на неё МФУшка влезла :) Над стойкой кондёр на стену.
Цель — фундаментальные исследования, числомолотилка. В целом всё нормально было, кроме ещё одного фактора, который выше никто не отметил. Последний, третий supermicro, несмотря на толщину 2U, был ужасно шумный. Первый брали Интел, 4u, он был тих. Второй 1U, шумоват. А вот третий нас просто добил. В итоге включали вычисления на нём, только уходя домой.
Ну и оно до сих пор стоит и работает. Не представляю, сколько денег это бы сожрало при разных вариантах аренды.
Если держать в голове, что у нас его виртуальные треды, можно завести бесконечный тредпул, их плодить бесщадно на каждый запрос запрошенное N число, а в потоках блокироваться на семафоре. В зависимости от обсуждения с собеседующим можно семафор сделать или глобальный, если хочется честно лимитировать число запросов от нашего сервиса к целевому, или на внешний запрос, если "чуть более честно следовать букве ТЗ".
Если виртуальных тредов нет, можно поинтересоваться, не предполагается ли, что у нас всегда достаточно памяти под треды, и авось их тоже можно плодить.
В общем, мой коммент скорее про то, что перед реализацией можно ещё больше деталей уточнить, которые могут дать пространство для манёвра.
Пора Павлу опять делать что-то новое, модное, молодежное?)
Есть вариант вложить материнский капитал сильно хуже, чем в квартиру -- в частный дом :)
Мне кажется, я бы в такой ситуации сразу начал рисовать график запросов и доказывать, что лучше не батчи по 10, а семафором каким-нибудь ограничить, чтобы в моменте было не более 10. Сергей, не задавал такой вопрос? )
Сперва прочитал как "есть во всех российских странах" =)