Khi nào nên sử dụng tập lệnh thử nghiệm trên thử nghiệm đơn vị?

Question

Tôi hiện đang làm việc trên một dự án đã được sản xuất trong hơn hai năm. Dự án sử dụng rộng rãi thử nghiệm đơn vị và kiểm tra giao diện người dùng theo kịch bản. Các bài kiểm tra đơn vị sơ khởi bao gồm khung hệ thống, các quy tắc nghiệp vụ và các quá trình chuyển đổi trạng thái (hoặc quy trình làm việc). Kịch bản thử nghiệm được sử dụng để thử nghiệm hộp đen. Tuy nhiên, theo thời gian, chi phí duy trì toàn bộ các bài kiểm tra đơn vị của chúng tôi đã trở nên ngày càng đắt đỏ, đặc biệt là những người liên quan đến tiểu bang.

Sau một số điều tra, chúng tôi thấy rằng các tập lệnh thử nghiệm có hiệu quả hơn (có nghĩa là cung cấp mức độ phù hợp tốt hơn) và rẻ hơn để duy trì hơn các bài kiểm tra đơn vị liên quan đến quy trình làm việc. Đây không phải là để nói rằng giá trị của các bài kiểm tra đơn vị đã được hoàn toàn phủ nhận nhưng nó làm tăng câu hỏi này cho dù một số lớp học của các bài kiểm tra đơn vị có thể được giảm trong lợi của kịch bản thử nghiệm.

Dự án của chúng tôi được chạy trên mô hình gia tăng lặp lại.

Answer 1

