Để tải hoặc không tải dữ liệu cho các bài kiểm tra đơn vị từ các tệp bên ngoài


16

Khi kiểm tra đơn vị, tôi thường thấy mình đang tranh luận về việc tôi cung cấp bao nhiêu dữ liệu và mong đợi từ các đơn vị của mình được kiểm tra, tôi nên đưa vào các tệp kiểm tra thực tế.

Sự đánh đổi mà tôi không ngừng đấu tranh là:

  • Nếu một phần lớn của thử nghiệm (trong khối lượng mã) bao gồm dữ liệu đầu vào và đầu ra, thì thực sự khó đọc thử nghiệm, nhưng tôi có thể dễ dàng nhìn thấy đầu vào và đầu ra thực tế.
  • Nếu tôi tải dữ liệu thử nghiệm từ các tệp, tôi có thể dễ dàng kiểm tra một loạt các biến thể của dữ liệu nhập có thể, dễ dàng sử dụng lại dữ liệu thử nghiệm cho nhiều thử nghiệm, nhưng tôi phải để lại mã nguồn để xem tệp khác để xem chính xác đầu vào là gì .

Là một trong những mô hình chống?


Những loại dữ liệu?
Jon Reid

@JonReid: Chủ yếu là văn bản.
DudeOnRock

Câu trả lời:


10

Để trả lời trực tiếp câu hỏi của bạn - không, tôi không tin hoặc là một mẫu chống khi được sử dụng đúng cách.

--- Câu trả lời dài dòng hơn ---

Từ kinh nghiệm của tôi, tôi nghĩ điều này phụ thuộc rất nhiều vào mục tiêu kiểm tra của bạn. Đây là quy tắc của ngón tay cái tôi đã sử dụng trong quá khứ và nó đã giúp tôi quyết định:

Bạn đang thực sự kiểm tra một đơn vị mã nhỏ? (Một bài kiểm tra đơn vị thực sự)

Nếu có, thì tôi đã thấy việc tạo dữ liệu bên trong bài kiểm tra chính xác dễ dàng hơn nhiều vì tôi có thể thấy những gì đang được truyền vào. Trong những trường hợp này, tôi thường sẽ tìm một thư viện giống như Jasmine để sử dụng vì tôi thấy rằng nó làm cho việc tạo và duy trì dữ liệu thử nghiệm dễ dàng hơn. Đó là một sở thích cá nhân - sử dụng bất cứ điều gì làm cho công việc của bạn dễ dàng hơn.

Nếu không, thì có lẽ bạn đang thực sự kiểm tra chính hệ thống. Trong những trường hợp này, tôi thường tải dữ liệu từ nguồn bên ngoài, lý do ở đây là:

  1. Thử nghiệm này không phải là về độ rõ ràng của mã đối với các lập trình viên (mặc dù điều đó vẫn quan trọng - ai đó phải duy trì điều này), đó là về việc chạy đủ các loại dữ liệu khác nhau thông qua toàn bộ khối hệ thống để chắc chắn rằng nó hoạt động hợp lý.
  2. Thường thì tôi sẽ viết mã hệ thống ống nước để tải và sử dụng dữ liệu thử nghiệm, nhưng chính dữ liệu đó được tạo bởi người khác (thường là nhân viên QA trong trường hợp của tôi). Những người này thường không phải là lập trình viên nên tôi không thể mong họ chỉnh sửa mã.

Vì vậy, câu trả lời dài, nó phụ thuộc vào những gì bạn đang thử nghiệm và tại sao. Cả hai cách tiếp cận đều hữu ích và có vị trí của chúng - chọn cách nào phù hợp nhất với tình huống của bạn.


9

Tôi không thấy một sự đánh đổi ở đây. Mã nguồn được cho là để mô tả các thuật toán, hoặc ít nhất là logic kinh doanh, không phải là lượng dữ liệu lớn. Nếu bạn viết một biến đổi Fourier, bạn muốn xác minh rằng âm xoang được ánh xạ chính xác đến một đỉnh đơn, âm thanh hỗn hợp đến nhiều đỉnh hơn, v.v., nhưng điều đó là hoàn toàn đủ để cung cấp một tệp có tên sinus.wavvào thói quen và xác minh rằng cấu trúc đầu ra là những gì bạn mong đợi.

Chắc chắn, về mặt kỹ thuật, bạn không có một sự đảm bảo ngay lập tức sinus.wavthực sự có chứa âm xoang, nhưng như bạn đã nói, việc liệt kê 100.000 giá trị biên độ trong nguồn không thực sự mang lại cho bạn điều đó - thực tế, nó còn tệ hơn , bởi vì bạn ít nhất có thể phát một tệp bên ngoài với một trình phát âm thanh để kiểm tra, trong khi các giá trị dữ liệu bị chôn vùi trong mã nguồn về cơ bản là không thể làm gì được.

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.