Có hai lý do để viết bài kiểm tra:
- Khẳng định hành vi mong đợi
- Ngăn chặn sự thoái lui của hành vi
Thực hiện (1) Khẳng định hành vi mong đợi:
Khi bạn đang xác nhận hành vi mong đợi, bạn muốn đảm bảo mã hoạt động như bạn nghĩ. Đây thực sự là một cách tự động để thực hiện xác minh thủ công thông thường của bạn mà bất kỳ nhà phát triển nào cũng sẽ thực hiện khi triển khai bất kỳ loại mã nào:
- Những gì tôi vừa viết có hoạt động không?
- Vòng lặp này có thực sự kết thúc không?
- Nó có lặp lại theo thứ tự tôi nghĩ không?
- Điều này sẽ hoạt động cho một đầu vào rỗng?
Đó là những câu hỏi mà tất cả chúng ta đều trả lời trong đầu và thông thường, chúng ta cũng sẽ cố gắng thực thi mã trong đầu, đảm bảo rằng nó có vẻ hoạt động. Đối với những trường hợp này, việc yêu cầu máy tính trả lời chúng một cách dứt khoát sẽ rất hữu ích. Vì vậy, chúng tôi viết một bài kiểm tra đơn vị để khẳng định rằng nó có. Điều này mang lại cho chúng tôi niềm tin vào mã của mình, giúp chúng tôi tìm ra các khiếm khuyết sớm và thậm chí có thể giúp thực sự triển khai mã.
Bạn nên làm điều này ở bất cứ đâu bạn cảm thấy cần thiết. Bất kỳ mã nào khó hiểu một chút hoặc không tầm thường. Ngay cả những đoạn mã tầm thường cũng có thể được hưởng lợi từ nó. Tất cả là về sự tự tin của chính bạn. Bao lâu để làm điều đó và đi bao xa sẽ phụ thuộc vào sự hài lòng của chính bạn. Dừng lại khi bạn có thể tự tin trả lời Có với: Bạn có chắc điều này hiệu quả không?
Đối với loại thử nghiệm này, bạn không quan tâm đến khả năng hiển thị, giao diện hoặc bất kỳ thứ gì khác, bạn chỉ quan tâm đến việc có mã hoạt động. Vì vậy, có, bạn sẽ thử nghiệm các phương pháp riêng tư và được bảo vệ nếu bạn cảm thấy chúng cần được kiểm tra để bạn trả lời Có cho câu hỏi.
Thực hiện (2) Ngăn chặn sự thoái lui của hành vi:
Khi bạn đã có mã hoạt động, bạn cần phải có một cơ chế để bảo vệ mã này khỏi bị hư hại trong tương lai. Nếu không ai chạm vào nguồn và cấu hình của bạn một lần nữa, bạn sẽ không cần điều này, nhưng trong hầu hết các trường hợp, bạn hoặc những người khác sẽ chạm vào nguồn và cấu hình phần mềm của bạn. Lỗi nội bộ này rất có thể phá vỡ mã làm việc của bạn.
Các cơ chế tồn tại trong hầu hết các ngôn ngữ như một cách để bảo vệ khỏi thiệt hại này. Các tính năng hiển thị là một cơ chế. Một phương pháp riêng tư bị cô lập và ẩn. Đóng gói là một cơ chế khác, nơi bạn chia ngăn mọi thứ để việc thay đổi ngăn khác không ảnh hưởng đến những thứ khác.
Cơ chế chung cho điều này được gọi là: mã hóa đến ranh giới. Bằng cách tạo ranh giới giữa các phần của mã, bạn bảo vệ mọi thứ bên trong một ranh giới khỏi những thứ bên ngoài nó. Các ranh giới trở thành điểm tương tác và hợp đồng mà mọi thứ tương tác với nhau.
Điều này có nghĩa là những thay đổi đối với một ranh giới, bằng cách phá vỡ giao diện của nó hoặc phá vỡ hành vi mong đợi của nó, sẽ làm hỏng và có thể phá vỡ các ranh giới khác dựa vào nó. Đó là lý do tại sao bạn nên có một bài kiểm tra đơn vị, nhắm mục tiêu các ranh giới đó và khẳng định chúng không thay đổi về ngữ nghĩa và hành vi.
Đây là bài kiểm tra đơn vị điển hình của bạn, bài kiểm tra mà hầu hết mọi người đều nói đến khi nhắc đến TDD hoặc BDD. Mục đích là để làm cứng các ranh giới và bảo vệ chúng khỏi sự thay đổi. Bạn không muốn thử nghiệm các phương pháp riêng tư cho việc này, bởi vì phương pháp riêng tư không phải là một ranh giới. Các phương pháp được bảo vệ là một ranh giới hạn chế và tôi sẽ bảo vệ chúng. Chúng không tiếp xúc với thế giới, nhưng vẫn tiếp xúc với các ngăn hoặc "Đơn vị" khác.
Phải làm gì với điều này?
Như chúng ta đã thấy, có một lý do chính đáng để kiểm tra đơn vị các phương pháp công khai và được bảo vệ, vì để khẳng định rằng các giao diện của chúng ta không thay đổi. Và cũng có lý do chính đáng để thử nghiệm các phương pháp riêng tư, để khẳng định rằng việc triển khai của chúng tôi hoạt động hiệu quả. Vì vậy, chúng ta nên đơn vị kiểm tra tất cả chúng?
Có và không.
Đầu tiên : Kiểm tra tất cả các phương pháp mà bạn cảm thấy cần có bằng chứng xác thực rằng nó hoạt động trong hầu hết các trường hợp để có thể tự tin rằng mã của bạn hoạt động, bất kể mức độ hiển thị. Sau đó, vô hiệu hóa các kiểm tra đó. Họ đã hoàn thành công việc ở đó.
Cuối cùng : Viết các bài kiểm tra cho ranh giới của bạn. Có một bài kiểm tra đơn vị cho mỗi điểm sẽ được sử dụng bởi các đơn vị khác trong hệ thống của bạn. Đảm bảo rằng kiểm tra này khẳng định hợp đồng ngữ nghĩa, tên phương thức, số lượng đối số, v.v. Và cũng đảm bảo kiểm tra xác nhận hành vi có sẵn của đơn vị. Bài kiểm tra của bạn phải chứng minh cách sử dụng thiết bị và những gì thiết bị có thể làm. Giữ cho các thử nghiệm này được bật để chúng chạy trên mọi lần đẩy mã.
LƯU Ý: Lý do bạn tắt bộ kiểm tra đầu tiên là để cho phép công việc tái cấu trúc xảy ra. Kiểm tra hoạt động là một khớp nối mã. Nó ngăn chặn việc sửa đổi mã mà nó đang thử nghiệm trong tương lai. Bạn chỉ muốn điều này cho các giao diện và hợp đồng tương tác của mình.