Модульное и интеграционное тестирование - неотъемлемая часть вашей повседневной жизни как разработчика. Однако для новичков Spring Boot написание содержательных тестов для своих приложений оказывается проблемой:

- С чего начать мои усилия по тестированию?

- Как Spring Boot может помочь мне в написании эффективных тестов?

- Какие библиотеки мне использовать?

В этом блоге вы получите обзор того, как модульное и интеграционное тестирование работает со Spring Boot. Кроме того, вы узнаете, на каких функциях и библиотеках Spring следует сосредоточиться в первую очередь. 

Улучшения языка Java, которые вам следует знать

Последнее обновление 30.03.2021, чтобы включать изменения до JDK 16.

Когда в Java 8 были представлены Streams и Lambdas, это было большим изменением, позволившим использовать функциональный стиль программирования с гораздо меньшим количеством шаблонного кода.

С тех пор Java перешла на более быструю периодичность выпусков, благодаря чему новая версия Java будет появляться каждые шесть месяцев. Эти версии постоянно добавляют в язык новые функции.

Независимо от того, новичок вы или профессионал, всегда полезно освежить в памяти методы обработки исключений, чтобы убедиться, что вы и ваша команда можете справиться с проблемами.

Обработка исключений в Java - непростая тема. Новичкам сложно понять, и даже опытные разработчики могут часами обсуждать, как и какие исключения следует создавать или обрабатывать.

Вот почему у большинства команд разработчиков есть собственный набор правил их использования. И если вы новичок в команде, вас может удивить, насколько эти правила могут отличаться от тех, которые вы использовали раньше.

Тем не менее, есть несколько передовых практик, которые используются большинством команд. Вот 9 самых важных из них, которые помогут вам начать работу или улучшить обработку исключений.

В этой статье будут рассмотрены и сравнены различные методы контейнеризации ваших Java-приложений. Эти инструменты позволят вам получить контейнерное приложение с минимальными настройками. Возможно, вам даже не потребуется устанавливать Docker или работать с Dockerfile. К концу этой статьи вы сможете решить, какой построитель образов контейнера является самым быстрым, потребляет наименьшее количество ресурсов, проще в настройке и лучше всего подходит для вашего сценария использования.

Последнее обновление: 05 апреля 2021 г.

Вы можете использовать это руководство, чтобы получить практическую информацию о том, как найти и установить последнюю версию Java, понять различия между дистрибутивами Java (AdoptOpenJdk, OpenJDK, OracleJDK и т. д.), А также получить обзор функций языка Java, включая версии Java версии. 8-16.

Инкапсуляция и отделение внутренних компонентов от public, вероятно, является одним из наиболее недооцененных методов программирования, когда речь идет о обеспечении длительной поддержки приложения.

К счастью, в Java есть нечасто используемый модификатор видимости package-private, который очень помогает скрыть нежелательные детали реализации. К сожалению, если количество внутренних классов велико, оно плохо масштабируется, но, к счастью, нам может помочь ArchUnit.

Когда вы поддерживаете большой Java-проект в течение более длительного периода, моменты, когда вы, наконец, можете удалить неиспользуемый код, могут быть очень приятными. Больше не нужно поддерживать, переносить версии библиотеки или поддерживать темные углы для кода, который больше не используется. Но выяснение того, какие части базы кода можно удалить, может быть проблемой, и инструменты в этой области, похоже, отстают от последних практик разработки на Java. В этом посте мы опишем подход к поиску кода без ссылок с помощью ArchUnit, который позволяет итеративно обнаруживать и удалять неиспользуемый код из ваших проектов Java.

Это глубокое погружение в управление памятью Java позволит расширить ваши знания о том, как работает куча, ссылочные типы и сборка мусора.

Большинство списков вопросов интервью по Spring Boot заставляют вас запоминать случайные детали из документации Spring Boot. Но запоминание — плохая замена истинному пониманию и уверенности в знании Spring Boot.

Поэтому сегодня мы собираемся применить другой подход. Вместо того, чтобы перечислять 50 вопросов по мелочам Spring Boot, мы сосредоточимся на 11, которые заставят вас задуматься и, таким образом, многому научиться на этом пути.
Вот они, в произвольном порядке.

