Tại sao bạn lại viết bài kiểm tra đơn vị cho bộ điều khiển?


22

Đối với tôi đây là một bài kiểm tra đơn vị hoàn toàn không liên quan và tôi không hiểu tại sao ai đó lại dành thời gian để viết nó, vì có rất ít giá trị để đạt được từ nó. Tôi sẽ biết rất rõ nếu bộ điều khiển này trả về kiểu mong muốn bằng cách thực thi phương thức trong trình duyệt. Thực sự, bạn có tin rằng một bài kiểm tra là cần thiết cho việc này và tại sao?

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}


7
Đừng đồng ý với điều đó @gnat. Đây không phải là về cấu trúc ngôn ngữ nhất thiết mà là về loại kết quả được trả về bởi bộ điều khiển. Mặc dù nó có thể sôi sục với cùng một thứ khi bạn không có hệ thống phân cấp thừa kế, nó trở thành một con thú hoàn toàn khác khi người điều khiển mong đợi Tổ tiên được trả về, Người điều khiển trả về Người và bây giờ Người được thay đổi không phải từ Tổ tiên, mà là PeopleAncestor ... Cũng trả lời tại sao thử nghiệm một phương pháp như vậy có thể là một ý tưởng tốt ...;) Các thử nghiệm đơn vị có nghĩa là để xử lý các tình huống trong đó một sự thay đổi trong một điều c / sẽ phá vỡ một thứ khác.
Marjan Venema


Có xu hướng đồng ý, tôi thường không dành nhiều thời gian để kiểm tra các điểm vào của ứng dụng. Nó giống như đơn vị thử nghiệm một phương pháp chính của ứng dụng console. chỉ làm cho rất ít ý nghĩa với tôi.
Mvision

Câu trả lời:


29

Điểm chính của họ là ở đây:

Tôi sẽ biết rất rõ nếu bộ điều khiển này trả về kiểu mong muốn bằng cách thực thi phương thức trong trình duyệt

Đơn vị là về tự động hóa kiểm thử không hồi quy đơn vị mã đơn giản, không phải là bạn tự nhìn. Bạn không muốn làm cho mình luôn luôn đơn vị trong ứng dụng của bạn.

EDIT: Thêm bình luận @anotherdave:

Đó là về dễ dàng mở rộng quy mô. Kiểm tra một bộ điều khiển trong trình duyệt có thể ổn; Điều gì về 10, 20, 50 bộ điều khiển? Bạn sẽ viết bài kiểm tra một lần; bạn có thể cần cập nhật nó khi bạn thay đổi bộ điều khiển, đó là chi phí hoạt động. Nhưng bạn có thường xuyên triển khai không? Chắc chắn một kiểm tra thủ công mỗi lần có nhiều chi phí hơn mà bài kiểm tra

Thay thế cho câu trả lời của @ Vladislav , kiểm tra đơn vị hoàn toàn mọi thứ có thể là quá mức cần thiết và thực sự không mong muốn. Nếu bạn cần thứ gì đó nhẹ hơn, bạn có thể thực hiện kiểm tra không hồi quy cấp cao hơn bằng Selenium. Chắc chắn bạn sẽ nhận được bảo hiểm ít hơn so với thử nghiệm đơn vị, nhưng bạn có thể có được phạm vi bảo hiểm có thể loại bỏ được mà tốn ít thời gian hơn khi thử nghiệm đơn vị và linh hoạt hơn.

Đó là, nếu bạn kiểm tra đơn vị mọi thứ bạn phải cập nhật một hoặc nhiều bài kiểm tra mỗi lần bạn sửa đổi một yếu tố đơn giản.


4
Ngoài ra để thêm lại: I would know perfectly well if this controller returned the wanted type by executing the method in a browser.- đó là về dễ dàng mở rộng quy mô. Kiểm tra một bộ điều khiển trong trình duyệt có thể ổn; Điều gì về 10, 20, 50 bộ điều khiển? Bạn sẽ viết bài kiểm tra một lần; bạn có thể cần cập nhật nó khi bạn thay đổi bộ điều khiển, đó là chi phí hoạt động. Nhưng bạn có thường xuyên triển khai không? Chắc chắn một kiểm tra thủ công mỗi lần có nhiều chi phí mà bài kiểm tra.
một

"Đơn vị là về tự động hóa" - Chính xác, tuy nhiên, thử nghiệm tích hợp (Selenium / Webdo / v.v.) cũng vậy. Tôi không nghĩ rằng nó nhất thiết phải cắt và làm khô để các bài kiểm tra đơn vị thực hiện nhanh hơn các bài kiểm tra tích hợp. Rất nhiều phụ thuộc vào cách tiếp cận, tuy nhiên nếu việc kiểm tra đơn vị hiệu quả đòi hỏi phải loại bỏ hàng tá dịch vụ và cuộc gọi khác nhau được thực hiện, thì một thử nghiệm tích hợp có thể được thực hiện nhanh hơn và duy trì đơn giản hơn (mặc dù chạy chậm hơn nhiều, vâng) . Điểm là, rất nhiều phụ thuộc vào bối cảnh và độ phức tạp của mã được thử nghiệm.
aroth

@anotherdave đã thêm nhận xét
Walfrat

