2008-10-27 30 views

Trả lời

12

Tôi thường định nghĩa nó là một đường dẫn thực thi mã duy nhất thông qua một phương thức duy nhất. Điều đó xuất phát từ quy tắc ngón tay cái rằng số lượng các bài kiểm tra đơn vị cần thiết để thử nghiệm một phương pháp bằng hoặc lớn hơn số của phương thức cyclomatic complexit y.

1

Chúng tôi xác định 'đơn vị' là một lớp duy nhất.

Khi bạn xác nhận đúng 'đơn vị' là một cụm từ không rõ ràng và điều này dẫn đến nhầm lẫn khi nhà phát triển chỉ sử dụng biểu thức mà không thêm chi tiết. Nơi tôi làm việc, chúng tôi đã dành thời gian để xác định ý nghĩa của chúng tôi khi nói 'kiểm tra đơn vị', 'kiểm tra chấp nhận', v.v. Khi một người mới tham gia nhóm, họ học các định nghĩa mà chúng tôi có.

Từ quan điểm thực tế, có khả năng sẽ luôn có sự khác biệt về ý kiến ​​về 'đơn vị' là gì. Tôi đã thấy rằng điều quan trọng đơn giản là thuật ngữ là sử dụng nhất quán trong ngữ cảnh của một dự án.

+0

Tôi tò mò - một đơn vị trong các mô hình khác là gì? Ví dụ, trong lập trình chức năng, là một đơn vị một chức năng? Trong các chương trình thủ tục, đơn vị sẽ là gì? –

+0

Tôi nghĩ rằng vấn đề là phức tạp bởi thực tế là nhiều công cụ có 'đơn vị' trong tên của họ. Ví dụ, bạn vẫn thường sử dụng jUnit để viết các test cho các tương tác giữa các lớp trong một gói; hoặc toàn bộ một cái bình. Nhưng tôi không coi một gói hoặc một cái lọ như một 'đơn vị'. – johnstok

0

Có thể là những thứ khác nhau. Lớp, Mô-đun, Tệp, ... Chọn mức độ chi tiết mong muốn của bạn về thử nghiệm.

8

Mặc dù định nghĩa có thể khác nhau, một "đơn vị" là một đoạn mã độc lập.

Thông thường, đó là một Lớp duy nhất.

Tuy nhiên, có ít lớp tồn tại trong sự cô lập. Vì vậy, bạn thường phải giả lập các lớp học cộng tác với lớp của bạn đang được kiểm tra.

Do đó, "đơn vị" (còn được gọi là "vật cố định") là một điều có thể kiểm chứng - thường là một lớp cộng với mô hình cho cộng tác viên.

Bạn có thể dễ dàng kiểm tra một gói các lớp liên quan bằng cách sử dụng công nghệ kiểm tra đơn vị. Chúng tôi làm thế này hoài. Có rất ít hoặc không có mocks trong các đồ đạc.

Thực tế, bạn có thể kiểm tra toàn bộ chương trình ứng dụng độc lập dưới dạng "đơn vị" đơn lẻ. Chúng tôi cũng làm điều này. Cung cấp bộ đầu vào và đầu ra cố định để đảm bảo ứng dụng tổng thể hoạt động chính xác.

+1

Tôi không đồng ý (mặc dù tôi không downvoting). Khi bạn kiểm tra toàn bộ lớp hoặc ứng dụng trong một bài kiểm tra, đó là bài kiểm tra tích hợp, không phải là bài kiểm tra đơn vị. Các bài kiểm tra đơn vị nên lý tưởng tương tác với một phương thức duy nhất của một lớp. – tvanfosson

+0

@tvanfosson: chúng tôi sử dụng nhiều chương trình ứng dụng để thực hiện một số quy trình kinh doanh khá lớn. Đối với chúng tôi, thực thi độc lập là "đơn vị" của chúng tôi để kiểm tra cấp độ doanh nghiệp. POV của chúng tôi hơi khác so với POV của bạn. –

6

Đơn vị là bất kỳ phần tử nào có thể được kiểm tra riêng biệt. Do đó, người ta hầu như luôn luôn là phương pháp thử nghiệm trong môi trường OO, và một số hành vi của lớp có sự liên kết chặt chẽ giữa các phương thức của lớp đó.

0

Tôi muốn nói đơn vị là 'hộp đen' có thể được sử dụng trong một ứng dụng. Nó là một cái gì đó có một giao diện được biết đến và cung cấp một kết quả được xác định rõ. Đây là một cái gì đó mà phải làm việc theo một thiết kế-spec và phải được kiểm tra.

Có nói rằng, tôi thường sử dụng kiểm tra đơn vị khi xây dựng các mục trong các hộp đen như vậy như một trợ giúp phát triển.

0

Tôi có thể nói rằng một đơn vị trong thử nghiệm đơn vị là một phần trách nhiệm cho một lớp học.

Tất nhiên ý kiến ​​này xuất phát từ cách chúng ta làm việc:

