2013-07-19 62 views
5

Tôi đang cố gắng kiểm tra đơn vị một ứng dụng khá phức tạp nhưng sử dụng MVC. Tôi biết việc áp dụng các xét nghiệm đơn vị không phải là lý tưởng nhưng tôi vẫn tin rằng có thể bằng cách tái cấu trúc mã hiện có. Phần lớn thời gian không thể kiểm thử đơn vị một đơn vị, mà không dựa vào các đơn vị khác, tức là chế độ xem dựa trên mô hình.Làm thế nào các xét nghiệm đơn vị có thể được mô-đun khi chúng phụ thuộc vào các đơn vị khác?

Cách tốt nhất để kiểm tra đơn vị trong trường hợp này là gì? Tốt hơn là sử dụng mô hình thực hay tạo mô hình giả?

Vấn đề với việc sử dụng mô hình thực trong tình huống của tôi là mô hình dựa trên các lớp phản hồi khác nhận dữ liệu từ XML để có một chuỗi phụ thuộc. Mô hình này có rất nhiều dữ liệu để dễ sử dụng hơn nhưng có lẽ tôi đang thiếu điểm.

Tôi đã cung cấp UML của ứng dụng cho ngắn gọn.

enter image description here

** Sửa ****

Ok vì vậy nếu tôi đúng, là nó thực hành tốt nhất để tạo ra dữ liệu giả bên trong một lớp học giả? ví dụ tôi có lớp học giả "MockPlaylistPanelModel" tạo ra dữ liệu cần thiết cho việc Xem lớp "PlaylistPanel" để chạy không có lỗi:

class MockPlaylistPanelModel extends Mock implements IPlaylistPanelModel 
{ 
    /** 
    * Return all playlist items 
    * @public 
    */ 
    public function get mainPlaylistItems():Vector.<PlaylistData> 
    { 
    var playData:Vector.<PlaylistData> = new Vector.<PlaylistData>; 
    var playlistResp:PlaylistData = new PlaylistData(0, "", "", 0, 0, 0, 0); 
    playData.push(playlistResp); 
    return playData; 
    } 

} 

Trả lời

6

Để kiểm tra đơn vị phù hợp với ứng dụng hiện có, bạn thường cần thay đổi mã ứng dụng để hỗ trợ kiểm tra đơn vị (như bạn đề cập đúng bạn có thể cần thực hiện một số phép tái cấu trúc). Tuy nhiên, tất nhiên rủi ro ở đây là những thay đổi đối với ứng dụng giới thiệu các lỗi, không thể được bảo vệ chống lại mà không có một số thử nghiệm tại chỗ.

Do đó, một cách tiếp cận hợp lý là để có được một số kiểm tra mức hệ thống tại chỗ bao gồm một số trường hợp sử dụng chính của bạn. Điều này đóng vai trò như một 'giàn giáo thử nghiệm' xung quanh ứng dụng của bạn, có nghĩa là bạn có thể bắt đầu giới thiệu các bài kiểm tra cấp thấp hơn một cách an toàn với giảm nguy cơ giới thiệu lỗi khi bạn sửa đổi ứng dụng để làm cho nó dễ kiểm tra hơn. Khi điều này xảy ra, bạn có thể giới thiệu một chính sách rằng các nhà phát triển phải viết các kiểm tra xung quanh bất kỳ mã nào họ thay đổi trước khi họ thay đổi nó - điều này cho phép bạn phát triển một cách tự nhiên một tập hợp các kiểm tra tự động xung quanh ứng dụng.

Tôi rất muốn giới thiệu việc lưu giữ Working Effectively with Legacy Code - cuốn sách tuyệt vời này bao gồm tất cả các loại kỹ thuật hữu ích để giới thiệu thử nghiệm vào một ứng dụng hiện có ít thử nghiệm tự động.

Về câu hỏi của bạn về việc bạn có nên tạo dữ liệu giả trong lớp mô phỏng để kiểm tra hay không, đây là một cách bạn có thể thực hiện khi tiêm phiên bản thử nghiệm của đối tượng, nhưng có lẽ không phải là tốt nhất. Bằng cách sử dụng khung mocking như Mockito, bạn có thể dễ dàng tạo các đối tượng giả với hành vi được xác định rõ ràng khi đang di chuyển. Trong trường hợp của bạn, bạn có thể sử dụng Mockito để tạo ra một mô hình thực hiện mô hình, và sau đó tiêm mô hình giả của bạn vào bất kỳ đối tượng phụ thuộc vào nó.

+0

+1 để tham khảo sách, +1 cho Mockito, +1 cho câu trả lời hay - quá tệ tôi chỉ có thể bỏ phiếu một lần ... – weltraumpirat

0

Họ không phải là kiểm tra đơn vị; chúng là các thử nghiệm tích hợp.

Có, sử dụng mocks để cô lập các lớp học cho các bài kiểm tra đơn vị.

0

Kiểm tra đơn vị phải chỉ kiểm tra một phần của chương trình. Nếu bạn sử dụng các phần khác, nó sẽ trở thành thử nghiệm tích hợp.

Kiểm tra tích hợp kiểm tra xem các bộ phận có hoạt động tốt với nhau hay không và không làm những gì họ phải làm.

Kiểm tra đơn vị kiểm tra xem phần đó có hoạt động không.

Đó là sự khác biệt giữa hai thử nghiệm.

Để cấu trúc lại để kiểm tra đơn vị, bạn có thể tìm mẫu thiết kế Dependency Injection.