🍀 NetMock: простой подход к тестированию HTTP-запросов в Java, Android и Kotlin Multiplatform

NetMock — это мощная и удобная библиотека, которая упрощает имитацию HTTP-запросов и ответов.

Улучшение стратегии тестирования HTTP-кода

• Подход предполагает изолирование HTTP-кода в отдельные компоненты, что позволяет проводить независимое тестирование остальной системы.
• Несмотря на то, что данный подход упрощает репозитории и тестовые классы, он часто пренебрегает тестированием самого HTTP-кода из-за сопутствующих сложностей.
• В результате возникает потребность проверять важнейшую логику, связанную с HTTP-запросами и парсингом JSON.

Данная проблема прослеживается в проектах, задействующих Retrofit.

Эта библиотека абстрагирует HTTP-логику посредством интерфейсов. Рассмотрим следующий фрагмент кода:
interface GitHubService {
@GET("users/{user}/repos")
suspend fun listRepos(@Path("user") user: String): List<RepoDto>
}

class GitHubRepositoryImpl(
private val githubService: GitHubService,
private val repoMapper: RepoMapper
): GitHubRepository {
override suspend fun listRepos(user: String): List<Repo> {
val repoDtos = githubService.listRepos(user)
return repoMapper.map(repoDtos)
}
}

Хотя этот подход упрощает репозитории и тестовые классы, он часто пренебрегает важными тестами для HTTP-логики. Кроме того, существует вероятность создания ненужных компонентов исключительно для упрощения модульного тестирования репозиториев.

Цель модульного тестирования — предотвращать и выявлять ошибки разработчиков, тем самым гарантируя правильную работу кода. Без надлежащих тестов даже простые ошибки, такие как изменение пути с users/{user}/repos на user/{user}/repos или переименование поля в RepoDto, могут остаться незамеченными, что неприемлемо в профессиональном проекте.

Я вовсе не критикую Retrofit. Наоборот, считаю ее отличной и удобочитаемой библиотекой.

Более того, признаю целесообразность изолирования HTTP-кода в отдельные компоненты ради улучшения структуры и удобства сопровождения.

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

Имитация запросов и ответов с помощью NetMock
@Test
fun `your test`() = runTest {
val user = "some_user"
netMock.addMock(
request = {
method = Method.Get
requestUrl = "https://api.github.com/users/$user/repos"
},
response = {
code = 200
body = readFromResources("responses/repo_list.json")
}
)

val result = sut.listRepos(user)

//...
}

Для имитации запросов и ответов применяется простой API, предоставляемый NetMock.

Добавляя mock-объект в очередь ожидаемых запросов и ответов, вы можете перехватывать и контролировать поведение HTTP-взаимодействий во время тестирования.

Создание экземпляра NetMock

Читать

@javatg

⏱ Все что вам нужно знать о таймаутах

Зачем устанавливать таймауты

Давайте для начала ответим на простой вопрос: "Зачем устанавливать таймауты?". Успешный ответ сервиса, даже если он занимает много времени, лучше, чем ошибка закрытия соединения по таймауту.
▪️Хм... не всегда, давайте разбираться.

Прежде всего если сервис не отвечает или отвечает слишком медленно, никто не будет ждать. Вместо того чтобы испытывать терпение ваших пользователей, следуйте принципу fail-fast. Позвольте вашим клиентам повторить запрос или обработать ошибку на их стороне. Когда возможно, возвращайте fallback значение.

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

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

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

Но для продакшен сервисов - это недопустимо. Это может быть даже опасным. Например, в нативном java HttClient connection/request таймауты отключены, я не думаю что это в рамках вашего SLA :)

📌 Продолжение

@javatg

🖥 Android Interview Questions

Очень полезная шпаргалка для собеседования по Android - Вопросы для собеседования по Android

▪Github

@javatg

🔋Основы реактивного программирования

Reactor
Reactor — это библиотека реактивного программирования для создания асинхронных и событийно-управляемых приложений на языке Java. Она предназначена для масштабируемой и эффективной обработки больших объемов потоков данных и событий. Я сам пользовался Reactor, и поэтому решил предложить вам эту простую и доступную для новичков библиотеку в демонстрационных целях.

Основное назначение Reactor — предоставление набора инструментов и абстракций для создания реактивных приложений. Reactor предлагает набор основных компонентов, таких как Flux и Mono, которые представляют собой потоки данных и событий. Эти компоненты могут быть объединены и преобразованы с помощью набора операторов, таких как map, filter и reduce, для создания сложных потоков данных.

Сравнение Mono и Flux
Как уже говорилось, реактивное программирование работает по модели “издатель-подписчик”. И Mono, и Flux предоставляют абстракцию для публикации событий.

Разница между ними заключается в том, что Mono может публиковать только одно событие за раз, а Flux — несколько событий за раз. Поэтому когда нужно публиковать только одно событие, выбирают Mono, а когда нужно публиковать несколько событий — Flux.

Теперь приведу небольшой пример, поясняющий каждую упоминаемую ранее концепцию.

Демо
Все начинается с того, что издатель выдает событие для потребителя.

