Bạn có thể giải thích bằng một vài câu:Kiểm tra đơn vị trong Java - nó là gì?
Tại sao chúng ta cần nó/tại sao chúng làm cho cuộc sống của chúng ta dễ dàng hơn?
Cách kiểm tra đơn vị [ví dụ đơn giản trong Java]?
Kiểm tra trang web JUnit và JUnit cookbook để biết chi tiết. Không có nhiều để viết các trường hợp kiểm tra JUnit. Trên thực tế đến với các trường hợp thử nghiệm tốt là chắc chắn khó khăn hơn so với thực hiện thực tế.
Khi nào chúng tôi không cần chúng/loại dự án chúng tôi có thể thoát khỏi thử nghiệm đơn vị?
Đừng cố gắng thử nghiệm mọi phương thức trong một lớp học, mà tập trung vào kiểm tra chức năng của lớp học. Đậu ví dụ, bạn sẽ không viết bài kiểm tra cho các getters và setters ...
Liên kết
JUnit - Đơn vị kiểm tra
EclEmma - thử nghiệm công cụ bảo hiểm
link text - Wikipedia liên kết đến kiểm tra đơn vị
Bởi vì đó là bằng chứng nào mà ứng dụng thực sự hoạt động như dự kiến. Bạn cũng sẽ tìm thấy lỗi hồi quy dễ dàng hơn nhiều. Việc kiểm tra trở nên dễ dàng hơn, vì bạn không phải tự đi qua mọi trạng thái ứng dụng có thể. Và cuối cùng, nhiều khả năng bạn sẽ tìm thấy các lỗi mà bạn thậm chí không biết tồn tại mặc dù bạn đã kiểm tra mã của mình theo cách thủ công.
Google cho junit
Unit tests nên luôn luôn được viết ra, như đã nói, nó là bằng chứng nào mà ứng dụng hoạt động như dự định. Một số điều không thể hoặc có thể khó kiểm tra, ví dụ như một giao diện người dùng đồ họa. Điều này không có nghĩa là GUI không nên được kiểm tra, nó chỉ có nghĩa là bạn nên sử dụng các công cụ khác cho nó.
Xem điểm 2.
Nó có thể làm việc đọc các bài viết trên Wikipedia về Unit Testing, vì điều này sẽ trả lời hầu hết các câu hỏi của bạn về tại sao. Trang web JUnit có tài nguyên để viết thử nghiệm đơn vị Java, trong đó Junit Cookbook có lẽ là điểm dừng đầu tiên của bạn.
Cá nhân, tôi viết các bài kiểm tra đơn vị để kiểm tra hợp đồng của một phương pháp, tức là tài liệu cho một chức năng cụ thể. Bằng cách này, bạn sẽ tham gia vào một chu kỳ tăng phạm vi kiểm tra của bạn và cải thiện tài liệu. Tuy nhiên, bạn nên cố gắng tránh kiểm tra: Mã
JUnit không phải là kiểm tra đơn vị duy nhất khung có sẵn cho Java, vì vậy bạn nên đánh giá các khung công tác khác như TestNG trước khi đi sâu vào nó.
Ngoài khuôn khổ "cấp cao nhất", bạn cũng sẽ tìm thấy một vài dự án bao gồm các lĩnh vực cụ thể, chẳng hạn như:
Tôi nghĩ rằng điều quan trọng cần lưu ý là kỹ thuật kiểm tra đơn vị xác định xem một số phần nhỏ (một đơn vị) của một chương trình có hoạt động đúng hay không. Điều mà hầu hết mọi người ở đây đang nói đến, và cách sử dụng hiện đại thông thường, là một thử nghiệm đơn vị tự động, chạy trong phần xây dựng hoặc theo yêu cầu. – Jason
Một trong những cuốn sách hay nhất về các bước và thử nghiệm đơn vị trong Java là Pragmatic Unit Testing in Java with JUnit (Andy Hunt)Dave Thomas)
Những gì tôi sẽ có văn bản đã được đề cập trong rất nhiều các phản ứng ở đây nhưng tôi nghĩ rằng tôi muốn thêm này ...
Các bài viết tốt nhất mà tôi từng đọc trên khi sử dụng/không kiểm tra đơn vị sử dụng là trên Steve Sanderson's blog. Đó là một bài viết tuyệt vời về chi phí/lợi ích của việc kiểm tra đơn vị trên các phần khác nhau của mã cơ sở của bạn (tức là một đối số hấp dẫn chống lại mức độ phù hợp 100%)
@Dolbz Tôi sẽ kiểm tra. Cảm ơn bạn. – EugeneP
Đây là cách cách lập trình của bạn nên là:
Như tên của nó cho thấy, nó là thử nghiệm cho các đơn vị của chúng tôi trong chương trình của chúng tôi. Ví dụ, nếu bạn có một phương thức trả về tổng kết của hai số nguyên, bạn sẽ kiểm tra nó bằng hai số để xem nó có hoạt động chính xác hay không. Ví dụ: đối với 2 + 2, nó trả về 4.
Chúng tôi cần những thử nghiệm này, vì trong các dự án lớn, có rất nhiều lập trình viên. Điều quan trọng là những lập trình viên này làm việc hài hòa. kiểm tra đơn vị hoạt động như bằng chứng về tính chính xác cho các thủ tục mà các lập trình viên của chúng tôi viết. do đó, một lập trình viên viết thủ tục của mình cộng với kiểm tra đơn vị của nó để cho thấy rằng thủ tục của mình hoạt động chính xác. Sau đó, ông cam kết những thay đổi của mình cho dự án. Các xét nghiệm này giúp bạn ngăn chặn rất nhiều lỗi trước khi xảy ra.
Tôi có một quy trình từng bước làm ví dụ, để viết ra một bài kiểm tra đơn vị Java trong Eclipse. Vui lòng xem "How To Write Unite Tests".
Tôi hy vọng điều đó sẽ hữu ích.
'đó là bằng chứng cho thấy ứng dụng hoạt động như dự định'. Đây là một quan niệm sai lầm rất phổ biến. Tất cả những gì họ chứng minh là một 'đơn vị' cụ thể hoạt động như dự định (không phải ứng dụng). Khi tích hợp nhiều đơn vị vẫn còn phạm vi cho các lỗi tích hợp trong đó hành vi trên nhiều đơn vị không như mong đợi mặc dù các đơn vị riêng lẻ có thành công 100%. Đó không phải là để nói rằng các bài kiểm tra đơn vị không phải là vô cùng hữu ích trong bản thân họ. – Dolbz
câu trả lời hay, ngoại trừ "google it" – EugeneP
Nếu bạn định chuyển sang thử nghiệm đơn vị, bạn cũng nên xem xét các khuôn khổ mocking. Sử dụng junit chỉ là một phần của phương trình, thường bạn sẽ muốn xác định trước/mô phỏng hành vi của các lớp nhất định cho thử nghiệm, ví dụ: cho một bài kiểm tra trên một lớp thường nói chuyện với một dịch vụ web, bạn có thể thử dịch vụ web để trả lại kết quả bạn muốn, thay vì thực hiện một cuộc gọi thực tế tới máy chủ web. Xem qestion này: http://stackoverflow.com/questions/22697/whats-the-best-mock-framework-for-java và http://mockito.org/ cho Mockito, một khung mocking đẹp. – Mike