JavaRush /Blog Java /Random-VI /Kiểm thử đơn vị Java: kỹ thuật, khái niệm, thực hành

Mức độ

28 February 2021
36 views
0 comments

Kiểm thử đơn vị Java: kỹ thuật, khái niệm, thực hành

Ngày nay, bạn khó có thể tìm thấy một ứng dụng không có các bài kiểm tra, vì vậy chủ đề này sẽ phù hợp hơn bao giờ hết đối với các nhà phát triển mới vào nghề: bạn không thể đi đến đâu nếu không có bài kiểm tra. Là một quảng cáo, tôi khuyên bạn nên xem các bài viết trước đây của tôi. Một số trong số chúng bao gồm các bài kiểm tra (và thậm chí các bài viết sẽ rất hữu ích):

Về nguyên tắc, hãy xem xét những loại thử nghiệm nào được sử dụng và sau đó chúng tôi sẽ nghiên cứu chi tiết mọi thứ bạn cần biết về thử nghiệm đơn vị.

Các loại thử nghiệm

Kiểm tra là gì? Như Wiki đã nói: “ Kiểm tra hoặc kiểm tra là một cách nghiên cứu các quy trình cơ bản của hệ thống bằng cách đặt hệ thống vào các tình huống khác nhau và theo dõi những thay đổi có thể quan sát được trong đó”. Nói cách khác, đây là cuộc kiểm tra hoạt động chính xác của hệ thống của chúng tôi trong một số tình huống nhất định. Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 2

Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 2

Nào, hãy xem có những loại thử nghiệm nào:

Kiểm thử đơn vị là các kiểm thử có nhiệm vụ kiểm thử từng mô-đun của hệ thống riêng lẻ. Điều mong muốn là đây là những phần có thể phân chia tối thiểu của hệ thống, ví dụ như các mô-đun.
Kiểm thử hệ thống là kiểm thử cấp cao để kiểm tra hoạt động của một phần lớn hơn của ứng dụng hoặc toàn bộ hệ thống.
Kiểm thử hồi quy là kiểm thử được sử dụng để kiểm tra xem các tính năng mới hoặc sửa lỗi có ảnh hưởng đến chức năng hiện có của ứng dụng hay không và liệu các lỗi cũ có xuất hiện trở lại hay không.
Kiểm tra chức năng là kiểm tra sự tuân thủ của một phần ứng dụng với các yêu cầu được nêu trong thông số kỹ thuật, câu chuyện của người dùng, v.v.

Các loại thử nghiệm chức năng:
- kiểm tra “hộp trắng” về sự tuân thủ của một phần ứng dụng với các yêu cầu cùng với kiến thức về triển khai nội bộ của hệ thống;
- Kiểm tra “hộp đen” về sự tuân thủ của một phần ứng dụng với các yêu cầu mà không cần biết về việc triển khai nội bộ của hệ thống.
Kiểm tra hiệu suất là một loại kiểm tra được viết để xác định tốc độ mà hệ thống hoặc một phần của hệ thống chạy dưới một tải nhất định.
Kiểm tra tải - các kiểm tra được thiết kế để kiểm tra tính ổn định của hệ thống dưới tải tiêu chuẩn và tìm ra mức cao nhất có thể mà ứng dụng hoạt động chính xác.
Kiểm thử căng thẳng là một loại kiểm thử được thiết kế để kiểm tra chức năng của ứng dụng dưới các tải không chuẩn và để xác định mức cao nhất có thể mà hệ thống sẽ không gặp sự cố.
Kiểm tra bảo mật - kiểm tra được sử dụng để kiểm tra tính bảo mật của hệ thống (trước các cuộc tấn công của tin tặc, vi rút, truy cập trái phép vào dữ liệu bí mật và các thú vui khác trong cuộc sống).
Thử nghiệm bản địa hóa là thử nghiệm bản địa hóa cho một ứng dụng.
Kiểm thử khả năng sử dụng là loại kiểm thử nhằm kiểm tra khả năng sử dụng, tính dễ hiểu, tính hấp dẫn và khả năng học hỏi của người dùng.

Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 4

Đơn vị - các bài kiểm tra đơn vị được sử dụng trong các lớp khác nhau của ứng dụng, kiểm tra logic chia nhỏ nhất của ứng dụng: ví dụ: một lớp, nhưng thường là một phương thức. Các thử nghiệm này thường cố gắng tách biệt càng nhiều càng tốt khỏi logic bên ngoài, nghĩa là tạo ra ảo tưởng rằng phần còn lại của ứng dụng đang hoạt động ở chế độ tiêu chuẩn.

Phải luôn có nhiều thử nghiệm kiểu này (nhiều hơn các loại khác), vì chúng thử nghiệm từng phần nhỏ và rất nhẹ, không tiêu tốn nhiều tài nguyên (ý tôi là tài nguyên RAM và thời gian).
Tích hợp - thử nghiệm tích hợp. Nó kiểm tra các phần lớn hơn của hệ thống, nghĩa là nó là sự kết hợp của một số phần logic (một số phương thức hoặc lớp) hoặc tính chính xác khi làm việc với một thành phần bên ngoài. Thường có ít bài kiểm tra kiểu này hơn bài kiểm tra Đơn vị vì chúng nặng hơn.

