Kiểm tra đơn vị là gì?

Xin chào mọi người, chúng tôi đã viết một bài báo nhỏ về kinh nghiệm của chúng tôi trong Thử nghiệm đơn vị với đồng đội của tôi Berkin Ergürbüz .

Chúc mọi người đọc truyện vui vẻ

Kiểm tra đơn vị là một phương pháp xác minh hành vi của đơn vị phần mềm nhỏ nhất có thể kiểm tra được bằng cách chạy nó tách biệt với tất cả các phần phụ thuộc của nó. Các bài kiểm tra đơn vị cho phép chúng tôi xác minh hành vi của mã chúng tôi viết bằng cách viết lại mã.Vì đây là phần nhỏ nhất có thể kiểm tra được của phần mềm nên các bài kiểm tra đơn vị được phát triển bởi các nhà phát triển phần mềm.

TDD LÀ GÌ?

Test Driven Development là một thực tế mà chúng ta đã nghe thấy thường xuyên trong những năm gần đây và đã bắt đầu trở nên phổ biến. Về cơ bản những gì nó nói là bài kiểm tra phải được viết trước khi viết mã ứng dụng.

Tại sao chúng ta viết bài kiểm tra đơn vị và nó mang lại cho chúng ta điều gì?

Có thể viết bài kiểm tra đơn vị có nhiều lợi thế, chúng tôi sẽ cố gắng nói về chúng.

Phát triển theo cách tiếp cận TDD yêu cầu xem xét kỹ lưỡng các yêu cầu hoặc thiết kế trước khi viết bất kỳ mã chức năng nào. Chúng tôi bắt đầu phát triển bằng cách viết các bài kiểm tra đơn vị. Quá trình này sẽ khiến chúng tôi phải suy nghĩ nhiều hơn về tính năng mà chúng tôi sẽ phát triển và sẽ cho phép chúng tôi chỉ tập trung vào các yêu cầu. Bắt đầu viết mã trực tiếp có thể khiến chúng ta khó tập trung hơn một chút vào thiết kế và dòng mã trong khi phát triển. Quá trình này sẽ giúp chúng tôi mắc ít lỗi hơn và viết mã đơn giản và rõ ràng hơn bằng cách chỉ tập trung vào các yêu cầu.

Một trong những lợi ích của việc trở thành người viết bài kiểm tra đơn vị là có thể nhận thấy các lỗi có thể xảy ra trong giai đoạn phát triển và có cơ hội sửa các lỗi này. Thời gian giữa thời điểm xảy ra lỗi và phát hiện lỗi càng lâu thì chi phí giải quyết lỗi càng cao. Kiểm tra đơn vị sẽ giúp chúng tôi ngăn chi phí này tăng lên.

Phần mềm của chúng tôi có cấu trúc liên tục phát triển và thay đổi.Vì lý do này, chúng tôi sẽ cần thực hiện các thay đổi trong các phương thức mà chúng tôi đã viết. Nếu các cải tiến hoặc thay đổi được thực hiện gây ra lỗi không mong muốn, thì lỗi này sẽ bị phát hiện bởi các thử nghiệm mà chúng tôi đã viết cho mã này trước đó và chúng tôi có thể nhận ra tình huống này trong giai đoạn phát triển và thực hiện hành động cần thiết. Khi chúng tôi thêm một tính năng mới vào một lớp có các bài kiểm tra được viết, chúng tôi thường tập trung vào các bài kiểm tra tính năng được thêm vào. Ngay cả khi tính năng mới này hoạt động bình thường, nó có thể khiến lớp này không hoàn thành một tính năng mà nó có thể thực hiện ở trạng thái hiện tại. Không phải lúc nào chúng ta cũng có thể kiểm tra các trường hợp được xác định trước. Trong những trường hợp như vậy, việc viết trước các bài kiểm tra tính năng hiện có sẽ bảo vệ khỏi các lỗi không mong muốn hoặc bị bỏ qua.

Mọi tính năng được thêm vào đều khiến các bài kiểm tra đơn vị hiện tại của chúng tôi không thành công và nếu chúng tôi cần sắp xếp lại các bài kiểm tra đơn vị này, trên thực tế, chữ " O" của các nguyên tắc RẮN, nghĩa là , phương pháp của chúng tôi mở để phát triển và đi ngược lại nguyên tắc tồn tại đóng cửa để thay đổi.

