Unit Test JPA Repositories Trong Spring Boot: Nền Tảng Vững Chắc Cho Lớp Dữ Liệu (Series Java Spring Roadmap)

Chào mừng bạn quay trở lại với chuỗi bài viết “Java Spring Roadmap”! Trên hành trình làm chủ Spring Boot của chúng ta, chúng ta đã đi qua rất nhiều khái niệm cốt lõi: từ lý do chọn Spring, Dependency Injection, Spring IoC và quản lý Beans, cách Spring hoạt động, cho đến việc xây dựng ứng dụng web đầu tiên với Spring MVC, xử lý bảo mật với Spring Security, và khám phá sức mạnh của Spring Boot với Starters, Autoconfiguration. Gần đây nhất, chúng ta đã bắt đầu lặn sâu vào lớp Persistence (lớp truy cập dữ liệu) với Hibernate/JPA, ánh xạ các mối quan hệ, vòng đời thực thể, và đặc biệt là sự tiện lợi mà Spring Data JPA mang lại thông qua các Repositories.

Khi xây dựng một ứng dụng, việc tương tác với database là một phần không thể thiếu. Lớp Repositories (hoặc DAOs – Data Access Objects) chính là nơi diễn ra sự tương tác này. Nó đóng vai trò như một “cửa ngõ” giữa ứng dụng của bạn và database. Tuy nhiên, chỉ viết code mà không kiểm tra kỹ lưỡng thì giống như lái xe trên đường mà không có đèn chiếu sáng vậy. Việc đảm bảo rằng các thao tác lưu trữ, truy xuất, cập nhật và xóa dữ liệu hoạt động đúng như mong đợi là cực kỳ quan trọng.

Trong bài viết này, chúng ta sẽ tập trung vào việc kiểm thử (testing) lớp Repositories một cách hiệu quả trong môi trường Spring Boot, cụ thể là sử dụng Unit Test. Chúng ta sẽ tìm hiểu tại sao việc này lại cần thiết, những thách thức thường gặp và làm thế nào Spring Boot với annotation @DataJpaTest giúp chúng ta giải quyết những thách thức đó một cách thanh lịch.

Tại Sao Cần Unit Test Cho JPA Repositories?

Trước hết, hãy làm rõ khái niệm “Unit Test”. Unit Test là một phương pháp kiểm thử phần mềm trong đó các đơn vị nhỏ nhất có thể kiểm thử được của một ứng dụng (gọi là các đơn vị – units) được kiểm thử một cách cô lập để xác định xem chúng có phù hợp với mục đích sử dụng hay không. Đối với Repositories, “đơn vị” chính là các phương thức trong interface Repository của bạn (như save(), findById(), findBy...(), v.v.).

Nhiều người có thể nghĩ: “Các phương thức cơ bản như save() hay findById() là của Spring Data JPA/Hibernate, chúng đã được kiểm thử rồi, sao tôi phải kiểm thử lại?” Đúng, bản thân các phương thức cốt lõi đã rất ổn định. Tuy nhiên, có nhiều lý do bạn vẫn cần kiểm thử Repositories của mình:

1. Kiểm tra Mapping Entity: Đảm bảo rằng các annotation JPA (@Entity, @Table, @Column, @OneToMany, v.v.) mà bạn đã cấu hình trong các bài viết trước hoạt động đúng với cấu trúc database thực tế (hoặc cấu trúc bạn mô phỏng trong test). Sai sót trong mapping là khá phổ biến.
2. Xác minh Custom Queries: Nếu bạn định nghĩa các phương thức truy vấn tùy chỉnh (ví dụ: findByEmail(String email) hoặc sử dụng @Query), Unit Test là cách hiệu quả nhất để đảm bảo cú pháp query của bạn đúng, tên cột/bảng chính xác và logic truy vấn mang lại kết quả mong muốn.
3. Kiểm tra Logic Repo đơn giản: Mặc dù Repositories nên tập trung vào CRUD, đôi khi bạn có thể thêm logic nhỏ liên quan trực tiếp đến việc truy cập dữ liệu tại đây. Test giúp xác minh logic đó.
4. Phản hồi nhanh chóng: Unit tests chạy rất nhanh vì chúng cô lập chỉ một phần nhỏ của ứng dụng và thường sử dụng database trong bộ nhớ (in-memory database). Điều này cho phép bạn chạy test thường xuyên trong quá trình phát triển và nhận phản hồi ngay lập tức nếu có gì đó sai sót ở lớp persistence.
5. Giảm thiểu Bug liên quan đến Database: Việc kiểm thử sớm và kỹ lưỡng lớp truy cập dữ liệu giúp bắt các lỗi liên quan đến database ngay từ đầu, tránh việc chúng lan đến các lớp cao hơn (Service, Controller) và khó debug hơn.

