Thực hành tốt nhất của dbunit cho hiệu suất

Question

Một số nguyên tắc/nguyên tắc tốt nhất cần làm theo những gì được đề xuất trên trang web dbunit thực tế, điều này có thể tăng tốc kiểm tra cũng như duy trì chúng? Tôi xin một số library like factory girl cho java, nhưng nó không giống như nó có thể vì gõ tĩnh.

Suy nghĩ hiện tại của tôi là có 1 bộ dữ liệu xml cho mỗi lớp thử nghiệm tại thời điểm này - có thể tôi chia sẻ một số trong số này và có thể tôi không. Trong khi một số dữ liệu thử nghiệm có thể được sao chép dữ liệu được sao chép, tôi thấy nó quá khó để duy trì bộ dữ liệu được chia sẻ qua 3000 bài kiểm tra đơn vị/tích hợp - và tôi có nhiều thời gian để đi.

Sẽ đánh giá cao bất kỳ nguyên tắc nào để theo dõi dẫn đến các thử nghiệm hoạt động tốt và dễ bảo trì.

Answer 1

Trong một bài tập trước, chúng tôi đã có hàng trăm bài kiểm tra tích hợp liên quan đến tập dữ liệu, mặc dù không phải trong DBUnit — môi trường thử nghiệm được viết từ đầu, vì nó là một công ty rất lớn có thể làm được điều này.

Tập dữ liệu được tổ chức theo thứ bậc. Hệ thống được thử nghiệm bao gồm một vài (5-10) mô-đun và dữ liệu thử nghiệm theo mẫu đó. Kịch bản lệnh thử nghiệm đơn vị trông giống như sau:

include(../../masterDataSet.txt) 
include(../moduleDataSet.txt) 

# unit-specific test data 
someProperty=someData 

Tên thuộc tính được ánh xạ trực tiếp vào bản ghi DB bằng một số công cụ kỳ quái mà tôi không thể nhớ.

Có thể áp dụng cùng một mẫu cho thử nghiệm DBUnit. Trong bộ dữ liệu chính bạn có thể đặt bản ghi luôn cần phải là — như từ điển, tải ban đầu của cơ sở dữ liệu, như thể nó được cài đặt từ đầu.

Trong bộ dữ liệu mô-đun bạn nên đặt hồ sơ bao gồm các trường hợp kiểm tra của phần lớn các thử nghiệm trong một mô-đun; Tôi không cho rằng một thử nghiệm trung bình của bạn bao gồm tất cả 70 bảng cơ sở dữ liệu của bạn, phải không? Bạn chắc chắn phải có một số nhóm chức năng có thể cấu thành một mô-đun, ngay cả khi ứng dụng là nguyên khối. Cố gắng tổ chức dữ liệu thử nghiệm cấp mô-đun xung quanh nó.

Cuối cùng, ở cấp kiểm tra, bạn chỉ sửa đổi bộ thử nghiệm của mình với số lượng bản ghi tối thiểu cần thiết cho các thử nghiệm cụ thể này.

Cách tiếp cận này có lợi ích to lớn của việc học; bởi vì có rất ít tệp dữ liệu, trong thời gian đó, bạn thực sự bắt đầu ghi nhớ chúng. Thay vì nhìn thấy hàng trăm tập hợp dữ liệu lớn chỉ khác nhau bởi các chi tiết không đáng kể (bạn phải tìm ra mỗi khi bạn quay lại thử nghiệm sau một thời gian), bạn có thể dễ dàng biết hai tập dữ liệu khác nhau như thế nào.

Một từ về hiệu suất ở cuối. Trên 2 của tôi.4 GHz 2 lõi WinXP máy xét nghiệm DBUnit liên quan đến:

• thả 14 bảng,
• tạo 14 bảng,
• chèn ca. 100 bản ghi,
• thực hiện logic thử nghiệm,

mất 1-3 giây. Nhật ký cho thấy rằng 3 hoạt động đầu tiên mất ít hơn một giây, hầu hết thời gian thử nghiệm được tiêu thụ bởi Spring. Logic này được thực hiện bởi mỗi bài kiểm tra, để tránh phụ thuộc vào thứ tự kiểm tra. Mọi thứ đều chạy trong một máy ảo với Derby được nhúng, đây có lẽ là lý do tại sao nó quá nhanh.

EDIT: Tôi nghĩ rằng bộ dữ liệu XML DBUnit không hỗ trợ bao gồm các tập tin thử nghiệm khác, nó có thể được khắc phục bằng cách sử dụng một lớp cơ sở cho tất cả các xét nghiệm hội nhập, ví dụ:

public class AbstractITest { 

    @Before 
    public void setUp() throws Exception { 
     // 
     // drop and recreate tables here if needed; we use 
     // Spring's SimpleJdbcTemplate executing drop/create SQL 
     // 
     IDataSet masterDataSet = new FlatXmlDataSetBuilder().build("file://masterDataSet.xml"); 
     DatabaseOperation.CLEAN_INSERT.execute(dbUnitConnection, dataSet); 
    } 
} 

public class AbstractModuleITest extends AbstractITest { 

    @Before 
    public void setUp() throws Exception { 
     super.setUp(); 
     IDataSet moduleDataSet = new FlatXmlDataSetBuilder().build("file://moduleDataSet.xml"); 
     DatabaseOperation.CLEAN_INSERT.execute(dbUnitConnection, moduleDataSet); 
    } 
} 

public class SomeITest extends AbstractModuleITest { 
    // The "setUp()" routine only here if needed, remember to call super.setUp(). 

    @Test 
    public void someTest() { ... } 
} 

Answer 2

Đề xuất trong Junit trong Hành động 2e thực sự không tạo quá nhiều tập dữ liệu (như một trong mỗi lớp thử nghiệm), nhưng chỉ đủ để được coi là duy trì được. Ngoại trừ một vài trường hợp ngoại lệ, tôi thấy có thể sử dụng một tập dữ liệu tổng thể cho hầu hết các bài kiểm tra đơn vị và các bộ dữ liệu riêng lẻ cho các bài kiểm tra tích hợp. Hạn chế sử dụng ExpectedDataSets cũng là một tùy chọn.

Ngoài ra, tôi đã sử dụng Unitils kết hợp với dbunit để đơn giản hóa một số cài đặt và tải dữ liệu thử nghiệm, vì vậy bạn có thể muốn xem xét nó khi thích hợp.