Quy ước đặt tên cho các gói thử nghiệm

Chúng tôi thực sự đặt tên cho các gói thử nghiệm của chúng tôi giống như các đối tác thử nghiệm của chúng. Vì vậy, chúng tôi kết thúc với cấu trúc này:

src/main/java
    com.hello.world
        helloWorld.java
src/test/java
    com.hello.world
        helloWorldTest.java

Tôi luôn cảm thấy như thế này không thông minh lắm vì bạn không thể phân biệt giữa "kiểm tra" và "kiểm tra" nếu chỉ được cung cấp với tên gói. Mặt khác, tôi đã không thực sự tìm thấy một trường hợp nào đó vấn đề này bằng cách nào đó. Đây có phải là một cách thực hành tốt để có các quy ước đặt tên giống nhau cho cả hai gói (đối với các trường hợp thử nghiệm và các lớp nguồn) không? Nếu không, điều gì sẽ là một cách tiếp cận tốt hơn?

naming packages

— OddDev
nguồn

Không biết nó có tốt không, nhưng nó là một thứ phổ biến. Tùy chọn khác (để đặt "Kiểm tra" vào tên gói, tên phương thức, v.v.) đánh hơi quá nhiều vào "Đặt tên Smurf". Như bạn nói, thật khó để nghĩ đến trường hợp không thể "phân biệt giữa" kiểm tra "và" kiểm tra "nếu chỉ được cung cấp với tên gói" sẽ là một vấn đề.

— David Arno

@DavidArno Cảm ơn bạn đã nhập :) Làm thế nào để tránh đặt tên smurf? Ý tôi là chúng ta sẽ kết thúc với com.hello.world.test.helloWorld.java, phải không?

— OddDev

Các "smurf" vấn đề là nhiều khi bạn có một phương pháp XXXTest()trong com.hello.world.test.helloWorldTest.java. Lời khuyên chung là chỉ có "Kiểm tra" xuất hiện một lần trong đường dẫn, vì vậy (a) sử dụng kiểm tra trong tên gói (và đặt tên tệp kiểm tra giống như tệp đang kiểm tra) hoặc (b) đặt tên gói là tương tự và thêm "test" vào tên tệp / lớp.

— David Arno

@DavidArno Ah, cảm ơn đã làm rõ! Tôi đã nhận xét đầu tiên của bạn sai. Tôi hiểu rồi

— OddDev

Vâng, tôi tranh luận rằng, nếu nó không rõ ràng, tôi đã nhận xét sai đầu tiên của mình :)

— David Arno

Đó là một quy ước tốt.

Đôi khi bạn muốn viết các bài kiểm tra đơn vị cho các lớp và các phương thức riêng tư. Bạn sẽ không thể gọi cho họ từ một lớp kiểm tra đơn vị được đặt trong gói khác.

Không nên có bất kỳ sự nhầm lẫn nào về việc có các lớp kiểm tra đơn vị trong cùng một không gian tên vì chúng không nên nằm trong đường dẫn lớp khi biên dịch hoặc chạy mã sản xuất.

Dưới đây là ví dụ về một mô-đun nhỏ với giao diện công cộng, lớp nhà máy công cộng và hai lớp triển khai gói riêng:

src/main/java:
    com.hello.transmogrifier
        public interface Transmogrifier
        public class TransmogrifierFactory
        class MapTransmogrifier implements Transmogrifier
        class ListTransmogrifier implements Transmogrifier

scr/test/java:
    com.hello.transmogrifier
        public class TransmogrifierFactoryTest
        public class MapTransmogrifierTest
        public class ListTransmogrifierTest

Ẩn các cài đặt của giao diện Transmogrifier có thể là một lựa chọn thiết kế hợp lệ. Có lẽ đó là trách nhiệm của lớp nhà máy trong việc lựa chọn thực hiện.

Vì các triển khai là gói riêng tư, bạn cần đặt các lớp kiểm tra đơn vị trong cùng một gói nếu bạn muốn kiểm tra chúng trực tiếp. Nếu bạn có các lớp kiểm tra đơn vị của mình trong một số gói khác, bạn chỉ có quyền truy cập trực tiếp vào giao diện công cộng và lớp xuất xưởng từ các bài kiểm tra của bạn.

— ĐẾN TỪ
nguồn

"Thông thường bạn muốn viết các bài kiểm tra đơn vị cho các lớp và các phương thức riêng tư gói". Không! Đây thực sự là thực hành xấu. Các loại gói riêng là chi tiết triển khai và không bao giờ nên được kiểm tra trực tiếp. Chỉ kiểm tra API công khai.

— David Arno

@DavidArno tôi không đồng ý. Tuy nhiên, tôi đã thay thế từ "thường" bằng từ "đôi khi" để tránh cuộc thảo luận cụ thể đó.

— ĐẾN TỪ

Bạn có thể không đồng ý tất cả những gì bạn muốn, nhưng việc kiểm tra hoạt động bên trong của một đoạn mã dẫn đến cả hai khớp nối chặt chẽ giữa các hoạt động bên trong và các thử nghiệm và để kiểm tra dễ vỡ trong khi tái cấu trúc đơn giản. Đó là thực tế rất xấu.

— David Arno

Nếu tôi muốn đảm bảo tất cả các triển khai Transmogrifier của tôi hoạt động, bất kể nhà máy làm gì, thì tôi sẽ viết các bài kiểm tra đơn vị kiểm tra từng lần thực hiện. Lưu ý rằng việc triển khai có API công khai được chia sẻ mặc dù các lớp là gói riêng tư. Các thử nghiệm này không được phá vỡ trừ khi tôi thay đổi API công khai. Trên thực tế, có lẽ tôi sẽ viết một bài kiểm tra chung cho Transmogrifier và sau đó chạy thử với mỗi lần thực hiện. Mặc dù có thể có được mỗi lần thực hiện bằng cách sử dụng nhà máy, tốt hơn hết là không nên có sự phụ thuộc đó khi thử nghiệm Transmogrifiers.

— ĐẾN TỪ

Rồi một ngày, bạn nhìn vào MapTransmogrifiervà ListTransmogrifierquyết định chúng có thể được tạo thành một lớp, vì vậy bạn tạo ListMapTransmogrifier, sửa đổi nhà máy để sử dụng và xóa hai lớp. Mã bây giờ không biên dịch, vì vậy bạn phải sửa đổi mọi thử nghiệm trong cả hai MapTransmogrifierTestvà ListTransmogrifierTestđể biên dịch nó. Một bài kiểm tra thất bại. Đó có phải là do thay đổi các bài kiểm tra hoặc tạo ra ListMapTransmogrifier? Ra mắt trình gỡ lỗi để tìm hiểu ... thay vào đó khi các bài kiểm tra sử dụng nhà máy, bạn thực hiện công cụ tái cấu trúc đó và tất cả vẫn còn biên dịch ...

— David Arno