Tách các lớp JUnit thành gói thử nghiệm đặc biệt?


118

Tôi đang tìm hiểu các khái niệm về Phát triển theo hướng kiểm thử thông qua việc đọc các bài viết về Thợ thủ công (nhấp vào Người thợ thủ công dưới Theo chủ đề ) được đề xuất trong câu trả lời cho câu hỏi trước của tôi, "Dự án mẫu để học JUnit và kỹ thuật phần mềm phù hợp" . Tôi yêu nó cho đến nay!

Nhưng bây giờ tôi muốn ngồi xuống và tự mình thử nó. Tôi có một câu hỏi mà tôi hy vọng sẽ chỉ cần một câu trả lời đơn giản.

Làm thế nào để bạn tổ chức các lớp kiểm tra JUnit và mã thực tế của bạn? Tôi chủ yếu nói về cấu trúc gói, nhưng bất kỳ khái niệm ghi chú nào khác cũng sẽ hữu ích.

Bạn có đặt các lớp thử nghiệm trong org.myname.project.test. * Và mã bình thường trong org.myname.project. * Không? Bạn có đặt các lớp kiểm tra ngay bên cạnh các lớp bình thường không? Bạn có thích đặt tiền tố tên lớp bằng Test hơn là đặt tiền tố chúng không?

Tôi biết điều này có vẻ như là điều tôi không nên lo lắng quá sớm, nhưng tôi là một người rất tập trung vào tổ chức. Tôi gần như là kiểu người dành nhiều thời gian hơn để tìm ra phương pháp theo dõi những việc cần hoàn thành, thay vì thực sự hoàn thành công việc.

Và tôi có một dự án hiện đang được chia thành từng gói gọn gàng, nhưng dự án trở thành một mớ hỗn độn. Thay vì cố gắng cấu trúc lại mọi thứ và viết các bài kiểm tra, tôi muốn bắt đầu mới, kiểm tra trước và tất cả. Nhưng trước tiên tôi cần biết các bài kiểm tra của tôi đi đến đâu.


chỉnh sửa: Tôi hoàn toàn quên mất Maven, nhưng có vẻ như phần lớn các bạn đang sử dụng nó! Trước đây, tôi đã có một trường hợp sử dụng cụ thể mà Maven hoàn toàn thất vọng với tôi nhưng Ant đã cho tôi sự linh hoạt mà tôi cần, vì vậy tôi cuối cùng đã gắn bó với Ant, nhưng tôi nghĩ có lẽ tôi đã tiếp cận sai. Tôi nghĩ rằng tôi sẽ cho Maven thử một lần nữa vì có vẻ như nó sẽ hoạt động tốt với sự phát triển theo hướng thử nghiệm.


Câu trả lời:


154

Tôi thích đặt các lớp thử nghiệm vào cùng một gói với các lớp dự án mà chúng thử nghiệm, nhưng trong một thư mục vật lý khác, như:

myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java

Trong một dự án Maven, nó sẽ như thế này:

myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java

Điểm chính ở đây là các lớp thử nghiệm của tôi có thể truy cập (và kiểm tra!) Các lớp và thành viên phạm vi gói.

Như ví dụ trên cho thấy, các lớp thử nghiệm của tôi có tên của lớp được thử nghiệm cộng với Testlàm hậu tố. Điều này giúp tìm kiếm chúng một cách nhanh chóng - không vui lắm khi thử tìm kiếm trong số hàng trăm lớp thử nghiệm, mỗi lớp có tên bắt đầu bằng Test...

Cập nhật lấy cảm hứng từ nhận xét của @ Ricket: theo cách này, các lớp thử nghiệm (thường) hiển thị ngay sau người bạn được thử nghiệm của họ trong danh sách tên lớp theo bảng chữ cái khôn ngoan của dự án. (Thật buồn cười khi tôi đang hưởng lợi từ điều này từng ngày, mà không hề nhận ra một cách có ý thức ...)

Update2: Rất nhiều nhà phát triển (bao gồm cả tôi) thích Maven, nhưng có vẻ như ít nhất cũng có nhiều người không thích. IMHO nó rất hữu ích cho các dự án Java "chính thống" (Tôi sẽ đặt khoảng 90% dự án vào loại này ... nhưng 10% còn lại vẫn là một thiểu số khá lớn). Nó rất dễ sử dụng nếu người ta có thể chấp nhận các quy ước của Maven; tuy nhiên nếu không, nó làm cho cuộc sống trở thành một cuộc đấu tranh khốn khổ. Maven dường như khó hiểu đối với nhiều người trên mạng xã hội Ant, vì nó rõ ràng đòi hỏi một cách suy nghĩ rất khác. (Bản thân tôi, chưa bao giờ sử dụng Ant, không thể so sánh cả hai.) Một điều chắc chắn là: nó làm cho thử nghiệm đơn vị (và tích hợp) trở thành một bước tự nhiên, hạng nhất trong quy trình, giúp các nhà phát triển áp dụng phương pháp thiết yếu này.