@aroth quan điểm của tôi là ngược lại, kiểm tra đơn vị đầy đủ một mã là một việc mất rất nhiều thời gian và làm cho mã rất khó thay đổi mà không có một số kiểm tra đơn vị để thay đổi. Kiểm tra tích hợp là nhẹ hơn. Tất nhiên bạn muốn kiểm tra đơn vị một cái gì đó rất phức tạp, nhưng không phải vì đơn vị bạn đã kiểm tra phần đó, mà bạn phải kiểm tra mọi thứ. Một lần nữa chúng ta lại thấy những người tìm kiếm viên đạn bạc nơi anh ta không tồn tại.
Walfrat

24

Tại sao bạn lại viết bài kiểm tra đơn vị cho bộ điều khiển?

Bởi vì không biết bối cảnh bạn không thể nói chắc chắn nếu bạn cần kiểm tra cái này hay cái kia. Dưới đây là một số lý do, tại sao bạn có thể muốn kiểm tra bộ điều khiển:

  • bộ điều khiển có thể chứa logic nối dây dịch vụ phức tạp, dễ bị lỗi. Bản thân các dịch vụ có thể hoạt động tốt, đó là kết quả mà bạn muốn kiểm tra và vì một số lý do bạn cho rằng không giới thiệu lớp điều phối vào ứng dụng của mình
  • bộ điều khiển của bạn chứa logic kinh doanh WHOLE của ứng dụng và bộ điều khiển thực sự là tất cả những gì bạn CÓ THỂ kiểm tra (xin đừng giả vờ rằng cả đời bạn đã làm việc với các cơ sở mã lý tưởng, có những cơ sở mã như vậy, tin tôi đi)
  • nhóm của bạn bao gồm 99% thiên tài và 1% người bình thường và bạn muốn giữ 1% đó khỏi lỗi trong lương của họ

2
Tôi sẽ nói thêm: "Bạn không thể biết trước ai trong tương lai sẽ thoát khỏi dự án và các bài kiểm tra là một phần của mã tự ghi"
Laiv

4
Đến điểm giữa, một dự án được tạo mà không có kiểm tra trong tâm trí có thể không thể kiểm tra được bằng bất kỳ cách nào khác ngoài kiểm tra bộ điều khiển không có giả. Tôi làm việc với nhóm C # có chính xác một dự án như vậy, vì vậy họ đang viết các bài kiểm tra bộ điều khiển cho đến khi họ có thể thêm cấu trúc cần thiết (giao diện, v.v.) để có thể kiểm tra chi tiết hơn.
Wayne Conrad

1

Tôi hoàn toàn đồng ý với OP.

Một bài kiểm tra đơn vị cho một bộ điều khiển là vô nghĩa. Bạn kiểm tra bộ điều khiển của mình hoàn toàn thông qua các bài kiểm tra hồi quy (ví dụ sử dụng Selenium).

Bạn nên TDD tất cả các thành phần / đối tượng mà bộ điều khiển sử dụng và giữ cho bộ điều khiển càng mỏng càng tốt. Sau đó, tất cả mọi thứ là đơn vị thử nghiệm đúng. Điều bạn muốn chắc chắn là mọi thứ đều hoạt động tốt khi thực hiện các yêu cầu web. Đó là thử nghiệm hồi quy.


Có lẽ vậy, nhưng đó không phải là một câu trả lời cho câu hỏi. Trên thực tế, đó là một lập luận chống lại việc sử dụng các bài kiểm tra đơn vị ở đây.
JMᴇᴇ

Tôi nghĩ rằng tôi đã trả lời câu hỏi "bạn có tin rằng một bài kiểm tra là cần thiết cho việc này không và tại sao?"
nháy mắt

Vâng, tôi nghĩ rằng @winkbrace và tôi có cùng suy nghĩ về điều này. Nhưng tôi cũng tin rằng đó là một cuộc thảo luận về những gì bạn nên kiểm tra đơn vị và không. Tôi nghĩ mọi người kiểm tra quá nhiều và những điều "sai". trong ví dụ của tôi, việc kiểm tra bộ điều khiển mang lại rất ít giá trị vì nó quá mỏng và hy vọng có các thử nghiệm xung quanh các dịch vụ. Tất cả các câu trả lời ở đây đều có ý nghĩa và có điểm tốt nhưng thực sự không thể đánh dấu một câu trả lời đúng.
sương giá

Logic điều khiển có thể được kiểm tra bằng các kiểm tra tích hợp tự động, tách biệt và khác biệt với các kiểm tra đơn vị cho các thành phần riêng lẻ.
KevBurnsJr

-1: Một bài kiểm tra đơn vị cho bộ điều khiển có thể là vô nghĩa. Bộ điều khiển là về chuyển đổi, nhưng đôi khi bản thân việc chuyển đổi rất phức tạp và nhà phát triển có thể muốn bảo vệ nó. Tôi cũng nghĩ rằng các bài kiểm tra đơn vị 1) cuối cùng là về việc xác nhận việc thực hiện, không nhất thiết phải xác nhận hành vi cấp cao và 2) được cho là nhanh chóng . Cả hai phẩm chất làm cho các bài kiểm tra đơn vị hữu ích hơn nhiều trong thời gian thực hiện; nói cách khác, họ là cuối cùng một công cụ của nhà phát triển, và chỉ tình cờ một cách để chất lượng sản phẩm Validate.
rsenna
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.