Unit-тестирование в Java: создание надежного кода с JUnit и Mockito

Для кого эта статья:

• Java-разработчики, стремящиеся улучшить качество своего кода
• Специалисты по тестированию ПО, изучающие unit-тестирование и фреймворки для Java

• Менеджеры и руководители проектов, заинтересованные в повышении надежности и сокращении рисков при разработке программного обеспечения

  Представьте, что вы создаете крупную Java-систему, всё работает, вы гордитесь своим кодом... а потом один маленький коммит обрушивает всю функциональность. Знакомо? Unit-тестирование — это не просто дополнительный слой кода, а практически обязательный инструмент для Java-разработчиков, которые хотят спать спокойно после деплоя. В этом руководстве я расскажу, как грамотно писать тесты, которые действительно находят ошибки, а не просто увеличивают процент покрытия. Вы получите работающие примеры, сравнение популярных фреймворков и конкретные техники, которые можно сразу применить в своих проектах. 🧪

Хотите стать востребованным специалистом с навыками тестирования? Курс тестировщика ПО от Skypro поможет вам освоить не только ручное, но и автоматизированное тестирование с использованием Java. Вы научитесь писать эффективные unit-тесты, работать с фреймворками JUnit и Mockito, и сможете автоматизировать рутинные процессы проверки кода. Уже через 9 месяцев вы станете специалистом, способным обеспечить качество любого программного продукта.

Что такое unit-тестирование в Java и почему оно необходимо

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

Звучит просто, но внедрение качественного тестирования радикально меняет процесс разработки и обслуживания приложений. Разберем, почему unit-тесты — не роскошь, а необходимость для Java-проектов.

Unit-тестирование в Java отличается от других типов тестирования своей фокусировкой на изоляции тестируемого кода. Хороший unit-тест проверяет конкретный функциональный аспект, выполняется быстро (миллисекунды) и не имеет внешних зависимостей вроде базы данных или файловой системы.

Александр Петров, Lead Java Developer

Мой путь к пониманию важности unit-тестирования был болезненным. В 2019 году мы работали над финтех-приложением с высокими требованиями к надежности. Руководство постоянно давило: "Быстрее, нам нужны новые функции". Мы жертвовали тестированием ради скорости.

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

После этого случая мы внедрили правило: ни один PR не принимается без адекватного покрытия тестами. Да, разработка стала занимать на 20-30% больше времени, но количество инцидентов снизилось на 80%. Более того, обнаружилось, что писать тесты до имплементации функциональности часто быстрее, чем потом отлавливать непонятные баги в продакшене.

В Java-экосистеме существуют отработанные подходы к написанию unit-тестов, основанные на принципах FIRST:

• Fast (Быстрые) — тесты должны выполняться быстро, чтобы разработчики могли запускать их часто
• Isolated (Изолированные) — каждый тест должен быть независимым от других
• Repeatable (Повторяемые) — тесты должны давать одинаковые результаты при многократных запусках
• Self-validating (Самопроверяющиеся) — тест должен однозначно определять, успешен он или нет
• Timely (Своевременные) — тесты лучше писать до или одновременно с кодом, а не после

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

Основные фреймворки для unit-тестирования в Java

Java-экосистема предлагает богатый выбор инструментов для unit-тестирования, каждый со своими особенностями и областью применения. Рассмотрим основные фреймворки, которые формируют фундамент современной практики тестирования в Java-проектах.

JUnit — стандарт де-факто

JUnit остается самым распространенным фреймворком для unit-тестирования в Java. С момента выхода версии 5 (JUnit Jupiter) он предлагает значительно улучшенный API и расширенные возможности.

Базовый пример теста с JUnit 5:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.DisplayName;
import static org.junit.jupiter.api.Assertions.*;

