Kiểm tra theo hướng dữ liệu với jUnit

Question

Bạn sử dụng những gì để viết các thử nghiệm theo hướng dữ liệu trong jUnit?

(Định nghĩa của tôi) một thử nghiệm dựa trên dữ liệu là một thử nghiệm đọc dữ liệu từ một số nguồn bên ngoài (tệp, cơ sở dữ liệu, ...), thực hiện một thử nghiệm trên mỗi dòng/tệp/bất kỳ và hiển thị kết quả trong Á hậu thử nghiệm như thể bạn đã thử nghiệm riêng biệt - kết quả của mỗi lần chạy được hiển thị riêng biệt, không phải trong một tổng hợp lớn.

Answer 1

Trong JUnit4, bạn có thể sử dụng trình kiểm tra Parameterized để thực hiện kiểm tra định hướng dữ liệu.

Nó không được ghi nhận kỹ lưỡng, nhưng ý tưởng cơ bản là tạo một phương thức tĩnh (chú thích với @Parameters) trả về một tập hợp các mảng đối tượng. Mỗi mảng được sử dụng làm đối số cho hàm tạo lớp thử nghiệm và sau đó các phương thức thử nghiệm thông thường có thể được chạy bằng các trường được đặt trong hàm tạo.

Bạn có thể viết mã để đọc và phân tích cú pháp tệp văn bản bên ngoài theo phương pháp @Parameters (hoặc lấy dữ liệu từ nguồn bên ngoài khác), sau đó bạn có thể thêm thử nghiệm mới bằng cách chỉnh sửa tệp này mà không cần biên dịch lại các thử nghiệm.

Answer 2

Kiểm tra định hướng dữ liệu thường sử dụng một thành phần có thể kiểm tra nhỏ để xử lý dữ liệu. (Đối tượng đọc tệp hoặc đối tượng giả) Đối với cơ sở dữ liệu và tài nguyên bên ngoài ứng dụng mocks được sử dụng để mô phỏng các hệ thống khác. (Dịch vụ web và cơ sở dữ liệu, v.v.). Thông thường tôi thấy là có các tệp dữ liệu ngoài xử lý dữ liệu và đầu ra. Bằng cách này, tập tin dữ liệu có thể được thêm vào VCS.

Answer 3

tôi sử dụng sự kết hợp của dbUnit, jMock và JUnit 4. Sau đó, bạn có thể ether chạy nó như bộ hoặc riêng rẽ

Answer 4

Chúng tôi hiện có nộp đạo cụ với số ID của chúng tôi trong đó. Điều này là khủng khiếp giòn, nhưng rất dễ dàng để có được một cái gì đó đi. Kế hoạch của chúng tôi là ban đầu có những số ID này được ghi đè bởi các thuộc tính -D trong các bản dựng kiến ​​của chúng tôi.

Môi trường của chúng tôi sử dụng DB kế thừa với dữ liệu đan xen khủng khiếp không thể tải trước khi chạy (ví dụ: bởi dbUnit). Cuối cùng, chúng tôi muốn đến nơi thử nghiệm đơn vị sẽ truy vấn DB để tìm ID với thuộc tính đang được kiểm tra, sau đó sử dụng ID đó trong thử nghiệm đơn vị. Nó sẽ chậm và được gọi là kiểm thử tích hợp, chứ không phải "kiểm tra đơn vị", nhưng chúng tôi sẽ thử nghiệm dựa trên dữ liệu thực để tránh tình huống mà ứng dụng của chúng tôi chạy hoàn toàn dựa trên dữ liệu thử nghiệm nhưng không thành công với dữ liệu thực.

Answer 5

Tôi sử dụng cơ sở dữ liệu trong bộ nhớ như hsqldb để tôi có thể điền trước cơ sở dữ liệu bằng bộ dữ liệu "kiểu sản xuất" hoặc tôi có thể bắt đầu với cơ sở dữ liệu hsqldb trống cần phải thực hiện thử nghiệm của tôi. Trên hết, tôi sẽ viết các bài kiểm tra của mình bằng cách sử dụng JUnit và Mockito.

Answer 6

Một số thử nghiệm sẽ tự cho mình là giao diện điều khiển.

Nếu cơ sở dữ liệu/tệp đọc được truy xuất bằng cuộc gọi giao diện thì chỉ cần kiểm tra đơn vị của bạn để triển khai giao diện và lớp kiểm tra đơn vị có thể trả lại bất kỳ dữ liệu nào bạn muốn.

Answer 7

Tôi với @ DroidIn.net, đó là chính xác những gì tôi đang làm, tuy nhiên để trả lời câu hỏi của bạn theo nghĩa đen "và hiển thị kết quả trong một người thử nghiệm như thể bạn đã thử nghiệm riêng biệt", bạn phải xem xét JUnit4 Á hậu tham số. DBUnit không làm điều đó. Nếu bạn phải làm rất nhiều điều này, trung thực TestNG là linh hoạt hơn, nhưng bạn hoàn toàn có thể làm cho nó được thực hiện trong JUnit.

Bạn cũng có thể xem JUnit Theories runner, nhưng hồi ức của tôi là nó không tuyệt vời cho các tập dữ liệu định hướng dữ liệu, điều này có ý nghĩa bởi vì JUnit không làm việc với số lượng lớn dữ liệu bên ngoài.

Answer 8

Đây là nơi TestNG, với @DataSource, tỏa sáng. Đó là một lý do tại sao tôi thích nó với JUnit; những người khác là phụ thuộc và thử nghiệm luồng song song.

Answer 9

Mặc dù đây là chủ đề khá cũ, tôi vẫn nghĩ đến việc đóng góp phần của mình. Tôi cảm thấy sự hỗ trợ của JUnit đối với việc kiểm tra theo hướng dữ liệu là ít và quá không thân thiện. cho ví dụ. để sử dụng tham số, chúng ta cần viết hàm tạo của chúng ta. Với lý thuyết Á hậu, chúng tôi không có quyền kiểm soát tập dữ liệu thử nghiệm được chuyển đến phương pháp thử nghiệm.

Hiện có nhiều nhược điểm như được xác định trong bài đăng blog này series: http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html

Hiện nay có là một giải pháp toàn diện đến cùng khá độc đáo trong các hình thức EasyTest đó là khuôn khổ aa mở rộng ra khỏi JUnit và nhằm cung cấp cho một nhiều chức năng cho người dùng. Trọng tâm chính của nó là thực hiện kiểm tra dữ liệu bằng cách sử dụng JUnit, mặc dù bạn không cần phải thực sự phụ thuộc vào JUnit nữa. Đây là dự án github cho refernece: https://github.com/anujgandharv/easytest

Nếu ai đó muốn đóng góp ý kiến ​​/ mã/đề xuất thì đây là lúc. Bạn chỉ cần truy cập kho lưu trữ github và tạo ra các vấn đề.

Answer 10

Bạn nên mở rộng TestCase bằng "DataDrivenTestCase" phù hợp với nhu cầu của mình. Đây là ví dụ: http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html

Không giống như kiểm tra tham số, nó cho phép các trường hợp kiểm tra được đặt tên độc đáo.