2014-07-08 26 views
28

Tôi đã quan tâm đến việc tạo thử nghiệm đơn vị cho các chức năng "không được báo cáo (riêng tư)" khi đang di chuyển. Tuy nhiên, về cơ bản nó thực sự khó khăn để tạo ra các xét nghiệm đơn vị tạo thành chúng trong gói thử nghiệm bởi vì tôi phải làm cho chúng "công khai". Mà cuối cùng, đánh bại toàn bộ quan điểm của họ là riêng tư. Vấn đề là chức năng trợ giúp này giúp môđun hóa và bây giờ chúng là mô-đun, sẽ tốt hơn nếu có thể tạo các bài kiểm tra đơn vị cho chúng mà không làm cho chúng có sẵn cho tất cả mọi người ngoại trừ gói thử nghiệm, chúng không phải là các hàm cần truy cập hoặc được sử dụng bởi bất kỳ ai khác ngoại trừ bộ thử nghiệm hoặc gói thực tế.Làm thế nào để kiểm tra chức năng không được báo cáo (riêng) trong go (golang)?

Mọi đề xuất? Có thể chỉ xuất hiện gói riêng và 1 gói bổ sung hoặc thứ gì đó thuộc loại đó không?

Trả lời

35

tạo ra một tập tin thử nghiệm trong gói

library_test.go

package mypkg 

func TestPrivateStruct(t *testing.T){ 
    pf := private{ "Private Field" } 
    .... 
} 

library.go

package mypkg 

type private struct { 
    privateField string 
} 

go test mypkg -v sẽ chạy thử nghiệm của bạn với struct tin của bạn

+0

Nhưng điều này có nghĩa là tất cả các thử nghiệm đơn vị của tôi không nằm trong gói 'test', phải không? Vì vậy, chạy thử nghiệm trên thư mục kiểm tra sẽ không còn cung cấp cho một bài kiểm tra đầy đủ của thư viện của tôi, phải không? –

+6

@CharlieParker - Có, nhưng đó là tiêu chuẩn trong Go. Bạn trộn các tệp _test và các tệp không phải _test trong một gói và kiểm tra một số/path/packagename, không phải một số/path/packagename/test hoặc một số/path/tests/packagename. – twotwotwo

+2

@twotwowo đủ công bằng. Tuy nhiên, nó gây phiền nhiễu để phải đi đến mọi thư mục để chạy thử nghiệm mỗi đi. Có thể chạy ** tất cả ** của các bài kiểm tra thông qua một số loại lệnh hoặc một tập tin thực hiện hoặc một cái gì đó của loại đó? –

3

Thứ nhất, bạn có thể có cả hai loại kiểm tra ở cùng một vị trí với y gói của chúng tôi bằng cách sử dụng tên gói cho các kiểm tra nội bộ (ví dụ: mypkg) và sử dụng cùng tên gói với "_test" được thêm vào cho các kiểm tra "bên ngoài" (ví dụ: mypkg_test). Cả hai loại kiểm tra phải nằm trong các tệp có tên kết thúc bằng "_test.go".

NHƯNG, toàn bộ các điểm kiểm tra đơn vị là để kiểm tra "giao diện bên ngoài" (tức là các chức năng công cộng) đối với gói của bạn. Đó là các xét nghiệm đơn vị phải luôn là các thử nghiệm "hộp màu trắng" (xem White Box Testing). Bằng cách đó bạn có thể cấu trúc lại mã của bạn và các thử nghiệm của bạn sẽ không bị phá vỡ.

Tất nhiên, đôi khi bạn muốn kiểm tra tính nhất quán nội bộ, điều này là không thể thông qua "giao diện bên ngoài". Vì điều đó tôi đã tìm thấy những xác nhận vô giá. Một khả năng khác là thêm (các) chức năng "chẩn đoán" công cộng với tên chỉ ra rằng chúng không dùng cho mục đích sử dụng bình thường.

+0

_với tên chỉ ra rằng chúng không sử dụng bình thường._ --- tại thời điểm bạn chỉ truy cập vào nội bộ từ các bài kiểm tra đơn vị của bạn, nhưng thông qua một lớp hướng dẫn có thể truy cập từ người gọi đến khởi động. Nếu bạn làm điều này, đó là một dấu hiệu tinh thể rõ ràng 'chỉ bên ngoài' thử nghiệm không cắt nó cho mục đích của bạn. Cũng có thể gọi một spade một spade và đi nội bộ. – hraban

+1

kiểm tra đơn vị là * không * chỉ cho các chức năng công cộng. Thường thì một giao diện công cộng có thể dẫn đến vô số các kỳ vọng khác nhau do kết hợp các chức năng riêng tư.nó dễ dàng hơn và an toàn hơn để có một bài kiểm tra đơn vị cho các chức năng mục đích đơn lẻ nhỏ hơn. Bạn vẫn muốn thử nghiệm công chúng cũng rõ ràng. –

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