2009-08-04 29 views
64

tôi có một dự án mà tôi đang xây dựng với Maven trong đó sử dụng Hibernate (và mùa xuân) để lấy dữ liệu từ một cơ sở dữ liệu, vvCác phương pháp hay nhất để kiểm tra tích hợp với Maven?

"kiểm tra" My cho DAO trong dự án của tôi kéo dài Spring AbstractTransactionalDataSourceSpringContextTests để một DataSource thể được kết nối vào lớp của tôi đang được kiểm tra để có thể chạy logic truy vấn/Hibernate, để tìm nạp dữ liệu, v.v.

Trên một số dự án khác, tôi đã sử dụng các loại thử nghiệm này cùng với cơ sở dữ liệu HSQL -memory hoặc chỉ vào một tệp) để có thể kiểm tra hiệu quả logic truy vấn cơ sở dữ liệu thực tế mà không dựa vào cơ sở dữ liệu bên ngoài. Điều này làm việc tuyệt vời, vì nó tránh bất kỳ phụ thuộc bên ngoài và "nhà nước" của cơ sở dữ liệu trước khi chạy các bài kiểm tra (mỗi trong số đó được bao bọc trong một giao dịch được cuộn lại) được xác định rõ.

Tôi rất tò mò về cách tốt nhất để tổ chức các thử nghiệm này, đây thực sự là một thử nghiệm tích hợp lỏng lẻo, với Maven. Nó cảm thấy một chút bẩn để giữ các xét nghiệm này trong src/test/java, nhưng từ những gì tôi đã đọc có vẻ không phải là một chiến lược nhất quán hoặc thực hành để tổ chức các bài kiểm tra tích hợp với Maven.

Từ những gì tôi đã đọc cho đến nay, có vẻ như tôi có thể sử dụng Failsafe plugin (hoặc trường hợp thứ hai của Surefire) và liên kết nó với giai đoạn integration-test và tôi cũng có thể ràng buộc tùy chỉnh khởi động hoặc tắt máy. chẳng hạn như để bắt đầu/dừng phiên bản HSQL) thành pre-integration-test hoặc post-integration-test. Nhưng, đây thực sự là phương pháp tốt nhất?

Vì vậy, câu hỏi của tôi về cơ bản là - thực tiễn tốt nhất được chấp nhận chung về tổ chức điều này với Maven là gì? Tôi đang gặp khó khăn khi tìm bất kỳ loại câu trả lời nhất quán nào trong tài liệu.

Những gì tôi muốn là để:

  • kiểm tra đơn vị riêng biệt từ các xét nghiệm hội nhập, vì vậy chỉ kiểm tra đơn vị được điều hành trong giai đoạn test
  • Khả năng liên kết lôgic khởi động tùy chỉnh/tắt máy để pre-integration-testpost-integration-test
  • có báo cáo từ hội nhập-kiểm tra sáp nhập/trình bày với các đơn vị kiểm tra chắc chắn báo cáo
+2

Move các bài kiểm tra tích hợp trong một dự án riêng biệt và duy trì các bài kiểm tra đơn vị trong cùng một dự án với tư cách là nguồn. –

Trả lời

20

codehaus page này với một số hướng dẫn. Tôi tìm thấy plugin không an toàn một chút của một hack, và nó làm cho chạy các bài kiểm tra đơn vị trong Eclipse fiendishly phức tạp. Tôi làm rộng rãi những gì bạn mô tả.

Xác định các xét nghiệm hội nhập trong src/itest/java Trong giai đoạn pre-hội nhập-test:

  • Rõ ràng mục tiêu/thử nghiệm lớp
  • Sử dụng mục tiêu build-helper-maven-plugin 's add-kiểm tra mã nguồn để thêm vị trí nguồn tốt nhất
  • Sử dụng Mojo tùy chỉnh để xóa src/test/java khỏi cấu hình để kiểm tra đơn vị không được biên dịch lại (Tôi thực sự không thích điều này, nhưng cần thiết để duy trì việc tách đơn vị và tích hợp kiểm tra).
  • Sử dụng trình biên dịch-plugin để biên dịch các bài kiểm tra tích hợp

Sau đó, trong giai đoạn hội nhập-kiểm tra, sử dụng chắc chắn hơn-plugin để chạy thử nghiệm.