Một trong những câu trả lời về SO đối với câu hỏi 'giới hạn của kiểm tra đơn vị' là việc kiểm tra đơn vị trở nên phức tạp khi được sử dụng để kiểm tra bất kỳ điều gì liên quan đến INTEGRATION thay vì chức năng. Kết nối và sử dụng các dịch vụ bên ngoài (cơ sở dữ liệu, SSH'ing đến một máy chủ khác, vv) và Giao diện người dùng là hai trong số các ví dụ được sử dụng. Nó không phải là bạn CANT sử dụng thử nghiệm đơn vị cho những điều này, nó chỉ là khó khăn liên quan đến bao gồm tất cả các căn cứ làm cho bằng cách sử dụng phương pháp thử nghiệm này không có giá trị nó ngoại trừ trong trường hợp độ tin cậy là tối quan trọng.

Tôi sử dụng "kiểm tra tập lệnh" cho tất cả mã UI JavaScript tùy chỉnh của tôi (công cụ mẫu, hiệu ứng và hoạt ảnh, v.v.) và tôi thấy nó nhanh chóng và đáng tin cậy nếu được thực hiện đúng.

Answer 2

Hai điều khác nhau

• Unit Tests - Developer - xác minh xem mã là đúng
• nghiệm thu - Khách hàng/QA/BA - xác minh rằng mã đúng được phát triển.

Hai danh mục phải khác biệt và cả hai đều đóng vai trò quan trọng không kém .. Việc bỏ một danh mục không thể hiện tốt. Kịch bản thử nghiệm như bạn đã đề cập rơi vào thể loại thứ hai. Tôi muốn giới thiệu một cái gì đó như FIT/Fitnesse cho mục đích này. Nếu điều đó là không khả thi, thì các công cụ kiểu tập lệnh thử nghiệm/ghi lại phát lại. Nhưng đừng vứt bỏ các bài kiểm tra đơn vị tốt .. ý bạn là gì khi 'chi phí duy trì kiểm tra trở nên đắt đỏ'?

Answer 3

Bạn thường sử dụng Kiểm tra đơn vị để thực hiện chính xác điều này: các đơn vị thử nghiệm. Chính xác hơn, để kiểm tra xem một đơn vị có tuân theo đặc điểm/hợp đồng giao diện của nó hay không. Nếu kiểm tra đơn vị không thành công, bạn biết chính xác vị trí của sự cố: nó nằm trong đơn vị được kiểm tra. Điều này làm cho nó dễ dàng hơn để gỡ lỗi, đặc biệt là kể từ khi kết quả của một bài kiểm tra đơn vị có thể được xử lý tự động. Tự động kiểm tra hồi quy đến tâm trí ở đây.

Bạn bắt đầu sử dụng kiểm tra giao diện người dùng theo kịch bản nếu bạn muốn rời khỏi phạm vi kiểm tra đơn vị hoặc muốn kiểm tra những thứ không thể kiểm tra tốt với các bài kiểm tra đơn vị. Ví dụ. khi bạn kiểm tra mã giao diện với nhiều API bên ngoài mà bạn không thể giả lập. Bây giờ bạn có thể kích động một số lỗi nhất định nhưng theo dõi chính xác nơi mà mã lỗi được chôn là khó khăn hơn nhiều.

Answer 4

Thực ra, có bốn cấp độ kiểm tra, 3 trong số đó có thể liên quan đến tập lệnh, lệnh đầu tiên không có.

thử nghiệm
• đơn vị: thử nghiệm một lớp học hoặc phương pháp trong sự cô lập hoàn toàn với phần còn lại của hệ thống
• thử nghiệm lắp ráp: thử nghiệm một kịch bản trong hệ thống trong sự cô lập hoàn toàn từ các thành phần khác bên ngoài vào hệ thống (có nghĩa là từ một miền chức năng khác)
• kiểm tra tích hợp: kiểm tra hệ thống bao gồm các yếu tố đầu vào đến từ phần bên ngoài và đầu ra đi tới hệ thống bên ngoài khác (từ các miền chức năng khác).
• kiểm tra chấp nhận: xác thực cuối cùng, như Gishu, để kiểm tra mã đúng (đó là các tính năng phù hợp) có ở đó.

Ví dụ về miền chức năng: Service Layer Bus, đó là tất cả các dự án (thường gói gọn một số cơ sở dữ liệu tham chiếu chính) có thể hiển thị dịch vụ của chúng trên xe buýt.
Bạn có thể làm:

• các unit test cho lớp xuất bản của bạn
• kiểm tra lắp ráp cho cơ chế xuất bản của mình phối hợp với các thành phần khác của SLB
• thử nghiệm hội nhập cho bạn dịch vụ SLB và các thành phần khác được phát triển bên ngoài SLB và khách hàng của các dịch vụ của bạn
• kiểm tra chấp nhận cho toàn bộ hệ thống.

Như đã nói, 3 loại kiểm tra cuối cùng có thể liên quan đến tập lệnh nặng và có thể nhanh chóng bao gồm nhiều mã của bạn hơn. Tùy thuộc vào số lượng tuyệt đối của các lớp/phương pháp để kiểm tra đơn vị, một bài kiểm tra lắp ráp tốt có thể là một cách tiếp cận tốt hơn.

Answer 5

Trong nhiều cách khác nhau, tôi đã trải qua cùng một loại đau mà bạn có xét nghiệm đơn vị vis-a-vis, đặc biệt là trong các dự án mà các thành viên không hề nhiệt tình về kiểm tra đơn vị và nhiều người trong số họ đơn giản bỏ qua hoặc bình luận kiểm tra-ra để có thể gian lận kiểm soát nguồn, tiết kiệm thời gian, vv Một cựu đồng nghiệp thậm chí đặt ra thuật ngữ "Hạn chế phát triển Driven" cho việc này.

Theo ý kiến ​​của tôi khi phải đối mặt với loại thách thức, sau đây là một số hướng dẫn vis-a-vis kiểm tra đơn vị:

• Huỷ kiểm tra lỗi thời - Đôi khi nó là vô nghĩa trong cố gắng cập nhật hàng trăm đến hàng ngàn của các dòng kiểm tra nếu chúng, về bản chất, không chính xác hoặc không liên quan. Hủy kiểm tra ngay lập tức. Đừng "Bỏ qua" chúng, đừng bình luận chúng. Xóa chúng hoàn toàn.
• Viết thử nghiệm cho chức năng mới - Bất kỳ chức năng mới nào vẫn cần phải được kiểm tra đơn vị và được viết theo cách có thể kiểm tra đơn vị.
• Viết kiểm tra để sửa lỗi - Khi hồi quy kiểm tra ứng dụng, nó có thể có liên quan để đảm bảo rằng các bản sửa lỗi có các bài kiểm tra đơn vị đảm bảo rằng lỗi đã được sửa.
• Đến địa ngục có mã vùng - Điều này có thể kiếm được một số lợi ích nhỏ, tôi chắc chắn, nhưng there is a fine line between ensuring functionality and using tests as an excuse to delay work. Trọng tâm phải đảm bảo chức năng cốt lõi hơn sau bất kỳ tỷ lệ bao phủ mã tùy ý nào.

Điều đó đang được nói, tôi vẫn nghĩ rằng thử nghiệm đơn vị không nên bị loại bỏ hoàn toàn. Kịch bản thử nghiệm và kiểm tra đơn vị có mục đích riêng của họ.Nhưng một sự cân bằng nên được đánh giữa một nỗ lực quá nhiệt tình để duy trì TDD và đối mặt với thực tế phát triển ứng dụng doanh nghiệp.

Answer 6

Giả định của tôi là nỗ lực duy trì cho các bài kiểm tra đơn vị của bạn tăng lên vì kiến ​​trúc của ứng dụng của bạn đã được phép tách rời. Vì không ai nhưng bạn thực sự biết những gì trong mã của bạn, bạn có thể muốn áp dụng phương pháp năm whys để quyết định vấn đề gốc, thực, cốt lõi của bạn là gì. Các bài kiểm tra đơn vị IME sẽ không bao giờ tốn kém để duy trì, miễn là bạn sử dụng kiến ​​trúc dựa trên giao diện được tách riêng, có độ phân giải cao.