Sự khác biệt chính đối với tôi là các thử nghiệm tích hợp tiết lộ nếu một tính năng đang hoạt động hoặc bị hỏng, vì chúng nhấn mạnh mã trong một kịch bản gần với thực tế. Họ gọi một hoặc nhiều phương pháp hoặc tính năng phần mềm và kiểm tra nếu chúng hoạt động như mong đợi.
Ngược lại, một bài kiểm tra Đơn vị kiểm tra một phương pháp duy nhất dựa trên giả định (thường sai) rằng phần còn lại của phần mềm đang hoạt động chính xác, bởi vì nó rõ ràng chế giễu mọi phụ thuộc.
Do đó, khi kiểm tra đơn vị cho một phương thức thực hiện một số tính năng có màu xanh lá cây, điều đó không có nghĩa là tính năng này đang hoạt động.
Giả sử bạn có một phương pháp ở đâu đó như thế này:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomethingrất quan trọng đối với khách hàng của bạn: đó là một tính năng, điều duy nhất quan trọng. Đó là lý do tại sao bạn thường viết một đặc tả Cucumber khẳng định nó: bạn muốn xác minh và truyền đạt tính năng này có hoạt động hay không.
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
Không còn nghi ngờ gì nữa: nếu thử nghiệm vượt qua, bạn có thể khẳng định rằng bạn đang cung cấp một tính năng hoạt động. Đây là những gì bạn có thể gọi Giá trị doanh nghiệp .
Nếu bạn muốn viết một bài kiểm tra đơn vị, DoSomethingbạn nên giả vờ (sử dụng một số giả) rằng phần còn lại của các lớp và phương thức đang hoạt động (nghĩa là: tất cả các phụ thuộc mà phương thức đang sử dụng đều hoạt động chính xác) và khẳng định phương thức của bạn đang hoạt động.
Trong thực tế, bạn làm một cái gì đó như:
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
return someResults;
}
Bạn có thể thực hiện việc này với Dependency Injection, hoặc một số Phương thức xuất xưởng hoặc bất kỳ Khung Mock nào hoặc chỉ mở rộng lớp đang thử nghiệm.
Giả sử có một lỗi trong Log.DoSomething(). May mắn thay, thông số Gherkin sẽ tìm thấy nó và các bài kiểm tra đầu cuối của bạn sẽ thất bại.
Tính năng này sẽ không hoạt động, vì Logbị hỏng, không phải vì [Do your job with someInput]không hoạt động. Và, nhân tiện, [Do your job with someInput]là trách nhiệm duy nhất cho phương pháp đó.
Ngoài ra, giả sử Logđược sử dụng trong 100 tính năng khác, trong 100 phương thức khác của 100 lớp khác.
Đúng, 100 tính năng sẽ thất bại. Nhưng, may mắn thay, 100 bài kiểm tra đầu cuối cũng thất bại và tiết lộ vấn đề. Và, vâng: họ đang nói sự thật .
Đó là thông tin rất hữu ích: Tôi biết tôi có một sản phẩm bị hỏng. Đó cũng là thông tin rất khó hiểu: nó không cho tôi biết vấn đề là ở đâu. Nó truyền cho tôi các triệu chứng, không phải là nguyên nhân gốc rễ.
Tuy nhiên, DoSomethingbài kiểm tra đơn vị có màu xanh lá cây, bởi vì nó sử dụng giả Log, được chế tạo để không bao giờ bị hỏng. Và, vâng: rõ ràng là nói dối . Đó là truyền thông một tính năng bị hỏng đang hoạt động. Làm thế nào nó có thể hữu ích?
(Nếu DoSomething()kiểm tra đơn vị của thất bại, hãy chắc chắn: [Do your job with someInput]có một số lỗi.)
Giả sử đây là một hệ thống có lớp bị hỏng:
Một lỗi duy nhất sẽ phá vỡ một số tính năng và một số thử nghiệm tích hợp sẽ thất bại.
Mặt khác, cùng một lỗi sẽ phá vỡ chỉ một bài kiểm tra đơn vị.
Bây giờ, so sánh hai kịch bản.
Các lỗi tương tự sẽ phá vỡ chỉ một bài kiểm tra đơn vị.
- Tất cả các tính năng của bạn sử dụng bị hỏng
Loglà màu đỏ
- Tất cả các bài kiểm tra đơn vị của bạn đều có màu xanh lá cây, chỉ có bài kiểm tra đơn vị cho
Logmàu đỏ
Trên thực tế, các bài kiểm tra đơn vị cho tất cả các mô-đun sử dụng một tính năng bị hỏng có màu xanh lá cây bởi vì, bằng cách sử dụng giả, chúng đã loại bỏ các phụ thuộc. Nói cách khác, họ chạy trong một thế giới lý tưởng, hoàn toàn hư cấu. Và đây là cách duy nhất để cô lập lỗi và tìm kiếm chúng. Kiểm tra đơn vị có nghĩa là chế nhạo. Nếu bạn không chế giễu, bạn không thử nghiệm đơn vị.
Sự khác biệt
Kiểm tra tích hợp cho biết những gì không hoạt động. Nhưng họ không có ích trong việc đoán xem vấn đề có thể ở đâu.
Đơn vị kiểm tra là kiểm tra duy nhất cho bạn biết nơi chính xác lỗi này là. Để rút ra thông tin này, họ phải chạy phương thức trong một môi trường bị chế giễu, trong đó tất cả các phụ thuộc khác được cho là hoạt động chính xác.
Đó là lý do tại sao tôi nghĩ rằng câu của bạn "Hoặc nó chỉ là một bài kiểm tra đơn vị kéo dài 2 lớp" bằng cách nào đó đã bị dịch chuyển. Một bài kiểm tra đơn vị không bao giờ nên kéo dài 2 lớp.
Câu trả lời này về cơ bản là một bản tóm tắt những gì tôi đã viết ở đây: Bài kiểm tra đơn vị nói dối, đó là lý do tại sao tôi yêu chúng .