Примечание: если вы сами проводите интервью по Spring Boot, возможно, вы захотите задать эти вопросы в открытом формате, ведущем к обсуждениям вместо того, чтобы ожидать ответов из учебников.

В этом посте я покажу, как мы можем использовать шаблон Circuit Breaker в приложении Spring Boot. Когда я говорю «шаблон Circuit Breaker» имеется в виду архитектурный шаблон автоматического выключателя. Netflix опубликовал библиотеку Hysterix для работы с автоматическими выключателями. В рамках этого поста я покажу, как мы можем использовать шаблон автоматического выключателя, используя библиотеку resilence4j в приложении Spring Boot.

Одна из основных функций Spring - функция публикации событий. Мы можем использовать события для разделения частей нашего приложения и реализации шаблона публикации-подписки. Одна часть нашего приложения может публиковать событие, на которое реагируют несколько слушателей (даже асинхронно). В рамках Spring Framework 5.3.3 (Spring Boot 2.4.2) теперь мы можем записывать и проверять все опубликованные события ( ApplicationEvent) при тестировании приложений Spring Boot с использованием @RecrodApplicationEvents.

В этой статье мы рассмотрим, как использовать Spring Boot 2.x и Redis для выполнения асинхронных задач, а полный код продемонстрирует шаги, описанные в этом посте.

Мониторинг очень важен для современных приложений, современные приложения по своей природе сильно распределены и имеют разные зависимости, такие как база данных, службы, кеширование и многое другое. Поэтому все более важны отслеживание и мониторинг этих служб, чтобы приложение придерживалось условий SLA ( Service Level Agreement). SLA — это соглашение между клиентом и поставщиком услуг, в нем учитываются надежность, скорость отклика и другие показатели уровня обслуживания.

Мы всегда стараемся не нарушать никаких SLA, нарушение любой части SLA может иметь множество последствий. Если услуга не соответствует условиям, определенным в SLA, она можкт нанести ущерб репутации бренда и привести к потери дохода. Хуже всего то, что компания может потерять клиента в пользу конкурента из-за своей неспособности удовлетворить требования клиента к уровню обслуживания.

Штрих-коды повсеместно используются в торговле и розничной торговле для помощи в отслеживании, покупках и  инвентаризации. Они позволяют организациям вести точный учет их поставок, товаров и других предметов, которые являются ключевыми для их деятельности. Для международного и  национального использования существуют разные штрих-коды, которые используются  в определенных контекстах. Например, штрих-коды UPC и EAN выглядят одинаково по своему форматированию  и могут использоваться аналогичным образом, но UPC - это в  основном  североамериканская система кодирования;  однако, как UPC и  EAN  будут  использоваться во всем мире.  QR - коды также используется во всем мире , но  является  обычно используется для обмена  сложными наборами информации,  например, сведениями о товарах  или  ссылками на веб-сайты.  

Следующие  пять  API-интерфейсов  позволят вам создавать изображения штрих-кода в трех ранее упомянутых форматах. Это позволит вам распечатать или создать упаковку с прикрепленными вашими личными штрих-кодами, без необходимости  извлекать ее из внешнего источника. Это может быть особенно полезно для малого бизнеса, поскольку обеспечивает большую независимость  как компании и улучшает  визуальную и профессиональную привлекательность ваших продуктов . 

Когда мы создаем программное обеспечение, мы хотим создавать «-способности»: понятность, ремонтопригодность, расширяемость и - в тренде сейчас - декомпозицию (чтобы мы могли разложить монолит на микросервисы, если возникнет необходимость). Добавьте в этот список свою любимую «способность».

Большинство - возможно, даже все - из этих «возможностей» идут рука об руку с чистыми зависимостями между компонентами.

Если компонент зависит от всех других компонентов, мы не знаем, какие побочные эффекты будет иметь изменение одного компонента, что затрудняет поддержку кодовой базы и еще более затрудняет ее расширение и разложение.

Со временем границы компонентов в кодовой базе имеют тенденцию ухудшаться. Плохие зависимости закрадываются и усложняют работу с кодом. Это имеет всевозможные плохие последствия. В частности, разработка замедляется.