So với Integration Test (kiểm thử tích hợp) toàn bộ ứng dụng hoặc một phần lớn của ứng dụng, Unit Test cho Repository nhanh hơn rất nhiều và dễ dàng xác định nguyên nhân lỗi (chỉ nằm ở lớp Repository hoặc cấu hình liên quan).

Thách Thức Khi Test Repositories

Thách thức lớn nhất khi kiểm thử lớp truy cập dữ liệu chính là sự phụ thuộc vào database. Để kiểm thử một Repository, bạn cần một database để nó tương tác. Điều này đặt ra các vấn đề:

• Môi trường Database: Bạn cần một instance database đang chạy. Sử dụng database “thật” (như MySQL, PostgreSQL đang chạy cục bộ hoặc trên server) có thể chậm, đòi hỏi cấu hình phức tạp và khó đảm bảo trạng thái dữ liệu sạch sẽ, nhất quán cho mỗi lần chạy test.
• Quản lý Dữ liệu Test: Trước khi chạy một test, bạn cần có dữ liệu trong database. Sau khi chạy test, bạn cần “dọn dẹp” dữ liệu đó để test tiếp theo không bị ảnh hưởng. Việc này có thể tốn công sức và dễ xảy ra lỗi.
• Tốc độ: Kết nối và tương tác với database “thật” luôn chậm hơn so với việc chạy logic trong bộ nhớ. Điều này làm giảm tốc độ chạy test tổng thể.

Spring Boot Cứu Cánh Với @DataJpaTest

Spring Boot hiểu rất rõ những thách thức này và cung cấp một giải pháp tuyệt vời cho việc kiểm thử lớp JPA Repository: annotation @DataJpaTest.

@DataJpaTest là một trong những “test slice” của Spring Boot. Nó được thiết kế đặc biệt để kiểm thử các thành phần của lớp Persistence. Khi bạn sử dụng @DataJpaTest trên một lớp test, Spring Boot sẽ tự động cấu hình những thứ cần thiết cho việc kiểm thử JPA:

• Nó sẽ scan các @Entity classes của bạn.
• Nó sẽ cấu hình Spring Data JPA Repositories.
• Nó sẽ tự động cấu hình một in-memory database (mặc định là H2, nếu H2 có trong classpath) và kết nối JPA/Hibernate tới database này. Database này chỉ tồn tại trong bộ nhớ khi test chạy và bị hủy sau đó.
• Nó loại trừ việc autoconfigure các thành phần khác không liên quan đến JPA (như controllers, services, security, v.v.), giúp context test nhẹ nhàng và khởi động nhanh chóng.
• Mặc định, mỗi test method được bọc trong một transaction và transaction này sẽ được rollback sau khi test hoàn thành. Điều này đảm bảo trạng thái database là sạch sẽ cho mỗi test method, loại bỏ nhu cầu dọn dẹp dữ liệu thủ công.

Nói cách khác, @DataJpaTest cung cấp một môi trường test “thu nhỏ” chỉ tập trung vào lớp JPA, với database trong bộ nhớ và quản lý transaction tự động, giúp việc viết và chạy test cho Repositories trở nên nhanh chóng và đáng tin cậy.

Cài Đặt Môi Trường Test