Как и java-потоки, Flux и Mono придерживаются ленивого выполнения, т.е. значение выражения не обрабатывается до тех пор, пока в нем нет необходимости.

Начнем с создания простого Flux.
Flux<Integer> flux = Flux.just(1, 2, 3, 4, 5);

Метод “just” позволяет создать Flux, если есть доступное значение. Это самый простой способ создания Flux. Несмотря на то что я привожу пример с Flux, шаги остаются такими же и для Mono. В Mono также используется метод “just” с той разницей, что Mono применяется только для одного элемента. Поэтому если задать несколько значений, то получим ошибку.
Flux<String> mappedFlux = flux.map(i -> "Number: " + i)
The above flux gets converted to
"Number: 1", "Number: 2", "Number: 3", "Number: 4", "Number: 5"

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

1. Map: преобразует каждый элемент, выдаваемый потоком данных, применяя к нему функцию.
2. Filter: фильтрует элементы, выдаваемые потоком данных, на основе предикатной функции.
3. Reduce: агрегирует элементы, выдаваемые потоком данных, в одно значение с помощью функции-аккумулятора.
4. Merge: объединяет несколько потоков данных в один.
5. Concat: конкатенирует нескольких потоков данных в один в определенном порядке.
6. FlatMap: преобразует каждый элемент, выдаваемый потоком данных, в другой поток данных, а затем сводит полученные потоки в один.
7. Zip: объединяет элементы, выдаваемые несколькими потоками данных, в один элемент с помощью функции-комбинатора.

Применим еще несколько операторов для пояснения их работы.
Flux<String> filteredFlux = mappedFlux.filter(s -> !s.endsWith("2") && !s.endsWith("4"));

Flux преобразуется в:
"Number: 1", "Number: 3", "Number: 5"

Теперь сведем Flux к одной строке.
Mono<String> reducedMono = filteredFlux.reduce("", (a, b) -> a+ ", " + b);

Flux преобразуется в:
"Number: 1, Number: 3, Number: 5"

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

*️⃣Следует отметить, что я добавил преобразованный вывод для пояснения, а на самом деле никаких вычислений не происходит. Как уже говорилось, Flux следует модели ленивого исполнения. Пока мы не подпишемся на поток событий, никаких вычислений не происходит. А когда подписываемся, получаем возможность контролировать то, что нужно сделать с полученным событием.

Чтобы упростить задачу и показать, как работает подписчик, просто выведу Flux.

📌Читать

@javatg

🖥 Новости Java

Spring Modulith 1.0 GA Released. Новый -релиз получила Spring Modulith — часть экосистемы Spring, призванная упростить построение модульных монолитов.

Announcing Testcontainers Desktop Free Application — свежий анонс утилиты, удобной для работы с тест-контейнерами. Из интересного — быстрое переключение между docker/colima/podman, возможность запуска контейнеров на фиксированных портах и их фриз на время дебага.

Выпущен Jmix 2.0 — новая версия платформы для быстрой разработки бизнес-приложений на Java. В статье — подробности о том, для чего нужен этот инструмент и как он позволяет сокращать время разработки бизнес-приложения.

OpenAI выложила на Github OpenCopilot. OpenCopilot — это ИИ-помощник, способный интегрироваться в продукт. Он готов к встраиванию через базовые API и может вызывать эти API по необходимости. Модель OpenCopilot основана на обширной лингвистической базе и способна определить, требует ли запрос пользователя выполнения вызова к какой-либо конечной точке API.

Дмитрий Иванов, Андрей Кулешов — Пирамида потребностей Маслоу для Java/Kotlin-разработчика. Виде — это полноценная методичка, посвященная тому, как начать и развить свой open-source-проект. От стадии кодинга и до построения комьюнити — каждый шаг расписан детально, с приведением полезных инструментов и практик.

JDK 21 G1/Parallel/Serial GC changes — статья о том, как изменятся сборщики мусора в JDK 21, и о планах их развития. Основные изменения коснутся G1 GС:

@javatg

🖥Перестаём бояться генерировать байт-код

Многие, возможно, думают, что работа с байт-кодом Java (будь то чтение или, тем более, генерация) — это какая-то особенная магия, доступная только продвинутым разработчикам с особенно крутым опытом. На самом деле, я считаю такую точку зрения ошибочной.

JVM устроена гораздо проще, чем CPU; она оперирует такими высокоуровневыми понятиями как классы, интерфейсы, методы, а не просто лопатит байты в памяти. В отличие от CPU, который легко уронить криво сгенерированным машинным кодом, JVM заботливо отверифицирует любой байт-код и в общем не даст выстрелить в ногу.

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

Весь приведённый код доступен в репозитории.



Задача
Я вдохновился книгой Бьёрна Страуструпа, по которой лет 20 назад изучал C++. В одной из первых глав в качестве задачи для введения в язык предлагается написать калькулятор выражений. Я же предлагаю не вычислять выражения, а генерировать байт-код, который вычисляет выражения.

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