Это тем более важно, если мы работаем над монолитной кодовой базой, охватывающей множество различных областей бизнеса или «ограниченных контекстов», если использовать жаргон Domain-Driven Design.

Как мы можем защитить нашу кодовую базу от нежелательных зависимостей? С тщательным проектированием ограниченных контекстов и постоянным соблюдением границ компонентов. В этой статье показан набор практик, которые помогают в обоих случаях при работе со Spring Boot.

При создании программного обеспечения команды разработчиков обычно определяют набор руководящих принципов и соглашений по разработке кода, которые считаются лучшими практиками.

Это методы, которые обычно документируются и доводятся до сведения всей команды разработчиков, которая их приняла. Однако во время разработки разработчики могут нарушить эти рекомендации, которые обнаруживаются во время ревью кода или с помощью инструментов проверки качества кода.

Поэтому важным аспектом является автоматизация этих директив в максимально возможной степени по всей архитектуре проекта, позволяющая оптимизировать проверки.

Мы можем реализовать эти рекомендации как проверяемые JUnit тесты с помощью ArchUnit. Это гарантирует, что сборка версии программного обеспечения будет прекращена в случае нарушения архитектуры.

При создании программного обеспечения все мы, как команда, соглашаемся следовать набору рекомендаций, которые обычно считаются лучшими практиками. Но во время разработки разработчики могут нарушить эти правила по незнанию или нежеланию. Обычно мы полагаемся на ревью кода или инструменты проверки качества кода, такие как SonarQube , PMD и т.д. для проверки таких нарушений. Но некоторые из рекомендаций могут быть решениями, которые нельзя автоматизировать с помощью SonarQube, PMD и т.д.

Например, обычно я хочу следовать приведенным ниже рекомендациям для моих приложений на основе Java:

1. Следуйте трехуровневой структуре (уровни веб, сервис, репозиторий), где любой уровень может взаимодействовать только с непосредственным нижним уровнем, а нижний уровень не должен взаимодействовать с верхним уровнем. т.е. веб-уровень может взаимодействовать с уровнем сервиса, уровень сервиса может взаимодействовать с уровнем репозитория. Но уровень репозитория не может взаимодействовать с сервисным или веб-уровнем, сервисный уровень не может взаимодействовать с веб-уровнем.

2. Если приложение большое, мы могли бы захотеть следовать структуре Package-By-Feature, где только компоненты Web и Service являются public, а остальные компоненты должны быть package-private.

3. При использовании внедрения зависимостей Spring не используйте внедрение на основе поля и предпочитайте внедрение на основе конструктора.

Таким образом, может быть много правил, которым мы хотим следовать. Хорошая новость заключается в том, что мы можем проконтролировать выполнение этих рекомендаций с помощью JUnit тестов с использованием ArchUnit.

Spring Mock-MVC может быть отличным способом протестировать Spring Boot REST API. Mock-MVC позволяет нам тестировать обработку запросов Spring-MVC без запуска реального сервера.

Я использовал тесты Mock-MVC в различных проектах, и по моему опыту они часто бывают довольно многословными. Это не должно быть плохо. Однако это часто приводит к копированию / вставке фрагментов кода в тестовые классы. В этом посте мы рассмотрим несколько способов очистки тестов Spring Mock-MVC.

Каждый раз, когда я начинаю реализацию нового REST API с помощью Spring, мне сложно решить, как выполнять валидацию запросов и обрабатывать бизнес-исключения. В отличие от других типичных проблем API, Spring и его сообщество, похоже, не согласны с лучшими методами решения этих проблем, и трудно найти полезные статьи по этому поводу.

В этой статье я обобщаю свой опыт и даю несколько советов по валидации интерфейсов.

Контейнеры стали предпочтительным средством упаковки приложения со всеми зависимостями программного обеспечения и операционной системы, а затем доставки их в различные среды.

В этой статье рассматриваются различные способы контейнеризации приложения Spring Boot:

- создание образа Docker с помощью файла Docker,

- создание образа OCI из исходного кода с помощью Cloud-Native Buildpack,

- оптимизация изображения во время выполнения путем разделения частей JAR на разные уровни с помощью многоуровневых инструментов.