Để sử dụng @DataJpaTest, bạn cần đảm bảo project của mình có các dependency cần thiết. Nếu bạn tạo project bằng Spring Initializr và chọn “Spring Boot DevTools”, “Spring Data JPA” và “H2 Database”, thì dependency kiểm thử (spring-boot-starter-test) và H2 đã có sẵn.

Dependency tối thiểu bạn cần cho kiểm thử JPA Repositories là:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

Hoặc với Gradle:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

Bây giờ, hãy tạo một lớp test. Giả sử chúng ta có một Entity Product và một Repository ProductRepository:

package com.example.demo.entity; // package của bạn

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private double price;

    // Getters and Setters
    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public double getPrice() { return price; }
    public void setPrice(double price) { this.price = price; }

    // Constructors
    public Product() {}
    public Product(String name, double price) {
        this.name = name;
        this.price = price;
    }

    // toString (optional but helpful for debugging)
    @Override
    public String toString() {
        return "Product{" +
               "id=" + id +
               ", name='" + name + '\'' +
               ", price=" + price +
               '}';
    }
}

package com.example.demo.repository; // package của bạn

import com.example.demo.entity.Product;
import org.springframework.data.jpa.repository.JpaRepository;
import java.util.List;
import java.util.Optional;

public interface ProductRepository extends JpaRepository<Product, Long> {
    // Custom query method
    Optional<Product> findByName(String name);
    List<Product> findByPriceGreaterThan(double price);
}

Lớp test sẽ trông như thế này:

package com.example.demo.repository; // Đặt lớp test trong package tương ứng hoặc test package

import com.example.demo.entity.Product;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;
import java.util.List;
import java.util.Optional;

import static org.assertj.core.api.Assertions.assertThat; // Sử dụng AssertJ

@DataJpaTest
@DisplayName("Tests cho ProductRepository") // Sử dụng DisplayName cho báo cáo test đẹp hơn
class ProductRepositoryTest {

    @Autowired
    private ProductRepository productRepository;

    @Autowired
    private TestEntityManager entityManager; // Helper để làm việc với entities trong test

    // Các test methods sẽ ở đây...
}

Annotation @DataJpaTest sẽ tự động cấu hình mọi thứ. Chúng ta chỉ cần @Autowired Repository mà chúng ta muốn test. TestEntityManager là một tiện ích hữu ích do Spring cung cấp trong môi trường @DataJpaTest, cho phép bạn tương tác trực tiếp với context JPA (ví dụ: persist entities, find entities) mà không cần thông qua Repository. Nó hữu ích cho việc thiết lập dữ liệu test ban đầu.

Mặc định, @DataJpaTest sẽ cố gắng sử dụng in-memory database. Nếu bạn muốn test với database “thật” (ví dụ: MySQL, PostgreSQL) trong môi trường test, bạn có thể cấu hình @AutoConfigureTestDatabase:

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) // Không thay thế database, dùng cái đã cấu hình
//@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE, connection = EmbeddedDatabaseConnection.H2) // Vẫn dùng H2 nhưng không ghi đè cấu hình khác
class ProductRepositoryTest {
    //...
}

Tuy nhiên, mục tiêu của “Unit Test” Repositories là sự nhanh chóng và cô lập, nên việc sử dụng in-memory database (mặc định) là phổ biến và khuyến khích cho mục đích này. Sử dụng database “thật” trong test thường được xếp vào loại Integration Test.

Viết Unit Tests Thực Tế

Bây giờ chúng ta sẽ viết các test methods để kiểm tra các chức năng cơ bản và các truy vấn tùy chỉnh của ProductRepository.

package com.example.demo.repository;

import com.example.demo.entity.Product;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;

import java.util.List;
import java.util.Optional;

import static org.assertj.core.api.Assertions.assertThat; // Sử dụng AssertJ

@DataJpaTest
@DisplayName("Tests cho ProductRepository")
class ProductRepositoryTest {

    @Autowired
    private ProductRepository productRepository;

    @Autowired
    private TestEntityManager entityManager;