Là một ví dụ về kiểm tra tích hợp, bạn có thể xem xét việc kết nối với cơ sở dữ liệu và kiểm tra việc thực thi chính xác các phương thức làm việc với cơ sở dữ liệu đó .
UI - kiểm tra hoạt động của giao diện người dùng. Chúng ảnh hưởng đến logic ở mọi cấp độ của ứng dụng, đó là lý do tại sao chúng còn được gọi là end-to-end. Theo quy định, có ít hơn nhiều trong số chúng, vì chúng nặng nhất và phải kiểm tra các đường dẫn cần thiết (đã sử dụng) nhất.

Trong hình trên, chúng ta thấy tỷ lệ diện tích của các phần khác nhau của tam giác: tỷ lệ gần như tương tự được duy trì trong số lượng các thử nghiệm này trong công việc thực tế.

Hôm nay chúng ta sẽ xem xét kỹ hơn các bài kiểm tra được sử dụng nhiều nhất - bài kiểm tra đơn vị, vì tất cả các nhà phát triển Java tự trọng đều có thể sử dụng chúng ở mức cơ bản.

Các khái niệm chính của kiểm thử đơn vị

Phạm vi kiểm thử

tài liệu về Bảo hiểm mã trên JavaRush và trên Habré ;
lý thuyết kiểm tra cơ bản

TDD (Phát triển dựa trên thử nghiệm)

Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 6

Chúng tôi đang viết bài kiểm tra của chúng tôi.
Chúng tôi chạy thử nghiệm, cho dù nó có vượt qua hay không (chúng tôi thấy mọi thứ đều có màu đỏ - đừng lo lắng: nó phải như vậy).
Chúng tôi thêm mã phải đáp ứng thử nghiệm này (chạy thử nghiệm).
Chúng tôi cấu trúc lại mã.

BDD (Phát triển theo định hướng hành vi)

Test Case

Lịch thi đấu

Giai đoạn thử nghiệm

Chỉ định dữ liệu cần kiểm tra (đồ đạc).
Sử dụng mã đang thử nghiệm (gọi phương thức đang thử nghiệm).
Kiểm tra kết quả và so sánh chúng với kết quả mong đợi.

Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 7

Mô phỏng

Sơ khai

Spy

Đôi khi các thuật ngữ sơ khai

mô phỏng

Môi trường thử nghiệm

@Test

@Before

@After

@BeforeClass

@AfterClass

@Ignore

@Test

@Test(timeout=100)

@Mock

@RunWith(MockitoJUnitRunner.class)

assertEquals(Object expecteds, Object actuals)- kiểm tra xem các đối tượng được truyền có bằng nhau hay không.
assertTrue(boolean flag)— kiểm tra xem giá trị được truyền có trả về true hay không.
assertFalse(boolean flag)— kiểm tra xem giá trị đã truyền có trả về sai hay không.
assertNull(Object object)– kiểm tra xem đối tượng có rỗng không.
assertSame(Object firstObject, Object secondObject)— kiểm tra xem các giá trị được truyền có tham chiếu đến cùng một đối tượng hay không.
assertThat(T t, Matcher<T> matcher)- kiểm tra xem t có thỏa mãn điều kiện được chỉ định trong trình so khớp hay không.

assertThat(firstObject).isEqualTo(secondObject)

Thực hành kiểm tra

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <version>2.2.2.RELEASE</version>
   <scope>test</scope>
</dependency>

@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
   private final RobotDAO robotDAO;

   @Override
   public Robot update(Long id, Robot robot) {
       Robot found = robotDAO.findById(id);
       return robotDAO.update(Robot.builder()
               .id(id)
               .name(robot.getName() != null ? robot.getName() : found.getName())
               .cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
               .producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
               .build());
   }
}

@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
   @Mock
   private RobotDAO robotDAO;

   private RobotServiceImpl robotService;

   private static Robot testRobot;

   @BeforeClass
   public static void prepareTestData() {
       testRobot = Robot
               .builder()
               .id(123L)
               .name("testRobotMolly")
               .cpu("Intel Core i7-9700K")
               .producer("China")
               .build();
   }

   @Before
   public void init() {
       robotService = new RobotServiceImpl(robotDAO);
   }

@Test
public void updateTest() {
   when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
   when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
   Robot robotForUpdate = Robot
           .builder()
           .name("Vally")
           .cpu("AMD Ryzen 7 2700X")
           .build();

   Robot resultRobot = robotService.update(123L, robotForUpdate);

   assertNotNull(resultRobot);
   assertSame(resultRobot.getId(),testRobot.getId());
   assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
   assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
   assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}

Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 9

Tất cả về Kiểm thử đơn vị: kỹ thuật, khái niệm, thực hành - 10

Vì vậy, hãy tóm tắt:

Tất cả về Unit testing: phương pháp, khái niệm, thực hành - 11