6
Tôi cũng đồng ý với ghi chú hậu tố. Ngoài ra, vì các lớp kiểm tra được tách thành một thư mục vật lý khác, không cần phải thử và đặt tiền tố với Kiểm tra trong một số nỗ lực đánh lừa sắp xếp thứ tự bảng chữ cái vào nhóm và tôi nghĩ SomeClassTest đọc tốt hơn.
Ricket

Ước tuyệt vời 1
whiskeysierra

1
Một điều về việc đặt các lớp thử nghiệm trong cùng một gói: mặc dù nó cho phép sử dụng các thành viên gói-riêng (đó là lý do tại sao tôi sử dụng lược đồ này), nó cũng không cho phép kiểm tra khả năng hiển thị tự động, đặc biệt. nếu bạn sử dụng TDD và để IDE của bạn tạo các sơ khai phương thức cần thiết. Nó có thể tạo ra chúng với khả năng hiển thị gói-riêng tư (NetBeans, tôi đang nhìn bạn), điều này làm cho bài kiểm tra của bạn vượt qua hoàn hảo (sau khi bạn thực sự đưa việc triển khai vào sơ khai đó), nhưng có thể không thành công khi sử dụng thực tế (nếu bạn quên thêm public) .
Sergei Tachenov

Mặc dù quy ước này rất thú vị, nhưng bạn sẽ làm gì khi bộ thử nghiệm phát triển? Ví dụ: giả sử bạn có 6 phương pháp trong lớp, mỗi phương pháp có 10 bài kiểm tra. Bạn có 60 bài kiểm tra trong lớp của bạn? Tôi thường chia nhỏ lớp thử nghiệm (một lớp thử nghiệm cho mỗi phương pháp). Vấn đề với điều này là bạn có thể tìm thấy rất nhiều lớp trong gói thử nghiệm của mình.
mmalmeida

1
@Thick_propheT trong Eclipse: nhấp chuột phải vào tên dự án, nhấp vào Mới - Khác ..., sau đó bên trong thư mục Java chọn Thư mục nguồn. đặt tên là "test". Sau đó, nếu bạn muốn tuân theo quy ước ở trên, hãy thêm một gói mới vào thư mục thử nghiệm này có cùng tên với gói của lớp mà bạn muốn viết trường hợp thử nghiệm, sau đó trong gói thêm một Trường hợp thử nghiệm JUnit mới (nằm trong thư mục Java / Junit khi bạn làm New-Other ...). trong trình hướng dẫn mới đó, bạn có thể chỉ định lớp đang được kiểm tra và đặt tên trường hợp thử nghiệm của bạn giống như tên với hậu tố "Kiểm tra"
inor 26/09/17

15

Tôi đặt các lớp thử nghiệm của mình trong cùng một gói với những gì họ đang thử nghiệm nhưng trong một thư mục hoặc dự án nguồn khác . Tổ chức mã thử nghiệm của tôi theo cách này cho phép tôi dễ dàng biên dịch và đóng gói riêng để các tệp jar sản xuất không chứa mã thử nghiệm. Nó cũng cho phép mã kiểm tra truy cập các trường và phương thức riêng của gói.


12

Tôi sử dụng Maven . Cấu trúc mà Maven thúc đẩy là: -

src/main/java/org/myname/project/MyClass.java

src/test/java/org/myname/project/TestMyClass.java

tức là một lớp kiểm tra với Kiểm tra được thêm vào trước tên của lớp được kiểm tra nằm trong cấu trúc thư mục song song với bài kiểm tra chính.

Một lợi thế của việc có các lớp thử nghiệm trong cùng một gói (mặc dù không nhất thiết phải là thư mục) là bạn có thể tận dụng các phương thức phạm vi gói để kiểm tra hoặc đưa vào các đối tượng thử nghiệm.


18
Tôi mặc dù vậy <class>Test.java, không phảiTest<class>.java
Mike Rylander

2
Maven sẽ chấp nhận một trong hai mẫu, theo tài liệu về Plugin Maven Surefire .
Elijah Woodward

3
Tôi cho rằng <class>Test.javalược đồ đặt tên làm cho cả lớp chính và lớp thử nghiệm hiển thị gần nhau khi sử dụng các tính năng tìm kiếm IDE, điều này làm cho nó tốt hơn một chút Test<class>.java.
christopheml

1
@christopheml Tôi đồng ý, đó là những gì tôi làm bây giờ.
Martin

Điều này đã làm việc cho Intellij. MyClassTest.java không hoạt động.
dùng2761431
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.