    @Test
    @DisplayName("Test Save và FindById")
    void testSaveAndFindById() {
        // Arrange (Thiết lập dữ liệu test)
        Product newProduct = new Product("Laptop ABC", 1200.00);

        // Act (Thực hiện hành động cần test)
        Product savedProduct = productRepository.save(newProduct);
        Optional<Product> foundProduct = productRepository.findById(savedProduct.getId());

        // Assert (Kiểm tra kết quả)
        assertThat(savedProduct).isNotNull();
        assertThat(savedProduct.getId()).isNotNull();
        assertThat(savedProduct.getName()).isEqualTo("Laptop ABC");
        assertThat(savedProduct.getPrice()).isEqualTo(1200.00);

        assertThat(foundProduct).isPresent(); // Đảm bảo tìm thấy
        assertThat(foundProduct.get().getName()).isEqualTo("Laptop ABC");
        assertThat(foundProduct.get().getPrice()).isEqualTo(1200.00);
    }

    @Test
    @DisplayName("Test FindAll khi có dữ liệu")
    void testFindAllWithData() {
        // Arrange
        entityManager.persist(new Product("Phone X", 800.00));
        entityManager.persist(new Product("Tablet Y", 450.00));
        entityManager.flush(); // Đẩy các thay đổi vào database in-memory

        // Act
        List<Product> products = productRepository.findAll();

        // Assert
        assertThat(products).isNotNull();
        assertThat(products).hasSize(2); // Kiểm tra số lượng
        assertThat(products).extracting(Product::getName) // Kiểm tra tên sản phẩm
                           .containsExactlyInAnyOrder("Phone X", "Tablet Y"); // Đảm bảo chứa đúng tên (không quan trọng thứ tự)
    }

    @Test
    @DisplayName("Test FindAll khi không có dữ liệu")
    void testFindAllWhenEmpty() {
        // Arrange: Không có dữ liệu nào được thêm vào (do rollback transaction)

        // Act
        List<Product> products = productRepository.findAll();

        // Assert
        assertThat(products).isNotNull();
        assertThat(products).isEmpty(); // Danh sách rỗng
    }

    @Test
    @DisplayName("Test FindByName (custom query)")
    void testFindByName() {
        // Arrange
        Product product1 = new Product("Keyboard Z", 150.00);
        Product product2 = new Product("Mouse W", 50.00);
        entityManager.persist(product1);
        entityManager.persist(product2);
        entityManager.flush();

        // Act
        Optional<Product> foundProduct = productRepository.findByName("Keyboard Z");
        Optional<Product> notFoundProduct = productRepository.findByName("Monitor M");

        // Assert
        assertThat(foundProduct).isPresent();
        assertThat(foundProduct.get().getName()).isEqualTo("Keyboard Z");
        assertThat(notFoundProduct).isNotPresent(); // Đảm bảo không tìm thấy sản phẩm không tồn tại
    }

    @Test
    @DisplayName("Test FindByPriceGreaterThan (custom query)")
    void testFindByPriceGreaterThan() {
        // Arrange
        Product product1 = new Product("Cheap Item", 20.00);
        Product product2 = new Product("Medium Item", 100.00);
        Product product3 = new Product("Expensive Item", 500.00);
        entityManager.persist(product1);
        entityManager.persist(product2);
        entityManager.persist(product3);
        entityManager.flush();

        // Act
        List<Product> expensiveProducts = productRepository.findByPriceGreaterThan(90.00);

        // Assert
        assertThat(expensiveProducts).isNotNull();
        assertThat(expensiveProducts).hasSize(2);
        assertThat(expensiveProducts).extracting(Product::getName)
                           .containsExactlyInAnyOrder("Medium Item", "Expensive Item");
    }


