2011-03-30 29 views
6

trong một plugin jQuery tôi đã tạo ra chức năng helper, như thế nàylàm thế nào để đơn vị kiểm tra chức năng nội bộ trong plugin jquery?

(function($) { 

    var someHelperFunction = function(s, d) { 
    return s*d; 
    } 
    var someOtherHelperFunction = function(s) { 
    return s*2; 
    } 

// here goes the normal plugin code 

})(jQuery); 

bây giờ tôi muốn gọi someHelperFunction từ bên ngoài, để có thể đơn vị kiểm tra nó, là có thể bằng cách nào đó?

+0

Vì bạn không thể truy cập các phương thức từ bên ngoài, điều đó là không thể. –

Trả lời

0

những người giúp việc được scoped bên trong plugin, mà là một chức năng ẩn danh, và bạn không thể truy cập vào các biến khai báo bên trong nó.
Nếu bạn muốn kiểm tra, hãy thả từ khóa var ở phía trước các chức năng. Điều đó sẽ khai báo các hàm như là toàn cầu (sẽ gắn chúng vào đối tượng cửa sổ), cho chúng khả năng hiển thị từ phạm vi cửa sổ (bằng cách gọi someHelperFunction hoặc window.someHelperFunction).
vậy, để thử nghiệm:

(function($) { 
    someHelperFunction = function(s, d) { 
     return s*d; 
    } 
    someOtherHelperFunction = function(s) { 
     return s*2; 
    } 
    // here goes the normal plugin code 
})(jQuery); 

sau khi thử nghiệm kết thúc, thêm từ khóa var một lần nữa.

Cập nhật
Tôi nghĩ rằng một cách tiếp cận tốt hơn sẽ được nhóm chức năng kiểm chứng của bạn trong một đối tượng - và xây dựng một api. Sau đó, trên cùng một nguyên tắc, bạn có thể làm api mà có thể nhìn thấy trong phạm vi toàn cầu hay không:

(function($, global) { 
    someHelperFunction = function(s, d) { 
     return s*d; 
    } 
    someOtherHelperFunction = function(s) { 
     return s*2; 
    } 

    var api = { 
     someHelperFunction: someHelperFunction, 
     someOtherHelperFunction: someOtherHelperFunction 
    }; 

    // decide whether you want to expose your api or not 
    if(makeGlobal) { 
     global.api = api; 
    } 
})(jQuery, this); 
+4

Hãy vui vẻ với điều này. –

+3

Không sử dụng các biến toàn cầu chỉ để kiểm tra các chức năng riêng của bạn. Đây không phải là câu trả lời hay vì nó xác nhận những thực hành xấu. – drublic

2

Per this related question, tôi muốn nói chỉ cần kiểm tra giao diện bên ngoài.

Nhưng nếu bạn phải thử nghiệm các phương pháp này một cách riêng biệt, bạn sẽ phải kiểm tra "bản sao" của chúng bên ngoài ngữ cảnh triển khai của chúng làm phương thức nội bộ. Nói cách khác, tạo một đối tượng mà trong đó chúng không thể truy cập được vào mã máy khách và sau đó cobble các phiên bản đó cùng với kịch bản bên ngoài của bạn trong một quá trình trước. Nghe có vẻ như rất nhiều công việc, nhưng hey, đó là điểm của phương pháp ẩn, phải không? (Để làm cho họ không thể truy cập.)

-3

hãy nhìn vào qunit, một thử nghiệm đơn vị hoạt Javascript lib

+1

Nó không phải là về thử nghiệm nói chung. Đó là về thử nghiệm các phương pháp địa phương. –

+0

oops, xin lỗi .. đã nói quá nhanh. lưu ý đến bản thân: đọc kỹ trước khi gõ – cander

1

Nếu các chức năng nội bộ cần thử nghiệm đó là một dấu hiệu tốt mà họ có thể phải ở trong một mô-đun riêng biệt ở đâu đó và tiêm như phụ thuộc và được sử dụng trong các đối tượng thực hiện giao diện công cộng của bạn. Đó là cách "dễ kiểm chứng" hơn để làm điều đó.

var myActualImplementationTestTheHellOutOfMe = function(s, d) { 

    return s*d; 

} 

(function($, helper) { 

    var someHelperFunction = function(s, d) { 
    return helper(s, d); 
    } 
    var someOtherHelperFunction = function(s) { 
    return s*2; 
    } 

// here goes the normal plugin code 

})(jQuery, myActualImplementationTestTheHellOutOfMe); 
1

Bạn cũng có thể xem xét tài liệu JavaScript. Có hai cách triển khai mà tôi biết: Ian Bicking's doctest.jsdoctest của riêng tôi.

+0

Tôi đang cố gắng cân nhắc những ưu và nhược điểm của mỗi thư viện nhưng chúng có vẻ khá giống nhau. Là tác giả của doctest - bạn có thể cho một thời gian ngắn không? Trường hợp sử dụng của tôi là thêm các bài kiểm tra đơn vị vào [không gian trắng] (https://github.com/dotnetCarpenter/white-space/issues/6) không có api công khai và cần thử nghiệm các đồ đạc và tài liệu HTML .readyState. – dotnetCarpenter

+0

Đầu tiên, tài liệu cho phép các ví dụ sử dụng được kiểm tra, đảm bảo rằng chúng vẫn được cập nhật. Doctests thực sự dùng để kiểm tra * tài liệu *, không phải mã. Thứ hai, tài liệu hoạt động tốt cho [chức năng thuần túy] (http: // vi.wikipedia.org/wiki/Pure_function), nhưng không phải cho mã dựa trên cuộc gọi lại. Tôi đề nghị sử dụng một khung kiểm thử chuyên dụng. – davidchambers

+0

Điều tôi thực sự thích về doctest, là tôi không phải tạo một API công khai giả tạo chỉ để thử nghiệm. Theo tôi hiểu, tôi có thể viết tài liệu phương thức/chức năng bên trong các bao đóng và vẫn cho phép truy cập cho các bài kiểm tra đơn vị. Tôi đoán đó là giới hạn của các hàm thuần túy, đó là một công cụ xử lý đối với tôi, vì những gì tôi thực sự thử nghiệm hành vi. – dotnetCarpenter

Các vấn đề liên quan