Хотите править код сразу в нескольких местах? Multi-Caret Editing позволяет поставить несколько курсоров и синхронно редактировать текст.
🔹 Что делает
— Позволяет редактировать одинаковые участки кода одновременно
— Ускоряет массовое переименование переменных, правки форматирования и шаблонных конструкций
— Работает не только в коде, но и в файлах конфигурации, JSON, XML
🔹 Зачем это нужно
— Экономит время при рутинных правках
— Снижает вероятность пропустить один из повторяющихся фрагментов
— Делает код-ревью и рефакторинг быстрее
🔹 Как использовать
— Выделите слово и нажмите Alt+J (Windows/Linux) или Ctrl+G (macOS) — добавится второй курсор
— Продолжайте нажимать, чтобы выбрать следующие вхождения
— Для выбора сразу всех вхождений используйте Ctrl+Alt+Shift+J
— Для произвольных позиций используйте Alt+Click для добавления курсора в нужное место
#Enterprise
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤2🔥2🤔2
🎯 Интеграционные тесты с Testcontainers
Пошаговая настройка тестов на Spring Boot 3 с Testcontainers + PostgreSQL: быстро, изолированно, воспроизводимо.
1️⃣ Зависимости (Maven/Gradle)
— Maven (pom.xml):
— Gradle (Kotlin DSL):
2️⃣ Включаем Testcontainers
C Spring Boot 3.1 контейнер можно подключить одной аннотацией без ручного прописывания spring.datasource.*.
3️⃣ Миграции для тестов (Flyway)
Положите миграции в src/test/resources/db/migration (отдельно от продовых — удобно для фикстур):
4️⃣ Ускоряем прогоны
▪️ Reusable containers (кэшируемый демон): добавьте в ~/.testcontainers.properties
и .withReuse(true) для контейнера в тесте.
▪️ Singleton-паттерн контейнера: вынесите контейнер в общий абстрактный класс теста, чтобы один контейнер работал на все тесты.
5️⃣ Полезные трюки и подводные камни
— Если на MacOS/Colima, проверьте доступность Docker API (docker info) перед тестами.
— Для детерминизма фиксируйте теги образов (например, postgres:16-alpine), не latest.
— Логи контейнеров доступны: postgres.followOutput(...) — удобно для диагностики нестабильных тестов.
— Если нужен R2DBC: поднимайте Postgres как выше, а в application-test.yml указывайте r2dbc URL; @ServiceConnection корректно сконфигурирует оба коннектора, если они в classpath.
— Тяжёлые фикстуры → создавайте через SQL-маски (V*_seed.sql) или @Sql прямо в тестах — не смешивайте тестовые данные с продовыми миграциями.
🐸 Библиотека джависта
#Enterprise
Пошаговая настройка тестов на Spring Boot 3 с Testcontainers + PostgreSQL: быстро, изолированно, воспроизводимо.
— Maven (pom.xml):
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-bom</artifactId>
<version>1.20.3</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>postgresql</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
— Gradle (Kotlin DSL):
dependencies {
implementation("org.springframework.boot:spring-boot-starter-data-jpa")
testImplementation("org.flywaydb:flyway-core")
testImplementation("org.postgresql:postgresql")
testImplementation(platform("org.testcontainers:testcontainers-bom:1.20.3"))
testImplementation("org.testcontainers:junit-jupiter")
testImplementation("org.testcontainers:postgresql")
}
C Spring Boot 3.1 контейнер можно подключить одной аннотацией без ручного прописывания spring.datasource.*.
@Testcontainers
@ExtendWith(SpringExtension.class)
@SpringBootTest
class PostgresIT {
@Container
@ServiceConnection // Spring сам подставит URL/логин/пароль в DataSource
static PostgreSQLContainer<?> postgres =
new PostgreSQLContainer<>("postgres:16-alpine")
.withDatabaseName("app")
.withUsername("app")
.withPassword("secret");
@Test
void contextLoads() {
// проверяем, что контекст и datasource поднялись на контейнере
}
}
Положите миграции в src/test/resources/db/migration (отдельно от продовых — удобно для фикстур):
src/
└─ test/
└─ resources/
└─ db/
└─ migration/
├─ V1__init.sql
└─ V2__seed.sql
▪️ Reusable containers (кэшируемый демон): добавьте в ~/.testcontainers.properties
testcontainers.reuse.enable=true
и .withReuse(true) для контейнера в тесте.
▪️ Singleton-паттерн контейнера: вынесите контейнер в общий абстрактный класс теста, чтобы один контейнер работал на все тесты.
— Если на MacOS/Colima, проверьте доступность Docker API (docker info) перед тестами.
— Для детерминизма фиксируйте теги образов (например, postgres:16-alpine), не latest.
— Логи контейнеров доступны: postgres.followOutput(...) — удобно для диагностики нестабильных тестов.
— Если нужен R2DBC: поднимайте Postgres как выше, а в application-test.yml указывайте r2dbc URL; @ServiceConnection корректно сконфигурирует оба коннектора, если они в classpath.
— Тяжёлые фикстуры → создавайте через SQL-маски (V*_seed.sql) или @Sql прямо в тестах — не смешивайте тестовые данные с продовыми миграциями.
#Enterprise
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍4❤2