    @Test
    @DisplayName("Test DeleteById")
    void testDeleteById() {
        // Arrange
        Product productToDelete = new Product("Old Stuff", 10.00);
        entityManager.persist(productToDelete);
        entityManager.flush(); // Đẩy vào database để lấy ID

        Long productId = productToDelete.getId();
        assertThat(productRepository.findById(productId)).isPresent(); // Đảm bảo nó tồn tại trước khi xóa

        // Act
        productRepository.deleteById(productId);
        Optional<Product> deletedProduct = productRepository.findById(productId);

        // Assert
        assertThat(deletedProduct).isNotPresent(); // Đảm bảo đã bị xóa
    }
}

Trong các test methods trên:

• Chúng ta sử dụng annotation @Test của JUnit 5.
• @DisplayName giúp đặt tên rõ ràng cho từng test case, làm cho báo cáo kết quả test dễ đọc hơn.
• Chúng ta tuân theo cấu trúc Arrange, Act, Assert (AAA) phổ biến trong kiểm thử:
  • Arrange: Thiết lập môi trường test, tạo dữ liệu cần thiết. Chúng ta dùng entityManager.persist() để lưu các entities vào database in-memory. entityManager.flush() đảm bảo các thay đổi được đồng bộ ngay lập tức.
  • Act: Thực hiện hành động cần test, tức là gọi phương thức trên productRepository.
  • Assert: Kiểm tra kết quả hành động có đúng như mong đợi không. Chúng ta sử dụng thư viện AssertJ (được bao gồm trong spring-boot-starter-test) với cú pháp fluent (chuỗi các lệnh) rất dễ đọc (ví dụ: assertThat(savedProduct).isNotNull();).
• Lưu ý rằng sau mỗi test method, transaction mặc định của @DataJpaTest sẽ tự động rollback. Điều này có nghĩa là dữ liệu bạn thêm vào (ví dụ: Phone X, Tablet Y) trong testFindAllWithData sẽ bị xóa sạch trước khi testFindByName chạy. Mỗi test method hoạt động trong môi trường database “sạch” của riêng nó.

Quản Lý Dữ Liệu Test (@Transactional và Data Setup)

Như đã đề cập, @DataJpaTest mặc định chạy với @Transactional và rollback sau mỗi test. Đây là hành vi rất mong muốn cho Unit Test vì nó đảm bảo tính độc lập giữa các test. Bạn không cần lo lắng về việc test A ảnh hưởng đến test B thông qua dữ liệu trong database.

Nếu vì lý do đặc biệt nào đó bạn muốn một test method *không* rollback (ví dụ: để debug database state hoặc cho một loại test khác), bạn có thể thêm @Commit hoặc @Rollback(false) lên test method đó. Tuy nhiên, hãy cẩn trọng khi làm điều này vì nó có thể làm các test phụ thuộc vào nhau.

Đối với việc setup dữ liệu test, chúng ta đã thấy cách sử dụng TestEntityManager.persist(). Đây là cách đơn giản và trực tiếp, rất phù hợp khi dữ liệu test không quá phức tạp.

Một cách khác là sử dụng annotation @Sql:

@Test
@DisplayName("Test FindByPriceGreaterThan sử dụng @Sql")
@Sql("/test-data/products.sql") // Đường dẫn đến file SQL trong classpath (thường là src/test/resources)
void testFindByPriceGreaterThanWithSql() {
    // Dữ liệu đã được thêm bởi script SQL

    // Act
    List<Product> expensiveProducts = productRepository.findByPriceGreaterThan(90.00);

    // Assert
    assertThat(expensiveProducts).isNotNull();
    assertThat(expensiveProducts).hasSize(2);
    assertThat(expensiveProducts).extracting(Product::getName)
                               .containsExactlyInAnyOrder("Medium Item", "Expensive Item");
}

Với cách này, bạn tạo một file SQL (ví dụ: src/test/resources/test-data/products.sql):

INSERT INTO product (name, price) VALUES ('Cheap Item', 20.00);
INSERT INTO product (name, price) VALUES ('Medium Item', 100.00);
INSERT INTO product (name, price) VALUES ('Expensive Item', 500.00);

Trước khi test method testFindByPriceGreaterThanWithSql chạy, Spring sẽ thực thi script SQL này. Sau khi test xong, transaction lại rollback, dọn dẹp dữ liệu.

