Software Developer
В этой статье вы найдете немного личных наблюдений и советов о том, как сохранить проект живым и здоровым с течением лет. Без иллюзий всезнания. С лёгким, здоровым цинизмом.
Мой личный опыт связан с разработкой сервисов в рамках продуктовой разработки. В данной статье я говорю именно о такой разработке, а не о создании библиотек, фреймворков, баз данных и других замечательных вещей. Также я не касаюсь проектной разработки, где код пишется на заказ и передаётся в поддержку другим.
Разработчики любят чистый код, а "Правило бойскаута", по слухам, делает его еще чище. На первый взгляд, подход кажется разумным: исправляешь мелкие недочёты, переименовываешь переменные, удаляешь лишние комментарии — удобно, быстро, безопасно. А главное, можно сказать, что внёс вклад!
Однако если такие правки не решают реальных проблем, это превращается в поверхностный рефакторинг, создающий лишь иллюзию прогресса. Это можно описать метафорой low-hanging fruit — когда разработчики выбирают самые лёгкие и очевидные задачи, избегая более сложных и значимых изменений.
Данная статья предлагает подход к написанию интеграционных тестов для приложений с Kafka, позволяющий сосредоточиться на спецификации взаимодействия, делая тесты более читаемыми и легкими для поддержки. Представленный подход не только повышает эффективность тестирования, но и способствует лучшему пониманию интеграционных процессов в приложении.
Тема ведения заметок остается актуальной и по сей день. Мы знаем, какую пользу это приносит автору. Знакомы с различными подходами к ведению заметок. Известны инструменты, которые можно использовать, и у нас есть выбор. Представьте, что вы нашли свой подход, инструмент, и база заметок растет и радует глаз. А что дальше? Об одном из путей развития этой темы я хочу рассказать.
Эта статья посвящена концепции цифрового сада — философии публичного ведения личных заметок.
Когда-то в детстве я лежал на кровати и долго разглядывал узоры на старом советском ковре, видя в них животных и фантастические фигуры. Теперь я чаще смотрю на код, но в моем сознании по-прежнему рождаются похожие образы. Как и на ковре, эти образы складываются в повторяющиеся паттерны. Они могут быть как приятными, так и отталкивающими. Сегодня я хочу рассказать вам о таком неприятном паттерне, который встречается в программировании.
Использование Testcontainers кардинально улучшило процесс работы с тестовыми сценариями. Благодаря этому инструменту, создание окружений для интеграционных тестов стало проще (см. статью Изоляция в тестах с Кафкой). Хотя нагрузочное тестирование встречается реже, чем функциональное, оно может быть гораздо более увлекательным. Изучение графиков и анализ работы конкретного сервиса может доставить настоящее удовольствие. Такие задачи редки, но для меня они особенно захватывающие.
Цель данной статьи — продемонстрировать подход к созданию стенда для нагрузочного тестирования в том виде, в котором пишутся обычные интеграционные тесты: в форме spock-тестов с использованием Testcontainers в среде Gradle проекта. В качестве утилит нагрузочного тестирования используются Gatling, WRK и Yandex.Tank.
Данная статья предлагает практические рекомендации по написанию интеграционных тестов, демонстрируя, как сосредоточиться на спецификациях взаимодействия с внешними сервисами, делая тесты более читаемыми и легкими для поддержки. Представленный подход не только повышает эффективность тестирования, но и способствует лучшему пониманию интеграционных процессов в приложении. Через призму конкретных примеров будут исследованы различные стратегии и инструменты - DSL-обертки, JsonAssert и Pact, предлагая читателю комплексное руководство по улучшению качества и наглядности интеграционных тестов.
Статья представляет примеры интеграционных тестов, выполненных с использованием Spock Framework на языке Groovy для тестирования HTTP-взаимодействий в Spring-приложениях. В то же время, основные методики и подходы, предложенные в ней, могут быть эффективно применены к различным типам взаимодействий за пределами HTTP.
Предлагается рассматривать отклонения от стандартов и спецификаций таким же образом, как великий Дарвин рассматривал мутации — придавать им ключевую роль в эволюции, рассматривать как источник генетического разнообразия, на котором основан естественный отбор.
Таким же образом и «мутации» в коде (отклонения от стандартов и спецификаций) служат движущей силой инноваций, адаптации и диверсификации в программном обеспечении.
Написание и поддержка интеграционных тестов с Kafka являются вызовом. В этой статье описывается подход, который упрощает процесс тестирования, обеспечивая изоляцию тестов и удобные инструменты для достижения этой цели.
Благодаря изоляции тесты с Kafka можно организовать так, чтобы на этапе проверки результатов был доступ ко всем сообщениям, созданным в ходе теста, без необходимости использования методов ожидания, таких как Thread.sleep(), или инструментов вроде Awaitility.
Метод подходит для использования с Testcontainers, Embedded Kafka, а также при запуске Kafka локально или иными способами.
В данной статье я хочу поделиться своим опытом создания нативного образа для EmbeddedKafka с использованием GraalVM. Использование такого образа в интеграционных тестах позволяет увеличить скорость запуска тестовых сценариев и сократить объем потребляемой памяти. Интересно отметить, что в сравнении с использованием confluentinc/cp-kafka в Testcontainers, разница в скорости и потреблении памяти оказывается заметной — и не в пользу последнего.
В данной статье я бы хотел описать подход к написанию тестов с четким разделением на отдельные этапы, каждый из которых выполняет свою специфическую роль. Это способствует написанию тестов, которые легче читать, понимать и поддерживать.
Речь пойдет об использовании методологии Arrange-Act-Assert применительно к интеграционным тестам на Spring Framework с использованием мокирования (mock) HTTP-запросов к внешним ресурсам, к которым идет обращение по ходу выполнения тестируемого кода в рамках поведения системы. Предлагаемые к рассмотрению тесты написаны с использованием Spock Framework на языке Groovy (см. недавнюю статью по этой теме: Тестируем Spring Boot приложения через Spock Framework). В качестве механизма мокирования будет использоваться MockRestServiceServer. Будет пару слов и о WireMock.
В данной статье я расскажу вам о том, каким образом можно построить граф маршрутов для приложений с Apache Camel, отслеживать состояния этих маршрутов и собирать для них метрики.
Мы используем Apache Camel в spring приложениях и в Apache ServiceMix. И если маршруты в отдельном сервисе — это штука понятная и легко обозримая, то в рамках шины данных, где таких маршрутов много, не все так просто.
В данной статье я бы хотел поделиться с Вами идеей использования cucumber в качестве движка бизнес-правил и подходом к проверке таких правил.
В примерах я буду ссылаться на приложение, которое решает задачу распределения клиентов по группам в зависимости от различных параметров. Требования к приложению такие:
Клиенту могут быть присущи такие параметры: страна, идентификатор, язык и т.д.
Cucumber is a tool that supports Behaviour-Driven Development (BDD) — a software development process that aims to enhance software quality and reduce maintenance costs.
Gherkin is a Business Readable, Domain Specific Language that lets you describe software's behaviour without detailing how that behaviour is implemented.