Trong đội của tôi, chúng tôi sử dụng các bài kiểm tra đơn vị hạn cho các bài kiểm tra mà chúng tôi kiểm tra trách nhiệm của một lớp duy nhất. Chúng tôi sử dụng các đối tượng giả để trang trải cho tất cả các đối tượng khác để các trách nhiệm của lớp được thực sự cô lập và không bị ảnh hưởng nếu các đối tượng khác có lỗi trong chúng.

Chúng tôi sử dụng thử nghiệm tích hợp cụm từ cho các bài kiểm tra nơi chúng tôi kiểm tra cách hai hoặc nhiều lớp đang hoạt động cùng nhau, để chúng tôi thấy rằng chức năng thực tế có ở đó. Cuối cùng, chúng tôi giúp khách hàng của chúng tôi viết các bài kiểm tra chấp nhận, hoạt động trên toàn bộ ứng dụng để xem điều gì thực sự xảy ra khi một "người dùng" đang làm việc với ứng dụng. Các tính năng chính:

Đây là điều khiến tôi nghĩ đó là mô tả hay.

1

Tôi làm việc 'đơn vị' là một chức năng. Đó là bởi vì chúng tôi không được phép sử dụng bất kỳ thứ gì ngoài phân tích chức năng trong thiết kế của chúng tôi (không có OOP). Tôi đồng ý 100% với câu trả lời của Will. Ít nhất đó là câu trả lời của tôi trong khuôn khổ công việc của tôi trong lập trình nhúng cho động cơ và điều khiển bay và nhiều hệ thống khác.

2

Theo kinh nghiệm của tôi, cuộc tranh luận về "đơn vị là gì" là một sự lãng phí thời gian.

Điều quan trọng hơn nhiều là "thử nghiệm nhanh như thế nào?" Kiểm tra nhanh chạy với tốc độ 100 +/giây. Các xét nghiệm chậm chạy đủ chậm mà bạn không theo dõi phản xạ mỗi lần bạn dừng lại để suy nghĩ.

Nếu thử nghiệm của bạn chậm, bạn sẽ không chạy chúng thường xuyên, làm cho thời gian giữa tiêm lỗi và phát hiện lỗi lâu hơn.

Nếu kiểm tra của bạn chậm, có thể bạn không nhận được lợi ích thiết kế của thử nghiệm đơn vị.

Muốn thử nghiệm nhanh? Theo dõi của Michael Feather rules of unit testing.

Nhưng nếu các bài kiểm tra của bạn nhanh và chúng giúp bạn viết mã của bạn, ai quan tâm đến nhãn họ có?

0

Sự hiểu biết của tôi (hoặc lý do) là các đơn vị phải tuân theo một hệ thống phân cấp trừu tượng và phạm vi tương tự như sự phân hủy phân cấp của mã của bạn.

Một phương pháp là một nhỏ và thường nguyên tử (theo lý thuyết) hoạt động ở mức thấp trừu tượng, vì vậy nó cần được kiểm tra

Một lớp học là một khái niệm giữa mức cung cấp dịch vụ và các quốc gia và do đó cần được kiểm tra .

Cả mô-đun (đặc biệt là nếu thành phần của nó được ẩn) là một khái niệm cao cấp với một giao diện hạn chế, vì vậy nó cần được kiểm tra, vv

Vì nhiều lỗi phát sinh từ sự tương tác giữa nhiều phương pháp và các lớp học , Tôi không thấy đơn vị thử nghiệm chỉ các phương thức riêng lẻ có thể đạt được mức độ bao phủ cho đến khi bạn đã có các phương thức sử dụng mọi kết hợp quan trọng, nhưng điều đó sẽ chỉ ra rằng bạn không kiểm tra đủ trước khi viết mã máy khách.

0

Điều đó không quan trọng. Tất nhiên nó là bình thường bạn yêu cầu để bắt đầu thử nghiệm đơn vị, nhưng tôi lặp lại nó, nó không quan trọng.

Các đơn vị là một cái gì đó dọc theo dòng:

  • phương pháp gọi bởi các thử nghiệm. Trong OOP, phương thức này đã được gọi trên một cá thể của một lớp (ngoại trừ các phương thức tĩnh)
  • một hàm bằng các ngôn ngữ thủ tục.

Nhưng, các "đơn vị", chức năng hoặc phương pháp, cũng có thể gọi một "đơn vị" từ các ứng dụng, mà là tương tự như vậy thực hiện bởi các thử nghiệm. Vì vậy, "đơn vị" có thể mở rộng trên nhiều chức năng hoặc thậm chí một số lớp.

"Kiểm tra quan trọng hơn đơn vị" (testivus). Một thử nghiệm tốt sẽ là:

  • tự động - thực hiện và chẩn đoán
  • nhanh - bạn sẽ chạy chúng rất thường xuyên
  • nguyên tử - một bài kiểm tra có trách nhiệm kiểm tra chỉ có một điều
  • Isolated - kiểm tra sẽ không phụ thuộc vào nhau
  • lặp lại - kết quả sẽ được xác định
Các vấn đề liên quan