Thực tiễn tốt nhất là đưa các chú thích Javadoc vào các lớp và phương thức kiểm tra junit? Hay là ý tưởng rằng họ nên dễ đọc và đơn giản đến mức không cần thiết phải cung cấp một câu chuyện về mục đích thử nghiệm?Javadoc trong các lớp thi Junit?
Cá nhân tôi sử dụng bình luận javadoc một cách tiết kiệm khi tôi thấy chúng làm tăng sự lộn xộn trên màn hình. Nếu tôi có thể đặt tên cho một lớp, hàm hoặc biến theo cách tự mô tả hơn thì tôi sẽ ưu tiên cho một chú thích. Một cuốn sách tuyệt vời để đọc về chủ đề này là Clean Code bởi Robert C. Martin (a.k.a Chú Bob).
sở thích cá nhân của tôi là làm cho cả lớp và phương pháp tự mô tả ví dụ:
class ANewEventManager {
@Test
public void shouldAllowClassesToSubscribeToEvents() {
/* Test logic here */
}
}
Một ưu điểm của phương pháp này là nó rất dễ dàng để xem trong đầu ra junit gì là không trước khi duyệt mã.
Tôi sử dụng Javadoc trong thử nghiệm của mình rất nhiều. Nhưng nó chỉ thực sự hữu ích khi bạn thêm thẻ của riêng bạn vào javadoc của bạn.
Mục tiêu chính ở đây là làm cho bài kiểm tra dễ hiểu đối với các nhà phát triển khác đóng góp cho dự án của bạn. Và cho rằng chúng ta thậm chí không cần phải tạo ra javadoc thực tế.
/**
* Create a valid account.
* @result Account will be persisted without any errors,
* and Account.getId() will no longer be <code>null</code>
*/
@Test
public void createValidAccount() {
accountService.create(account);
assertNotNull(account.getId());
}
Tiếp theo, chúng tôi cần thông báo cho plugin Javadoc của chúng tôi rằng chúng tôi đã thêm thẻ mới.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
<configuration>
<tags>
<tag>
<name>result</name>
<placement>a</placement>
<head>Test assertion :</head>
</tag>
</tags>
</configuration>
</plugin>
</plugins>
</build>
Và bây giờ tất cả những gì còn lại cần làm là gọi trình cắm maven của chúng tôi.
javadoc:test-javadoc (or javadoc:test-aggregate for multi-module projects)
Đây là một ví dụ khá dễ dàng, nhưng khi chạy thử nghiệm phức tạp hơn, nó là không thể để mô tả các bài kiểm tra bằng cách đơn giản sử dụng một tên phương pháp tự mô tả.
Điều gì sẽ là đầu ra của ví dụ của bạn? – jgomo3
Tôi cũng thích nhận xét bằng UT, nó giúp hiểu trường hợp sử dụng sau vài giây.
Tôi đã tạo một thư viện nhỏ để bao gồm các mô tả trong ngăn xếp của bất kỳ loại báo cáo nào, bất kỳ ai kiểm tra báo cáo đều có thể dễ dàng gặp sự cố.
Tên thư viện là Frutilla, cảm thấy tự do để sử dụng nó https://github.com/ignaciotcrespo/frutilla
Đọc mã sạch ngay bây giờ. Chỉ cần hoàn thành bài kiểm tra đơn vị của Roy Ohserov, người thực sự nhấn mạnh khả năng đọc của con người về bài kiểm tra đơn vị và tích hợp. – HDave