tạo thử nghiệm đơn vị (bán) tự động?

Question

Có khung làm việc hỗ trợ tạo một số kiểm tra đơn vị tiêu chuẩn từ chú thích không? Một ví dụ về những gì tôi có trong tâm trí sẽ là:

@HasPublicDefaultConstructor 
public class Foo { 

} 

Điều này rõ ràng sẽ được sử dụng để tự động tạo kiểm tra đơn vị kiểm tra xem Foo có hàm tạo mặc định hay không. Tôi có phải là người duy nhất nghĩ về điều gì đó như thế không? ;) Trong khi tôi quan tâm nhất đến Java, các giải pháp bằng các ngôn ngữ khác chắc chắn sẽ rất thú vị.

EDIT: Để trả lời câu trả lời của S.Lott, hãy để tôi làm rõ:

Tôi đang cố gắng kiểm tra xem lớp đó có hàm tạo mặc định hay không. (Tất nhiên đó chỉ là một ví dụ.) Tôi chỉ có thể làm như vậy bằng cách viết một bài kiểm tra, nhưng tôi thấy rằng khá tẻ nhạt. Vì vậy, tôi đang tìm một công cụ có thể xử lý các chú thích tại thời gian biên dịch (thông qua APT) và tạo kiểm tra cho tôi. Có điều gì giống như vậy không? Nếu không, bạn có nghĩ đó là một ý tưởng hay không?

Answer 1

điều này có thể là những gì bạn đang tìm kiếm: http://developer.spikesource.com/wiki/index.php/Projects:testgen4j. các liên kết hữu ích khác tại: http://www.opensourcetesting.org/unit_java.php. đây là giấy hiện tại: http://www.alexquinn.org/papers/Generating%20Java%20unit%20tests%20with%20AI%20planning%20(2007).pdf

Answer 2

EiffelStudio CDD có một cách tiếp cận thú vị. Trong khi chạy trong chế độ gỡ lỗi, IDE thu thập thông tin về các phương thức được gọi và đặt ngữ cảnh và các cuộc gọi vào các kiểm thử đơn vị. Thất bại được phát hiện bằng cách sử dụng Design by Contract. Tôi biết có một số thiết kế của phần mở rộng hợp đồng trên đầu trang của Java, vì vậy đây có thể là một cách tốt đẹp để đi.

Answer 3

Ví dụ cụ thể của bạn có thể tốt hơn khi sử dụng java APT (biên dịch chú thích thời gian biên dịch) để phát hiện các vấn đề như vậy sớm hơn nhiều, tại thời gian biên dịch.

Answer 4

Agitar có [thương mại] sản phẩm, AgitarOne, tạo thử nghiệm JUnit. Tôi không chắc chắn nó hiện đang hỗ trợ chú thích, nó didn't in 2005.

Jtest là một trình tạo testr đơn vị Java khác và Parasoft cũng cung cấp C++Test để tạo các thử nghiệm đơn vị C++.

Tôi chưa bao giờ thử nghiệm bất kỳ thứ gì trong số chúng; Tôi đã đọc bài kiểm tra C++ một vài năm trước đây, nhưng không được thuyết phục.

Answer 5

Câu hỏi đặt ra là liệu "gây ô nhiễm" mã sản xuất với thông tin Kiểm tra đơn vị dưới dạng chú thích bổ sung có thực sự là một ý tưởng hay không. Cá nhân tôi sẽ bỏ phiếu chống lại nó.

Answer 6

Hơi giống với những gì bạn đã mô tả để kiểm tra sự hiện diện của một hàm tạo mặc định, tôi đã sử dụng TestUtil để tự động kiểm tra getters và setters. Bạn có thể sử dụng tệp XML hoặc thẻ JavaDoc để tinh chỉnh các tùy chọn thử nghiệm. Đáng buồn là hiện tại dường như không phải là tùy chọn cho chú thích.

Answer 7

"xử lý các chú thích ... và tạo ra các thử nghiệm đối với tôi"