@DataJpaTest vs @SpringBootTest

Chúng ta đã gặp @SpringBootTest trong các bài viết trước. Làm thế nào để phân biệt và khi nào sử dụng @DataJpaTest so với @SpringBootTest?

Kết luận:

• Sử dụng @DataJpaTest khi bạn chỉ muốn kiểm thử riêng lớp Repository và cách nó tương tác với database. Đây là Unit Test cho lớp Persistence.
• Sử dụng @SpringBootTest khi bạn cần kiểm thử sự tương tác giữa nhiều thành phần Spring hoặc khi cấu hình bean của bạn phức tạp và cần toàn bộ context để test. Đây là Integration Test.

Trong phần lớn trường hợp, khi kiểm thử Repository, @DataJpaTest là lựa chọn phù hợp và hiệu quả hơn.

Các Lưu Ý và Thực Tiễn Tốt Nhất

• Giữ Test Focused: Test chỉ nên kiểm tra chức năng của Repository. Không đưa logic nghiệp vụ phức tạp vào test Repository. Logic nghiệp vụ nên được test ở lớp Service.
• Sử dụng Assertions Mạnh mẽ: Thay vì sử dụng assertEquals, assertTrue của JUnit, hãy sử dụng AssertJ (như trong ví dụ) để viết các assertions rõ ràng và dễ đọc hơn (ví dụ: assertThat(list).hasSize(5).contains("item1", "item2");).
• Test Cases: Ngoài các thao tác CRUD cơ bản, hãy đảm bảo bạn test tất cả các phương thức truy vấn tùy chỉnh mà bạn định nghĩa. Cân nhắc test các trường hợp edge case (ví dụ: tìm kiếm không tìm thấy, danh sách rỗng).
• Tên Test Rõ Ràng: Đặt tên test methods sao cho chúng mô tả rõ ràng mục đích của test (ví dụ: testSaveAndFindById, testFindAllWhenEmpty). Sử dụng @DisplayName là một cách hay.
• Database Thật vs. In-Memory: Đối với Unit Test Repositories, in-memory database (H2) là lý tưởng vì tốc độ và sự đơn giản. Tuy nhiên, đôi khi cú pháp SQL hoặc các tính năng cụ thể của database “thật” có thể gây ra sự khác biệt. Nếu gặp trường hợp này, bạn có thể cân nhắc viết thêm các Integration Test sử dụng database “thật” (có thể dùng Testcontainers) để kiểm tra sự tương thích, nhưng các Unit Test cơ bản vẫn nên chạy nhanh với in-memory DB.

Kết Luận

Việc Unit Test các JPA Repositories là một bước quan trọng để đảm bảo lớp truy cập dữ liệu của bạn hoạt động đúng đắn. Nó giúp bạn bắt lỗi sớm, xác minh mapping và các truy vấn tùy chỉnh, mang lại sự tự tin khi phát triển ứng dụng.

Với Spring Boot, annotation @DataJpaTest đã đơn giản hóa đáng kể quá trình này bằng cách cung cấp một môi trường test chuyên biệt, cấu hình in-memory database và quản lý transaction tự động. Bằng cách tận dụng @DataJpaTest và các công cụ đi kèm như TestEntityManager, bạn có thể viết các test hiệu quả, nhanh chóng và đáng tin cậy cho lớp Persistence của mình.

Đây là một phần không thể thiếu trong hành trình làm chủ Spring Boot của bạn. Hãy thực hành viết test cho các Repositories trong project của bạn để thấy được lợi ích của nó.

Tiếp theo trên Lộ trình Java Spring, chúng ta sẽ tiếp tục xây dựng các lớp cao hơn và tìm hiểu cách kiểm thử chúng. Nhưng trước đó, việc đảm bảo nền tảng dữ liệu vững chắc là tối quan trọng.

Hẹn gặp lại bạn trong các bài viết tiếp theo trên Spring Boot Roadmap – Lộ trình phát triển cho Java Spring Boot 2025!