public interface Expression {
double evaluate(Function<String, Double> inputs);
}
Выражения в списке разделены точкой с запятой (;), метод evaluate возвращает результат вычисления последнего из выражений. Выражения определим так:

Число (например, 2, 42, 3.14) — это выражение.
Идентификатор (например, foo, pi, myVar_1) — это выражение. Значение по-умолчанию для переменной вычисляется с помощью вызова inputs.apply(id).
Если A и B — выражения, то A + B, A - B, A * B, A / B, -A, (A) — так же выражения
Если A — это идентификатор, и B — это выражение, то A = B — так же выражение
Генерируем класс
Для начала напишем генератор класса, реализующего интерфейс Expression.

▪Читать дальше
▪Github

@javatg

🖥 Infinity For Reddit

Крутой проект на Java. Клиент Reddit для Android. В нем нет рекламы, он отличается чистым пользовательским интерфейсом и плавным просмотром веб-страниц

Содержит такие функции, как Lazy Mode (автоматическая прокрутка сообщений), поддержка нескольких учетных записей и ночная тема.

▪Github
▪Docs

@javatg

🖥 PostgreSQL JDBC Driver

Драйвер PostgreSQL JDBC Driver (сокращенно PgJDBC) позволяет Java-программам подключаться к базе данных PostgreSQL, используя стандартный, независимый от базы данных Java-код. Это JDBC-драйвер с открытым исходным кодом, написанный на языке Pure Java (Type 4) и взаимодействующий в сетевом протоколе PostgreSQL.

▪Github
▪Docs

@javatg

🎮 Как уменьшить объем шаблонного кода в тестах Kotlin

Тестирование должно быть простым.

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

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

Сценарий использования
Допустим, у нас есть приложение, которое отправляет какие-либо данные принимающему API. Отправляем следующее:
data class Stuff(val name: String, val type: String)

Сервис перенаправляет запрос другому классу для фактической отправки. Код выглядит так:
import okhttp3.OkHttpClient

class StuffService() {
private val client = OkHttpClient()
.newBuilder()
.addInterceptor { chain ->
val request = chain.request().newBuilder()
.addHeader("Content-Type", "application/json")
.build()
chain.proceed(request)
}.build()

private val stuffLink = StuffLink(client, "http://some.where")

fun sendStuff(stuff: Stuff) = stuffLink.sendStuff(stuff)
}

Клиент (назовем его ссылкой, тем самым исключая множественные трактовки этого понятия) выполняет фактическую отправку, создавая запрос и отправляя его посредством заданного OkHttpClient и URL. Рассмотрим код:

import com.fasterxml.jackson.databind.ObjectMapper
import okhttp3.MediaType.Companion.toMediaType
import okhttp3.OkHttpClient
import okhttp3.Request
import okhttp3.RequestBody.Companion.toRequestBody
import okhttp3.Response

class StuffLink(private val client: OkHttpClient, private val url: String) {
private val objectMapper = ObjectMapper()

fun sendStuff(stuff: Stuff): Response {
val request = Request.Builder()
.url(url)
.post(
objectMapper.writeValueAsString(stuff)
.toRequestBody("application/json".toMediaType()),
).build()

return client.newCall(request).execute()
}
}

Вариант теста 1

🔎 Читать

@javatg

🖥 ​Что такое object в Kotlin

Известно, что в Kotlin объекты создаются с помощью конструкторов. Но это не единственный способ!

В этой статье вы узнаете о двух альтернативах: object expressions и object declarations.

📌Читать

#android

@javatg

🖥 HertzBeat

HertzBeat - это система мониторинга с открытым исходным кодом, работающая в режиме реального времени, с пользовательским мониторингом, высокопроизводительным кластером и возможностью работы без агентов.

▪Github

@javatg

🏛Событийно-ориентированная архитектура

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

Преимущества событийно-ориентированной архитектуры
▪️Слабая связанность: службы разделены, чем обеспечивается независимость и модульность.
▪️Масштабируемость: службы масштабируются независимо, исходя из потребности в событиях, чем повышается общая производительность системы.
▪️Асинхронная обработка: событиями обеспечиваются асинхронное взаимодействие, уменьшение задержки и времени отклика.
▪️Порождение событий: поддерживается естественным образом, ведь состояние системы определяется последовательностью прошлых событий.
▪️Гибкость: добавление новых служб или изменение имеющихся не сказывается на всей системе.

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

В основе Kafka — модель обмена сообщениями «публикация-подписка», где в темах отправителями публикуются сообщения-события, а получатели — для получения и обработки сообщений — подписываются на эти темы. События хранятся в Kafka неизменяемо и только с возможностью добавления. Данные обрабатываются как в реальном времени, так и ретроспективе.

Ключевые понятия Kafka
• Темы  — каналы для публикации событий и подписки на них.
• Отправители  — службы, которыми события создаются и отправляются в темы Kafka.
• Получатели  — службы, которые подписываются на темы, ими обрабатываются входящие события.
• Разделы: каждая тема разбивается на разделы, чем обеспечиваются параллельная обработка и распределение нагрузки.

Роль Kafka в событийно-ориентированной архитектуре

📌 Читать

@javatg