Phát triển dựa trên thử nghiệm và cải thiện kỹ năng kiểm tra hộp trắng

9

Tôi là một lập trình viên Java cấp nhập cảnh. Tôi có kiến thức và kinh nghiệm tốt với J2SE. Bất cứ ai có thể tư vấn cho tôi về cách cải thiện hoặc điều chỉnh các kỹ năng của tôi để trở thành một người thử nghiệm hộp trắng Java? Nhiều đầu vào được chào đón.

Và phát triển hướng thử nghiệm là gì?

— người dùng892871
nguồn

Tại sao không thử nghiệm hộp đen là tốt?

— Martijn Verburg

@Martijn, xem xét nền tảng, rất có thể là do những thách thức kỹ thuật của thử nghiệm whitebox. Ngoài ra, trong khi các kỹ thuật hộp đen rất hữu ích cho các nhà phát triển, những người có phẩm chất tốt cho nhà phát triển không tạo ra những người thử nghiệm hộp đen tốt, chúng tôi quá tò mò và có thể mất kiên nhẫn. Tôi biết tôi làm được.

— StuperUser

9

Phát triển hướng thử nghiệm (TDD) và đó là anh em họ mở rộng, TDD chấp nhận (ATDD) và Phát triển hướng hành vi (BDD) là những kỹ thuật hữu ích để học như một người thử nghiệm trong hệ sinh thái Java. Tôi sẽ tập trung vào TDD khi bạn đang tìm kiếm thử nghiệm hộp trắng.

TDD là gì? - Trung tâm, đó là cách thực hành viết một bài kiểm tra thất bại (màu đỏ), làm cho bài kiểm tra đó vượt qua bằng cách viết một triển khai (màu xanh lá cây) và sau đó bao thanh toán lại. Bài viết Wikipedia là một nơi đủ để bắt đầu tìm hiểu thêm thông tin. Nhưng chủ đề rất rộng lớn, tôi khuyên bạn nên đọc một số cuốn sách nổi tiếng trong không gian này như Phát triển hướng thử nghiệm bằng ví dụ và Làm việc hiệu quả với mã kế thừa . Tôi cũng sẽ sử dụng một cách không biết xấu hổ cho chương TDD trong Nhà phát triển Java có căn cứ

Trong hệ sinh thái Java, điều này có nghĩa là bạn muốn tìm hiểu:

Các JUnit thư viện và / hoặc TestNG thư viện.
Một thư viện chế giễu như Mockito hoặc JMock
Một công cụ kiểm tra tải để tấn công mã - JMeter
Khái niệm về Dependency Injection (một dạng đảo ngược của kiểm soát)

Và sau đó luyện tập, luyện tập, luyện tập, luyện tập. Trình kiểm tra hộp trắng Java tốt là rất hiếm, tốt nhất có các bài kiểm tra viết chống lại một loạt các cơ sở mã.

HTH giúp bạn bắt đầu!

— Martijn Verburg
nguồn

Chúng cũng là những kỹ thuật hữu ích để học như một nhà phát triển trong hệ sinh thái Java. Theo tôi hiểu, người kiểm tra nên làm kiểm tra hộp đen.

— Tom

1

Junit là một trong những khung thử nghiệm đơn vị tốt nhất cho ngôn ngữ lập trình Java. Đây là một khung nguồn mở để viết và chạy các bài kiểm tra lặp lại.

— Swagatika
nguồn

1

Tôi thường không muốn trích dẫn Wikipedia nhưng thông tin về bài viết này có vẻ đủ an toàn ...

http://en.wikipedia.org/wiki/Test-driven_development

Về cơ bản, theo cách hiểu, đây là cách tiếp cận Test-First để phát triển phần mềm là các bài kiểm tra đơn vị được thiết kế và viết để sử dụng các trường hợp trước, sau đó phát triển khó xảy ra sau đó để giúp các bài kiểm tra đơn vị đó vượt qua.

— phong_shaft
nguồn

0

Tôi không chắc liệu đề xuất của tôi có được coi là công cụ để kiểm tra hộp trắng hay không nhưng bạn cũng có thể xem dbUnit cho các dự án dựa trên cơ sở dữ liệu và Selenium để kiểm tra web (ví dụ: kiểm tra các yếu tố nên tồn tại dựa trên một số kết quả).

— Bob Santos
nguồn

0

Câu hỏi đặc biệt làm cho tham chiếu đến "thử nghiệm hộp trắng". Đây là nơi các bài kiểm tra của bạn có kiến thức sâu sắc về cấu trúc bên trong mã của bạn và khẳng định hành vi ở mỗi bước thay vì chỉ hiệu ứng đầu vào / đầu ra / phụ (kiểm tra hộp đen). Trong khi JUnit là tuyệt vời để làm cả hai, bạn cần thêm các khung bổ sung để làm điều này trong bối cảnh của một bài kiểm tra đơn vị.

EasyMock và JMock là những khuôn khổ tốt để làm điều này. Tôi có xu hướng ủng hộ JMock.

Có nguy cơ bắt đầu một cuộc tranh luận trong Cựu ước, bạn nên suy nghĩ cẩn thận về ý nghĩa của việc kiểm tra hộp trắng. Các kiểm tra hộp trắng được liên kết chặt chẽ với mã của bạn (rõ ràng) và nếu không được sử dụng cẩn thận, các khung mô phỏng có thể khiến các kiểm tra của bạn khá phức tạp, khó đọc và có xu hướng dễ vỡ hơn khi tái cấu trúc.

Tôi có xu hướng dính vào một hỗn hợp của cả hai. Kiểm tra hộp đen bất cứ khi nào có thể, và kiểm tra hộp trắng áp dụng một cách tiết kiệm cho mã rủi ro / phức tạp hơn.

Tất nhiên, các khung được liệt kê ở trên cũng có thể được sử dụng trong các thử nghiệm hộp đen trong đó số lượng các lớp đóng góp (được tiêm) lớn và việc khai thác đơn giản trở nên khó sử dụng.

Về TDD - chủ yếu là cách tiếp cận nâng cao thiết kế để viết mã, thay vì chỉ đơn giản là cách viết bài kiểm tra. Các thử nghiệm bạn có ở cuối là một đầu ra quan trọng, nhưng hơn nữa cách tiếp cận nhằm tăng cường thiết kế và cấu trúc ứng dụng của bạn.

— rupjones
nguồn