У Sentry слишком много компонентов, используйте нашу тулу где потребуется всего лишь Clickhouse, Postgres, Redis и Kafka (ну и возможно ещё pgbouncer, sentinel, zookeeper и stolon). Удивительно, почему для логов, метрик и трейсов достаточно одного otel-collector + Clickhouse с графаной. А тупо для агрегации ошибок которых в сотни раз меньше, что у вас, что у Sentry надо ещё один мониторинг поднимать, с большим количеством компонентов. Эти ошибки и так уже есть у меня в КХ, почему нельзя просто плагин для графаны написать который позволит их отображать красиво? Типа если всё будет просто и понятно тогда поддержку продать не получится или что?
Количество i9n тестов зависит не от эндпоинтов, а от комбинаторной сложности входных параметров и числа поведенческих сценариев тестируемой системы.
Вы правы в этом уточнении.
Вот их ускорение до 2 секунд...
Вы заставляете меня третий раз повторять, что это возможно, если захотеть. Но у меня такой потребности пока не было, скорость тестов не является для меня проблемой в данный момент.
Если у вас есть большой опыт с тестами, будет полезно если вы изложите это в виде статьи, потому что в комментариях мы уже по кругу ходить начинаем.
Прочитайте, пожалуйста, статью ещё раз. Там не только про то, чтобы заменить все тесты на интеграционные.
Во-первых, если вы правильно организуете код то, часть тестов, вроде тестов бизнес-логики, у вас останутся в виде юнит-тестов.
Во-вторых, как бы сказал James O Coplien, возможно, большая часть ваших тестов просто мусор, который ничего не тестирует, и вам стоит провести ревизию. Возможно, поэтому при таком количестве тестов, у вас всё равно возникают проблемы на продакшене и приходится срочно катить хотфиксы.
В третьих. Количество интеграционных тестов зависит от количества эндпоинтов. В среднем микросервисе их скорее десятки, а не сотни. Соответственно и интеграционных тестов у вас будет пропорционально. Так же я написал, что у вас есть множество способов оптимизировать выполнение интеграционных тестов. Закладывать 5 секунд на прогон одного теста - это слишком большое допущение. Вот у меня есть проект где около 70 интеграционных тестов и они прогоняются за 16 секунд. Если бы я захотел их улучшить, то в первую очередь я бы сократил их количество, а не скорость выполнения. Go, кстати, умеет кэшировать результаты выполнения тестов, и запускать только нужные, можете это тоже настроить в CI.
По итогу ваши расчётные 3 часа превращаются в минуты или десятки секунд.
Если вы хотите сказать, что у вас есть большой опыт с интеграционными тестами и вы знаете как прогнать сотню тестов за 4 секунды, ну напишите статью, с удовольствием почитаю.
В каких-то языках просто компиляция проекта занимает сильно больше чем 5 минут. И как-то люди живут с этим)
У вас есть множество способов ускорить интеграционные тесты. Вы можете не удалять контейнер с Постгресом каждый раз, а просто делать drop database. Вы можете запустить БД по числу ядер и прогонять тесты параллельно. Тут большой простор для оптимизаций, но я вообще не вижу в этом проблемы. Вроде у всех уже давно есть CI/CD, просто пушишь изменения и идёшь пить чай, сколько там эти тесты прогоняются 5 секунд или 5 минут вообще не важно.
У меня вся статья про то, что не нужно тестировать через поведение, нужно тестировать через проверку данных. А вы меня спрашиваете: как мне протестировать поведение?
Тогда единственное, что вам нужно протестировать это то, как ваша функция обрабатывает данные. Нет никакой разницы работают ваши функции в горутине или нет. Одна она запущена или 10к (кроме того, что 10к это неэффективно). Используя каналы для получения данных и отправки результатов, вы можете запустить эти функции параллельно. Для Го это очень простой кейс, никакой проблемы вызванной асинхронностью тут быть не может.
for data := range inputCh {
go func(d Data) {
resultCh <- myFunc(d)
}(data)
}
Действительно нетривиальный код в действительно параллельной среде — можно протестировать только моками, исходя из моего опыта.
Если вам нужно протестировать как 10к функций работают параллельно и шарят состояние между собой, то это какой-то исключительный случай. Возможно, в этом случае вам действительно стоит использовать моки, я не отрицаю. Но 99% остальных тестов не такие! Если вы приведёте мне наглядный пример где моки упрощают тестирование, то я добавлю его в статью.
У вас столько статей про функциональное программирование, кажется вы должны понимать красоту чистых функций и преимущества классического тестирования.
Интерфейсы плохо, потому что они мешают нам ломать обратную совместимость.
Нет смысла сохранять обратную совместимость между сервисом и репозиторием одного компонента в одном микросервисе. В нашем примере они просто мешают рефакторингу.
Мне всегда нужно протестировать именно поведение. Интеграционные тесты, которые вы восхваляете, тестируют именно поведение.
Не совсем понимаю как вы тестируете поведение в интеграционных тестах. Вы отправляете какие-то данные на эндпоинт и проверяете, что вам вернулось именно те данные которые вы ожидаете. Это тестирование состояния.
Ога, зато пока соседняя команда не допилит свой эндпоинт, я никаких тестов прогнать не смогу. Удобно!
Как часто такое случается на практике? Мне кажется это достаточно редкий кейс. Но даже в таком случае вы сможете прогнать самые главные тесты, тесты вашей бизнес-логики. Либо использовать WireMock или что-то подобное для эмулирования API которого ещё не существует, если хотите написать интеграционные тесты заранее.
В общем, вы в 2025 году считаете асинхронные операции «некоторыми случаями»
Имеется ввиду работа с очередями (кафка, рэббит). В приведённом докладе более подробно рассказан этот кейс.
У Sentry слишком много компонентов, используйте нашу тулу где потребуется всего лишь Clickhouse, Postgres, Redis и Kafka (ну и возможно ещё pgbouncer, sentinel, zookeeper и stolon).
Удивительно, почему для логов, метрик и трейсов достаточно одного otel-collector + Clickhouse с графаной. А тупо для агрегации ошибок которых в сотни раз меньше, что у вас, что у Sentry надо ещё один мониторинг поднимать, с большим количеством компонентов.
Эти ошибки и так уже есть у меня в КХ, почему нельзя просто плагин для графаны написать который позволит их отображать красиво? Типа если всё будет просто и понятно тогда поддержку продать не получится или что?
Прямо сейчас читаю эту книгу. Удивительно, но сама книга читается гораздо проще чем все краткие выжимки по ней. При том, что она на английском.
Вы правы в этом уточнении.
Вы заставляете меня третий раз повторять, что это возможно, если захотеть. Но у меня такой потребности пока не было, скорость тестов не является для меня проблемой в данный момент.
Если у вас есть большой опыт с тестами, будет полезно если вы изложите это в виде статьи, потому что в комментариях мы уже по кругу ходить начинаем.
Прочитайте, пожалуйста, статью ещё раз. Там не только про то, чтобы заменить все тесты на интеграционные.
Во-первых, если вы правильно организуете код то, часть тестов, вроде тестов бизнес-логики, у вас останутся в виде юнит-тестов.
Во-вторых, как бы сказал James O Coplien, возможно, большая часть ваших тестов просто мусор, который ничего не тестирует, и вам стоит провести ревизию. Возможно, поэтому при таком количестве тестов, у вас всё равно возникают проблемы на продакшене и приходится срочно катить хотфиксы.
В третьих. Количество интеграционных тестов зависит от количества эндпоинтов. В среднем микросервисе их скорее десятки, а не сотни. Соответственно и интеграционных тестов у вас будет пропорционально.
Так же я написал, что у вас есть множество способов оптимизировать выполнение интеграционных тестов. Закладывать 5 секунд на прогон одного теста - это слишком большое допущение. Вот у меня есть проект где около 70 интеграционных тестов и они прогоняются за 16 секунд. Если бы я захотел их улучшить, то в первую очередь я бы сократил их количество, а не скорость выполнения.
Go, кстати, умеет кэшировать результаты выполнения тестов, и запускать только нужные, можете это тоже настроить в CI.
По итогу ваши расчётные 3 часа превращаются в минуты или десятки секунд.
Я не понимаю, вы таким сложным образом просто хотели посоветовать https://github.com/godepo/pgrx ?
Хм, ну ок, спасибо!)
Если вы хотите сказать, что у вас есть большой опыт с интеграционными тестами и вы знаете как прогнать сотню тестов за 4 секунды, ну напишите статью, с удовольствием почитаю.
В каких-то языках просто компиляция проекта занимает сильно больше чем 5 минут. И как-то люди живут с этим)
У вас есть множество способов ускорить интеграционные тесты. Вы можете не удалять контейнер с Постгресом каждый раз, а просто делать drop database. Вы можете запустить БД по числу ядер и прогонять тесты параллельно. Тут большой простор для оптимизаций, но я вообще не вижу в этом проблемы. Вроде у всех уже давно есть CI/CD, просто пушишь изменения и идёшь пить чай, сколько там эти тесты прогоняются 5 секунд или 5 минут вообще не важно.
Так зачем вам моки тогда? Пишите сразу чистые функции.
Ну ок, пусть работают 300 секунд, но найдут ошибку, чем отработают за секунду, ничего не найдут, а баг обнаружится после деплоя.
У меня вся статья про то, что не нужно тестировать через поведение, нужно тестировать через проверку данных. А вы меня спрашиваете: как мне протестировать поведение?
Тогда единственное, что вам нужно протестировать это то, как ваша функция обрабатывает данные.
Нет никакой разницы работают ваши функции в горутине или нет. Одна она запущена или 10к (кроме того, что 10к это неэффективно). Используя каналы для получения данных и отправки результатов, вы можете запустить эти функции параллельно. Для Го это очень простой кейс, никакой проблемы вызванной асинхронностью тут быть не может.
Я просто вставил ваш комментарий в ChatGPT и он сгенерил рабочий тест.
https://gist.github.com/AlexAkulov/12644f01ef36d5faade8b3cedd86fbe8
Всё как вы хотели, но на моём М1 отрабатывает за 3 секунды.
Я упомянул в статье https://testcontainers.com -- отличная штука, если не знаете с чего начать.
Если вам нужно протестировать как 10к функций работают параллельно и шарят состояние между собой, то это какой-то исключительный случай. Возможно, в этом случае вам действительно стоит использовать моки, я не отрицаю. Но 99% остальных тестов не такие!
Если вы приведёте мне наглядный пример где моки упрощают тестирование, то я добавлю его в статью.
У вас столько статей про функциональное программирование, кажется вы должны понимать красоту чистых функций и преимущества классического тестирования.
Нет смысла сохранять обратную совместимость между сервисом и репозиторием одного компонента в одном микросервисе. В нашем примере они просто мешают рефакторингу.
Не совсем понимаю как вы тестируете поведение в интеграционных тестах. Вы отправляете какие-то данные на эндпоинт и проверяете, что вам вернулось именно те данные которые вы ожидаете. Это тестирование состояния.
Как часто такое случается на практике? Мне кажется это достаточно редкий кейс. Но даже в таком случае вы сможете прогнать самые главные тесты, тесты вашей бизнес-логики. Либо использовать WireMock или что-то подобное для эмулирования API которого ещё не существует, если хотите написать интеграционные тесты заранее.
Имеется ввиду работа с очередями (кафка, рэббит). В приведённом докладе более подробно рассказан этот кейс.