Viết bài kiểm tra đơn vị khuyến khích giảm độ phức tạp của mã và viết mã chất lượng tốt hơn. Sẽ rất khó để viết các bài kiểm tra các phương thức phức tạp và chứa nhiều logic.

Để viết mã có thể kiểm tra, nó sẽ cho phép chúng tôi viết mã của mình theo các phương thức nhỏ hơn và chỉ với một tác vụ trong mỗi phương thức. Theo thời gian, những cách tiếp cận này sẽ cho phép chúng tôi tạo ra văn hóa phát triển phần mềm cho chúng tôi.

Trong khi chúng tôi đang kiểm tra mã của mình, chúng tôi cần cách ly hoàn toàn với các phụ thuộc bên ngoài vì đối tượng chúng tôi quan tâm là mã trong đơn vị mà chúng tôi muốn kiểm tra. Chúng tôi không quan tâm đến hành vi của các phụ thuộc bên ngoài. Nhu cầu kiểm tra độc lập và tách biệt với các đoạn mã mà các đơn vị mà chúng tôi đang kiểm tra phụ thuộc vào cho phép chúng tôi trừu tượng hóa các đơn vị này và thiết kế mã thành các phần nhỏ có thể tái sử dụng. Như một ví dụ về các phụ thuộc bên ngoài; phương thức, điểm cuối nguồn bên ngoài, v.v.

Bằng cách viết mã có thể kiểm tra, chúng tôi thực sự bắt đầu áp dụng các nguyên tắc RẮN nhiều hơn.

Làm thế nào để chúng tôi viết một bài kiểm tra đơn vị?

Các giai đoạn trong cách tiếp cận TDD như sau;

1. Bài kiểm tra được phát triển.

2. Thử nghiệm thất bại.

3. Mã hóa được thực hiện để thử nghiệm thành công.

4. Thử nghiệm thành công.

5. Mã được cấu trúc lại.

Trước khi bắt đầu các bước này, cần phải khai báo các lớp và phương thức mà chúng ta sẽ viết bài kiểm tra. Trước tiên chúng ta phải viết bài kiểm tra các phương thức, sau đó thấy rằng bài kiểm tra này không thành công, viết mã phương thức có liên quan và tiếp tục quá trình sau khi bài kiểm tra thành công.

Sau khi hoàn thành các quy trình này cho các phương pháp hiện có của chúng tôi, chúng tôi sẽ chạy tất cả các thử nghiệm của mình và hy vọng các phương pháp thử nghiệm của chúng tôi sẽ hoạt động thành công. Sự phát triển của chúng tôi để một phương pháp thử nghiệm thành công có thể khiến các thử nghiệm khác thất bại. Trong trường hợp này, bằng cách tái cấu trúc mã, chúng tôi hoàn tất quy trình sau khi kiểm tra lại thành công.

Ngoài cách tiếp cận TDD, chúng tôi bắt đầu viết sau khi viết phương pháp kiểm tra đơn vị trong quy trình phát triển phần mềm truyền thống.

Tóm tắt;

Vào cuối ngày, điểm kiểm tra đơn vị không nên chỉ nói rằng chúng tôi có các bài kiểm tra đơn vị trong dự án của mình. Viết các phương pháp kiểm tra đơn vị thực sự phục vụ mục đích của nó sẽ mang lại cho chúng ta rất nhiều lợi ích. Do đó, bằng cách cố gắng viết mã có thể kiểm tra, chúng tôi sẽ có văn hóa phát triển mã chất lượng tốt hơn. Nó sẽ phục vụ để phát hiện lỗi ở giai đoạn sớm nhất bằng cách dự đoán mức độ ảnh hưởng của một cải tiến trong mã của chúng ta đến các hành vi khác và nơi chúng ta có thể gặp lỗi.

Trong bài viết tiếp theo của chúng tôi, chúng tôi sẽ cố gắng giải thích cách chúng tôi phát triển các phương pháp kiểm tra đơn vị và ví dụ về các quy trình liên quan. Hẹn gặp lại

địa chỉ e-mail của chúng tôi cho tất cả các đề xuất và phản hồi của bạn;

Berkin — [email protected] Fatmagul — [email protected]

Bản tiếng Anh của bài viết:

https:///@berkinergurbz/what-is-the-unit-test-4bc4178cdd30