public class CalculatorTest {

@Test
@DisplayName("1 + 1 = 2")
void additionTest() {
Calculator calculator = new Calculator();
assertEquals(2, calculator.add(1, 1), "Сложение целых чисел");
}

@Test
@DisplayName("Проверка деления на ноль")
void divisionByZeroTest() {
Calculator calculator = new Calculator();
assertThrows(ArithmeticException.class, () -> calculator.divide(1, 0));
}
}

Ключевые возможности JUnit 5:

• Параметризованные тесты с разными источниками данных
• Динамическое создание тестов
• Улучшенная интеграция с лямбда-выражениями
• Расширенная поддержка условного выполнения тестов
• Вложенные тестовые классы для лучшей организации

TestNG — мощная альтернатива

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

import org.testng.annotations.*;
import static org.testng.Assert.*;

public class AuthServiceTest {

private AuthService service;

@BeforeClass
public void setup() {
service = new AuthService();
}

@Test(groups = {"authentication", "critical"})
public void testSuccessfulLogin() {
boolean result = service.login("user", "validPassword");
assertTrue(result);
}

@Test(groups = {"authentication"}, dependsOnMethods = {"testSuccessfulLogin"})
public void testInvalidCredentials() {
boolean result = service.login("user", "wrongPassword");
assertFalse(result);
}
}

Преимущества TestNG:

• Поддержка зависимостей между тестами
• Гибкое группирование тестов
• Расширенная поддержка многопоточного выполнения
• Встроенные возможности для параметризации
• Мощная система отчетов и интеграций

Mockito — изоляция зависимостей

Mockito — это фреймворк для создания заглушек (mocks, stubs) при тестировании. Он позволяет имитировать поведение внешних зависимостей, чтобы тестировать единицы кода в изоляции.

import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

public class OrderServiceTest {

@Test
void placeOrderTest() {
// Создание моков
PaymentGateway paymentMock = mock(PaymentGateway.class);
NotificationService notificationMock = mock(NotificationService.class);

// Настройка поведения мока
when(paymentMock.processPayment(anyDouble())).thenReturn(true);

// Создание тестируемого объекта с моками
OrderService orderService = new OrderService(paymentMock, notificationMock);

// Вызов тестируемого метода
boolean result = orderService.placeOrder(new Order("123", 100.0));

// Проверка результата
assertTrue(result);

// Проверка взаимодействий
verify(paymentMock).processPayment(100.0);
verify(notificationMock).sendConfirmation(anyString());
}
}

AssertJ — улучшенные проверки

AssertJ предоставляет богатый и интуитивно понятный API для написания утверждений (assertions), делая тесты более читабельными.

import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

public class UserValidatorTest {

@Test
void validateUserTest() {
User user = new User("john@example.com", "John", 25);
UserValidator validator = new UserValidator();

ValidationResult result = validator.validate(user);

assertThat(result.isValid()).isTrue();
assertThat(result.getErrors())
.isEmpty()
.as("Проверка отсутствия ошибок для валидного пользователя");

User invalidUser = new User("invalid-email", "", -5);
ValidationResult invalidResult = validator.validate(invalidUser);

assertThat(invalidResult.isValid()).isFalse();
assertThat(invalidResult.getErrors())
.hasSize(3)
.contains("Invalid email format")
.contains("Name cannot be empty")
.contains("Age must be positive");
}
}

В таблице ниже приведено сравнение основных фреймворков для unit-тестирования в Java:

Выбор фреймворка зависит от специфики проекта, но большинство современных Java-приложений использует комбинацию JUnit 5 + Mockito + AssertJ для достижения баланса между функциональностью, читабельностью и простотой использования. 🛠️

Как написать эффективные unit-тесты: пошаговое руководство

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

Шаг 1: Определение того, что нужно тестировать

Первый шаг — четко понять, какую функциональность или компонент вы тестируете и какие аспекты требуют проверки.

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

Например, для метода парсинга даты из строки, вам потребуется проверить:

• Корректные форматы дат (стандартные случаи)
• Различные форматы и стили записи дат (вариативность)
• Некорректные строки, которые не являются датами (обработка ошибок)
• Граничные случаи (переходы года, високосные годы, смены тысячелетий)

Шаг 2: Структурирование теста по модели AAA

Модель Arrange-Act-Assert (AAA) или Given-When-Then в BDD — это проверенный шаблон для структурирования unit-тестов:

@Test
void calculateDiscountTest() {
// Arrange (подготовка)
Customer goldCustomer = new Customer("John", CustomerType.GOLD);
Order order = new Order(goldCustomer, 1000.0);
PriceCalculator calculator = new PriceCalculator();

// Act (действие)
double finalPrice = calculator.calculateFinalPrice(order);

// Assert (проверка)
assertEquals(800.0, finalPrice, 0.01, "Gold customers should get 20% discount");
}

Этот шаблон делает тесты понятными и единообразными, что критически важно для поддерживаемости кодовой базы тестов.

Шаг 3: Именование тестов и организация тестового класса

Хорошие имена тестов — это документация, объясняющая, что делает код и как он должен себя вести.

• Шаблон имени: методТестируемогоКлассаусловиеТестаожидаемоеПоведение
• Пример: calculateNegativeAmountThrowsIllegalArgumentException

Современный подход с JUnit 5 также использует описательные аннотации:

@Test
@DisplayName("Price calculation: gold customer with order over $1000 gets 20% discount")
void calculatePriceWithGoldCustomerDiscount() {
// тест
}

Организуйте тесты логически, группируя связанные проверки:

class UserServiceTest {

@Nested
@DisplayName("User registration tests")
class RegistrationTests {
@Test
void registerNewUser_ValidData_ReturnsCreatedUser() { /* ... */ }

@Test
void registerNewUser_EmailAlreadyExists_ThrowsDuplicateException() { /* ... */ }
}

@Nested
@DisplayName("User authentication tests")
class AuthenticationTests {
@Test
void authenticate_ValidCredentials_ReturnsToken() { /* ... */ }

@Test
void authenticate_InvalidPassword_ThrowsAuthException() { /* ... */ }
}
}

Шаг 4: Использование параметризованных тестов для проверки многих случаев

Когда требуется проверить метод с разными входными данными, параметризованные тесты значительно сокращают дублирование кода:

@ParameterizedTest
@DisplayName("Email validation with multiple cases")
@CsvSource({
"user@example.com, true", 
"invalid-email, false",
"user.name@domain.co.uk, true",
"@missing-username.com, false"
})
void validateEmail(String email, boolean expectedResult) {
EmailValidator validator = new EmailValidator();
assertEquals(expectedResult, validator.isValid(email),
"Email validation failed for: " + email);
}

Шаг 5: Написание тестов, устойчивых к изменениям

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

• Тестируйте через публичный API, а не обращайтесь к приватным деталям
• Проверяйте конечный результат, а не промежуточные шаги (если это не критично)
• Используйте моки только для внешних зависимостей, а не для тестирования внутренних взаимодействий

Мария Соколова, QA Lead

В моей практике был случай, когда я присоединилась к проекту с низким покрытием кода тестами. Команда сопротивлялась внедрению unit-тестирования, аргументируя это нехваткой времени и тем, что "всё и так работает".

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

На демонстрации команде я показала, как именно тесты выявили эти проблемы. Ключевым моментом стало то, что я структурировала тесты как документацию — каждый метод имел понятное название, описывающее сценарий и ожидаемое поведение.

После исправления багов мы запустили A/B-тестирование и увидели снижение количества прерванных транзакций на 17%. Это был тот редкий случай, когда технический долг удалось монетизировать и показать бизнес-ценность unit-тестирования.

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

Мокирование и изоляция зависимостей в Java-тестах