Đối với một số lượng hạn chế các trường hợp, điều này có thể được thực hiện để làm việc. Nói chung, tuy nhiên, nó không thể làm việc.

@StandardTestForClassHierarchy1 
@StandardTestForClassHierarchy2 
@StandardTestForClassHierarchy3 
@StandardTestForSomeOtherFeature4 
@AspectFeature5 
@AspectFeature6 
@HasPublicDefaultConstructor 
@AspectX 
@AspectY 
class SomeClass extends SomeClassHierarchy implements SomeOtherFeature { 
} 

Tôi không thể phân biệt chú thích không được chú thích của mình khỏi chú thích thực sự của tôi.

Chú thích kiểm tra có mô tả hành vi thời gian chạy của ứng dụng của tôi không?

• Nếu họ làm mô tả thời gian chạy hành vi, sau đó họ cho-real chú thích AOP, không giới thiệu các bài kiểm tra, nhưng chú thích thực sự mà thực sự tạo ra mã run-time. Và chú thích có thử nghiệm riêng trên các lớp mô phỏng.

• Nếu chú thích không mô tả hành vi thời gian chạy, bây giờ tôi có sự lộn xộn kỳ lạ này của chú thích không hoạt động và chức năng. Tôi không thấy giá trị trong chú thích không hoạt động.

Answer 8

Có vẻ như bạn đang tìm kiếm một ngôn ngữ lập trình có sức mạnh biểu đạt khai báo nhiều hơn tiêu chuẩn Java. Các bài kiểm tra mà bạn đề xuất điền vào các khoảng trống cho đến khi trình biên dịch có thể kiểm tra ngữ nghĩa của các khai báo.

Tôi không biết bất kỳ công cụ nào chuyển đổi từ loại chú thích bạn đề xuất thành thử nghiệm tự động. Nghe có vẻ như một bài tập TDD tốt, mặc dù, đặc biệt là với các API trình biên dịch (-ish) gần đây.

Answer 9

Bạn có thể phát hiện điều này tại thời gian biên dịch với APT.

http://www.javaspecialists.eu/archive/Issue167.html

Answer 10

tl; dr: công cụ kiểm tra Sử dụng mã thay thế. Họ có thể làm những gì bạn muốn, không gây ô nhiễm mã của bạn và có thể dễ dàng được xây dựng thành một quá trình xây dựng tự động.

Điều này nghe có vẻ không giống với một bài kiểm tra đơn vị. Nếu bạn kiên quyết rằng mọi lớp phải có một hàm tạo mặc định, một trình phân tích mã tĩnh có thể là một sự đánh cược tốt hơn. PMD chắc chắn có một máy dò cho loại điều này. Bạn cũng có thể ép loại máy dò này với Checkstyle.

Cả hai đều dễ dàng tùy chỉnh và có thể được thực hiện một phần của quá trình tích hợp liên tục của bạn ngay bên cạnh các bài kiểm tra đơn vị của bạn.

Điểm quan trọng nhất: Điều này sẽ cho phép bạn triển khai chức năng mà bạn muốn mà không gây ô nhiễm cơ sở mã với chú thích bổ sung. Đó là điểm mấu chốt lớn đối với tôi khi tôi nhìn vào ý tưởng này: bạn đã tạo ra một vấn đề quản lý phần mềm lớn.

Chỉ cần tưởng tượng tình hình sửa đổi một lớp với một hàm khởi tạo mặc định là không thay đổi (do đó yêu cầu các đối tượng được thiết lập đầy đủ trong khi xây dựng). Bạn có nhớ cập nhật tất cả các chú thích đó trong lớp đó không? Bạn có nhớ thay đổi chú thích có liên quan trong các lớp khác gọi phương thức trong phần này không? Và kể từ đó trở đi.

Answer 11

Tôi nghĩ bạn không thể tự cứu mình bất cứ điều gì. Nhưng bạn sẽ thêm tính phức tạp.

Nếu tôi muốn chắc chắn có một hàm tạo mặc định, tôi sẽ thêm phần sau đây vào bài kiểm tra đơn vị của mình.

Foo foo = new Foo();