Cuối cùng, ràng buộc bất kỳ mục tiêu gọn gàng nào cho giai đoạn thử nghiệm tích hợp sau (mặc dù thông thường chúng không cần thiết vì bạn có thể sử dụng teardown thử nghiệm() để dọn dẹp).

Tôi chưa tìm được cách kết hợp kết quả kiểm tra khi giai đoạn báo cáo đã trôi qua, nhưng tôi có xu hướng xem các bài kiểm tra tích hợp như một phần thưởng bổ sung, miễn là họ vượt qua báo cáo không quan trọng .

Cập nhật: Tôi nghĩ rằng điều đáng nói là bạn có thể chạy Jetty từ bên trong các bài kiểm tra tích hợp của bạn thay vì sử dụng mục tiêu cầu nối. Điều này giúp bạn kiểm soát tốt hơn các bài kiểm tra. Bạn có thể tìm hiểu thêm chi tiết từ this answer và các blog được tham chiếu.

+2

Bạn có thực sự cần phải loại bỏ các bài kiểm tra đơn vị? Chắc chắn nó không phải là một ý tưởng tồi để chạy chúng một lần nữa tại thời gian thử nghiệm tích hợp. –

+1

Nói chung bạn nói đúng. Không có hại gì khi chạy thử nghiệm đơn vị một lần nữa, nhưng tôi đã có 100 dự án trên máy chủ và phải thực hiện một số tối ưu hóa để quản lý tải trong phần cứng có sẵn. –

+0

Đủ công bằng, bạn đã có một trường hợp đặc biệt khá quan trọng :-) –

6

This good blog post đề xuất ba tùy chọn;

1) mô-đun riêng biệt cho các xét nghiệm hội nhập

2) thư mục nguồn khác nhau

3) khác nhau tên file mẫu

Tôi chưa thử cả ba, vì vậy không thể đưa ra ý kiến mà tôi thích.

+3

liên kết chính xác là http://javamoods.blogspot.com/2009/12/unit-and-integration-testing-with-maven.html – Alex

25

Cách đơn giản để thực hiện việc này là sử dụng các danh mục JUnit.

Sau đó, bạn có thể dễ dàng chạy một số thử nghiệm trong giai đoạn thử nghiệm và một thử nghiệm khác trong giai đoạn thử nghiệm tích hợp.

Mất vài phút và chỉ yêu cầu 3 bước.

  1. Định nghĩa một giao diện đánh dấu
  2. Chú thích các lớp bạn muốn chia
  3. plugins Configure Maven.

Ví dụ đầy đủ được đưa ra ở đây. https://stackoverflow.com/a/10381662/1365383

+1

giải pháp rất tốt thực sự! – Uberto

+0

Hoặc nếu bạn đang sử dụng TestNG, bạn có thể chỉ định các nhóm thử nghiệm: đơn vị và tích hợp chẳng hạn. – Kemoda

1

Tôi thích tùy chọn thứ hai, Các thư mục nguồn khác nhau, nhưng tôi thấy khá khó chịu phải kết thúc với CNTT các bài kiểm tra tích hợp hoặc loại trừ các gói.

Để tránh điều này, tôi đã kết thúc với cấu hình này:

<properties> 
    <testSource>src/test/java</testSource> 
    <testSourceResource>src/test/resources</testSourceResource> 
</properties> 
<build> 
    <testSourceDirectory>${testSource}</testSourceDirectory> 
    <testResources> 
      <testResource> 
      <directory>${testSourceResource}</directory> 
      </testResource> 
     </testResources> 
..... 
..... 

và sau đó tôi ghi đè lên cả hai biến trong các cấu hình khác nhau cho hội nhập và nghiệm thu:

<profiles> 
    <profile> 
    <id>acceptance-tests</id> 
    <properties> 
    <testSource>src/acceptance-test/java</testSource> 
    <testSourceResource>src/acceptance-test/resources</testSourceResource> 
    </properties> 
    </profile> 
<profile> 
    <id>integration-tests</id> 
    <properties> 
    <testSource>src/integration-test/java</testSource> 
    <testSourceResource>src/integration-test/resources</testSourceResource> 
    </properties> 
    </profile> 
..... 
..... 
..... 
Các vấn đề liên quan