Истинный unit-тест должен проверять только тестируемый класс, изолируя его от внешних зависимостей. Здесь на помощь приходит мокирование — техника создания объектов, имитирующих поведение реальных зависимостей. 🎭

Основные типы тестовых двойников

В Java-тестировании используются несколько типов замен реальных объектов:

• Mock (мок) — объект, записывающий вызовы методов и позволяющий проверить взаимодействия
• Stub (заглушка) — упрощенная реализация, возвращающая предопределенные ответы
• Fake — функциональная реализация, но упрощенная (например, in-memory база данных)
• Spy (шпион) — частичный мок, который использует реальный объект, но отслеживает вызовы

Разница между ними важна, поскольку влияет на способ написания и проверки тестов:

Практические примеры с Mockito

Mockito — самый популярный фреймворк для мокирования в Java. Рассмотрим типичные сценарии его использования:

Мокирование с настройкой поведения

// Тестируем сервис заказов, который зависит от сервиса платежей
@Test
void completeOrder_SuccessfulPayment_OrderMarkedAsPaid() {
// Создаем мок сервиса платежей
PaymentService paymentServiceMock = mock(PaymentService.class);

// Настраиваем, что метод processPayment должен возвращать true
when(paymentServiceMock.processPayment(anyDouble(), anyString()))
.thenReturn(true);

// Создаем тестируемый объект, внедряя мок
OrderService orderService = new OrderService(paymentServiceMock);

// Вызываем тестируемый метод
Order order = new Order("12345", 100.0);
orderService.completeOrder(order, "4111-1111-1111");

// Проверяем, что заказ помечен как оплаченный
assertTrue(order.isPaid());

// Проверяем, что метод processPayment был вызван с правильными аргументами
verify(paymentServiceMock).processPayment(100.0, "4111-1111-1111");
}

Мокирование с выбрасыванием исключений

@Test
void completeOrder_PaymentFailed_ThrowsPaymentException() {
// Создаем мок, который будет выбрасывать исключение
PaymentService paymentServiceMock = mock(PaymentService.class);
when(paymentServiceMock.processPayment(anyDouble(), anyString()))
.thenThrow(new PaymentFailedException("Insufficient funds"));

OrderService orderService = new OrderService(paymentServiceMock);
Order order = new Order("12345", 100.0);

// Проверяем, что метод выбрасывает ожидаемое исключение
assertThrows(OrderProcessingException.class, () -> {
orderService.completeOrder(order, "4111-1111-1111");
});

// Проверяем, что заказ не помечен как оплаченный
assertFalse(order.isPaid());
}

Проверка последовательности и количества вызовов

@Test
void processRefund_CompleteRefund_NotifiesCustomerAndUpdatesInventory() {
// Создаем моки
NotificationService notificationMock = mock(NotificationService.class);
InventoryService inventoryMock = mock(InventoryService.class);

RefundService refundService = new RefundService(notificationMock, inventoryMock);

// Вызываем тестируемый метод
refundService.processRefund(new Refund("R123", 150.0, "C001"));

// Проверяем последовательность вызовов
InOrder inOrder = inOrder(inventoryMock, notificationMock);
inOrder.verify(inventoryMock).updateStock(anyString(), anyInt());
inOrder.verify(notificationMock).sendRefundNotification(anyString(), anyDouble());

// Проверяем, что больше никаких взаимодействий не было
verifyNoMoreInteractions(notificationMock);
}

Использование ArgumentCaptor для проверки сложных аргументов

Когда нужно проверить сложные объекты, переданные в мокированный метод:

@Test
void sendOrderConfirmation_ComplexOrder_CorrectEmailContent() {
// Создаем мок сервиса отправки email
EmailService emailServiceMock = mock(EmailService.class);

// Создаем тестируемый сервис
NotificationService notificationService = new NotificationService(emailServiceMock);

// Создаем тестовые данные
Customer customer = new Customer("john@example.com", "John Smith");
Order order = new Order("123456", Arrays.asList(
new OrderItem("Product A", 2, 25.0),
new OrderItem("Product B", 1, 50.0)
));

// Вызываем тестируемый метод
notificationService.sendOrderConfirmation(customer, order);

// Создаем ArgumentCaptor для захвата аргументов
ArgumentCaptor<String> emailCaptor = ArgumentCaptor.forClass(String.class);
ArgumentCaptor<String> contentCaptor = ArgumentCaptor.forClass(String.class);

// Проверяем вызов с захватом аргументов
verify(emailServiceMock).sendEmail(
emailCaptor.capture(), 
anyString(), 
contentCaptor.capture()
);

// Проверяем захваченные значения
assertEquals("john@example.com", emailCaptor.getValue());
String content = contentCaptor.getValue();
assertTrue(content.contains("123456"));
assertTrue(content.contains("Product A"));
assertTrue(content.contains("$100.00")); // Общая сумма
}

Лучшие практики мокирования

Эффективное использование моков требует понимания нескольких ключевых принципов:

• Мокируйте только то, что необходимо — чрезмерное мокирование делает тесты хрупкими
• Мокируйте интерфейсы или абстракции, а не конкретные классы, когда это возможно
• Не мокируйте типы-значения (String, Integer и т.д.) или простые POJO-объекты
• Инъекция зависимостей делает код более тестируемым — используйте её в проектировании
• Избегайте мокирования тестируемого класса — это создает риск тестирования мока, а не реальной логики

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

Интеграция тестирования в процесс разработки Java-проектов

Эффективное внедрение unit-тестирования выходит за рамки написания отдельных тестов — это создание культуры и процессов, обеспечивающих высокое качество кода. Рассмотрим, как встроить тестирование в рабочий процесс Java-команды.

Непрерывная интеграция (CI) с автоматическим запуском тестов

Настройка CI-пайплайна для автоматического запуска тестов при каждом коммите или пул-реквесте — фундамент эффективного тестирования:

# Пример базовой конфигурации GitHub Actions для Java-проекта
name: Java CI with Maven

on: [push, pull_request]

jobs:
build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Build and test with Maven
run: mvn -B test
- name: Generate test coverage report
run: mvn jacoco:report
- name: Upload coverage report
uses: actions/upload-artifact@v2
with:
name: coverage-report
path: target/site/jacoco

Ключевые аспекты интеграции тестирования в CI:

• Настройка быстрого запуска только unit-тестов для оперативной обратной связи
• Отдельные этапы для более длительных интеграционных тестов
• Автоматическое формирование отчетов о покрытии кода тестами
• Настройка уведомлений команды при падении тестов

Test-Driven Development (TDD)

TDD — это подход к разработке, при котором тесты пишутся до реализации функциональности, следуя циклу:

1. Red: Написать тест, который падает
2. Green: Написать минимальный код, позволяющий тесту пройти
3. Refactor: Улучшить код, сохраняя прохождение теста

Пример процесса TDD для реализации валидации email:

// 1. Сначала пишем тест (Red)
@Test
void isValidEmail_CorrectEmailFormat_ReturnsTrue() {
EmailValidator validator = new EmailValidator();
boolean result = validator.isValidEmail("user@example.com");
assertTrue(result);
}

// 2. Минимальная реализация для прохождения теста (Green)
public class EmailValidator {
public boolean isValidEmail(String email) {
return email != null && email.contains("@");
}
}

// 3. Добавляем больше тестов
@Test
void isValidEmail_MissingAtSymbol_ReturnsFalse() {
EmailValidator validator = new EmailValidator();
boolean result = validator.isValidEmail("userexample.com");
assertFalse(result);
}

@Test
void isValidEmail_MissingDomain_ReturnsFalse() {
EmailValidator validator = new EmailValidator();
boolean result = validator.isValidEmail("user@");
assertFalse(result);
}

// 4. Улучшаем реализацию (Refactor)
public class EmailValidator {
private static final Pattern EMAIL_PATTERN = 
Pattern.compile("^[A-Za-z0-9+_.-]+@(.+)$");

public boolean isValidEmail(String email) {
if (email == null) return false;
Matcher matcher = EMAIL_PATTERN.matcher(email);
return matcher.matches();
}
}

Управление покрытием кода тестами

Покрытие кода (code coverage) — это метрика, показывающая, какая часть кода выполняется во время тестирования. Для Java-проектов основным инструментом измерения покрытия является JaCoCo.

Настройка JaCoCo в Maven-проекте:

<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.7</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>check</id>
<goals>
<goal>check</goal>
</goals>
<configuration>
<rules>
<rule>
<element>CLASS</element>
<limits>
<limit>
<counter>LINE</counter>
<value>COVEREDRATIO</value>
<minimum>0.80</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>

Важно помнить о разных типах покрытия:

• Line coverage — какой процент строк кода был выполнен
• Branch coverage — какой процент ветвлений (if/else) был выполнен
• Method coverage — какой процент методов был вызван
• Class coverage — какой процент классов был загружен

Внедрение Code Reviews с фокусом на тесты

Проверка качества тестов должна быть частью процесса ревью кода. Чек-лист для ревью тестов:

1. Проверяют ли тесты правильное поведение, а не детали реализации?
2. Покрыты ли граничные случаи и сценарии ошибок?
3. Понятны ли имена тестов и отражают ли они тестируемое поведение?
4. Независимы ли тесты друг от друга?
5. Нет ли чрезмерного использования моков или анти-паттернов тестирования?

Инструменты и практики для оптимизации процесса тестирования

1. Mutation Testing (PIT, Pitest) — проверяет эффективность тестов путем внесения изменений в код и проверки, обнаруживают ли тесты эти изменения
2. Property-Based Testing (jqwik) — генерация тестовых данных на основе свойств, которым должен соответствовать код
3. Consumer-Driven Contract Testing (Pact) — для микросервисных архитектур, где потребители определяют контракты для провайдеров
4. Continuous Testing — запуск тестов в фоновом режиме во время разработки, например, с помощью Infinitest

Для максимальной эффективности важно также определить, какие области кода требуют более тщательного тестирования:

• Высокий приоритет: бизнес-логика, критические алгоритмы, обработка платежей, безопасность
• Средний приоритет: сервисный слой, адаптеры API, основные утилиты
• Низкий приоритет: простые POJO-классы, инфраструктурный код, UI-элементы

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

Качественное unit-тестирование — это не дополнительная нагрузка, а инвестиция в стабильность и масштабируемость вашего Java-проекта. Грамотное использование JUnit, Mockito и других инструментов поможет создать надежную страховочную сетку, которая ловит ошибки еще до того, как они попадут в продакшн. Помните: время, потраченное на написание тестов сегодня, экономит дни и недели отладки завтра. Начните с малого — добавьте тесты к критически важным компонентам, постепенно формируйте культуру тестирования в команде, и вы увидите, как повышается не только качество кода, но и уверенность разработчиков при внедрении изменений.

Читайте также

• Java для веб-разработки: создание сайта с нуля на фреймворках
• Первая работа Java и Kotlin разработчика: путь от новичка к профессионалу
• 15 идей Android-приложений на Java: от простых до коммерческих
• Создаем идеальное резюме Java и Python разработчика: структура, навыки
• 15 стратегий ускорения Java-приложений: от фундамента до тюнинга
• IntelliJ IDEA: возможности Java IDE для начинающих разработчиков
• Абстракция в Java: принципы построения гибкой архитектуры кода
• JVM: как Java машина превращает код в работающую программу
• Полиморфизм в Java: принципы объектно-ориентированного подхода
• Оператор switch в Java: от основ до продвинутых выражений