Tại sao nên sử dụng JUnit để thử nghiệm?

Có thể câu hỏi của tôi là một người mới, nhưng tôi thực sự không thể hiểu được hoàn cảnh mà tôi sẽ sử dụng tháng sáu?

Cho dù tôi viết các ứng dụng đơn giản hay ứng dụng lớn hơn, tôi đều kiểm tra chúng bằng các System.outcâu lệnh và nó rất dễ dàng đối với tôi.

Tại sao tạo các lớp kiểm tra với JUnit, các thư mục không cần thiết trong dự án nếu chúng ta vẫn phải gọi các phương thức tương tự, kiểm tra xem chúng trả về cái gì và sau đó chúng ta có một chi phí chú thích mọi thứ?

Tại sao không viết một lớp và kiểm tra nó cùng một lúc System.outmà không tạo các lớp Test?

Tái bút Tôi chưa bao giờ làm việc trên các dự án lớn mà tôi chỉ đang học.

Vậy mục đích là gì?

Đó không phải là thử nghiệm, đó là "tìm kiếm thủ công ở đầu ra" (được biết đến trong biz là LMAO). Chính thức hơn, nó được gọi là "tìm kiếm thủ công cho đầu ra bất thường" (LMFAO). ^{(Xem ghi chú bên dưới)}

Bất cứ khi nào bạn thay đổi mã, bạn phải chạy ứng dụng và LMFAO cho tất cả các mã bị ảnh hưởng bởi những thay đổi đó. Ngay cả trong các dự án nhỏ, đây là vấn đề và dễ bị lỗi.

Bây giờ quy mô lên tới 50k, 250k, 1m LỘC trở lên và LMFAO bất cứ khi nào bạn thực hiện thay đổi mã. Không chỉ khó chịu, điều đó là không thể: bạn đã nhân rộng các kết hợp đầu vào, đầu ra, cờ, điều kiện và rất khó để thực hiện tất cả các nhánh có thể.

Tồi tệ hơn, LMFAO có thể có nghĩa là truy cập các trang trên các trang của ứng dụng web, chạy báo cáo, lướt qua hàng triệu dòng nhật ký trên hàng chục tệp và máy, đọc email được tạo và gửi, kiểm tra tin nhắn văn bản, kiểm tra đường dẫn của robot, đổ đầy chai soda, tổng hợp dữ liệu từ hàng trăm dịch vụ web, kiểm tra lộ trình kiểm toán của một giao dịch tài chính ... bạn có ý tưởng. "Đầu ra" không có nghĩa là một vài dòng văn bản, "đầu ra" có nghĩa là hành vi hệ thống tổng hợp.

Cuối cùng, kiểm tra đơn vị và hành vi xác định hành vi hệ thống. Các thử nghiệm có thể được chạy bởi một máy chủ tích hợp liên tục và kiểm tra tính chính xác. Chắc chắn là vậy System.out, nhưng máy chủ CI sẽ không biết liệu một trong số họ có sai không và nếu có, họ sẽ kiểm tra đơn vị và bạn cũng có thể sử dụng khung.

Cho dù chúng ta nghĩ chúng ta tốt đến đâu, con người không phải là khung kiểm tra đơn vị tốt hoặc máy chủ CI.

Lưu ý: LMAO đang thử nghiệm, nhưng trong một ý nghĩa rất hạn chế. Nó không lặp lại theo bất kỳ cách có ý nghĩa nào trong toàn bộ dự án hoặc là một phần của quy trình. Nó giống như phát triển gia tăng trong REPL, nhưng không bao giờ chính thức hóa các thử nghiệm gia tăng đó.

Chúng tôi viết các bài kiểm tra để xác minh tính đúng đắn của hành vi của chương trình.

Xác minh tính đúng đắn của hành vi của chương trình bằng cách kiểm tra nội dung của câu lệnh đầu ra bằng mắt của bạn là một hướng dẫn , hay cụ thể hơn là một quá trình trực quan .

Bạn có thể tranh luận rằng

kiểm tra trực quan hoạt động , tôi kiểm tra xem mã có làm gì không, đối với các kịch bản này và một khi tôi có thể thấy nó chính xác, chúng tôi sẽ làm tốt.

Trước tiên, thật tuyệt khi bạn quan tâm đến việc mã có hoạt động chính xác hay không. Đó là một điều tốt. Bạn đang ở phía trước của đường cong! Đáng buồn thay, có một vấn đề với điều này như là một cách tiếp cận.

Vấn đề đầu tiên với kiểm tra trực quan là bạn là một tai nạn hàn tồi mà không bao giờ có thể kiểm tra lại tính chính xác của mã của bạn.

Vấn đề thứ hai là cặp mắt được sử dụng kết hợp chặt chẽ với bộ não của chủ sở hữu đôi mắt. Nếu tác giả của mã cũng sở hữu đôi mắt được sử dụng trong quá trình kiểm tra trực quan, thì quá trình xác minh tính chính xác có sự phụ thuộc vào kiến ​​thức về chương trình được nội hóa trong não của người kiểm tra trực quan.

Rất khó để một cặp mắt mới xuất hiện và xác minh tính chính xác của mã đơn giản vì chúng không được hợp tác với bộ não của người viết mã gốc. Chủ sở hữu của cặp mắt thứ hai sẽ phải trò chuyện với tác giả ban đầu của mã để hiểu đầy đủ mã được đề cập. Hội thoại như một phương tiện chia sẻ kiến ​​thức nổi tiếng là không đáng tin cậy. Một điểm không thể khắc phục nếu Bộ giải mã gốc không có sẵn cho đôi mắt mới. Trong trường hợp đó, cặp mắt mới phải đọc mã gốc.

Đọc mã của người khác không nằm trong các bài kiểm tra đơn vị khó hơn đọc mã có các bài kiểm tra đơn vị liên quan. Tốt nhất là đọc mã người khác là công việc khó khăn, tệ nhất là đây là nhiệm vụ khó khăn nhất trong công nghệ phần mềm. Có một lý do mà các nhà tuyển dụng, khi quảng cáo tuyển dụng, nhấn mạnh rằng một dự án là một lĩnh vực xanh (hoặc hoàn toàn mới). Viết mã từ đầu dễ dàng hơn sửa đổi mã hiện có và do đó làm cho công việc được quảng cáo có vẻ hấp dẫn hơn đối với các nhân viên tiềm năng.

Với thử nghiệm đơn vị, chúng tôi chia mã thành các phần thành phần của nó. Đối với mỗi thành phần, sau đó chúng tôi đặt ra gian hàng của chúng tôi nêu cách chương trình nên hoạt động . Mỗi bài kiểm tra đơn vị kể một câu chuyện về cách phần đó của chương trình sẽ hoạt động trong một kịch bản cụ thể. Mỗi bài kiểm tra đơn vị giống như một điều khoản trong hợp đồng mô tả những gì sẽ xảy ra theo quan điểm của mã khách hàng.

Điều này có nghĩa là một cặp mắt mới có hai chuỗi tài liệu trực tiếp và chính xác về mã được đề cập.

Đầu tiên họ có mã, cách thực hiện, cách mã được thực hiện ; thứ hai họ có tất cả kiến ​​thức mà lập trình viên gốc đã mô tả trong một tập hợp các tuyên bố chính thức kể câu chuyện về cách mã này được cho là hành xử.

Kiểm tra đơn vị nắm bắt và mô tả chính thức kiến ​​thức mà tác giả ban đầu sở hữu khi họ thực hiện lớp học. Chúng cung cấp một mô tả về cách lớp đó hành xử khi được sử dụng bởi một khách hàng.

Bạn đúng khi đặt câu hỏi về tính hữu ích của việc này vì có thể viết các bài kiểm tra đơn vị vô dụng, không bao gồm tất cả các mã được đề cập, trở nên cũ hoặc lỗi thời, v.v. Làm thế nào để chúng tôi đảm bảo rằng các bài kiểm tra đơn vị không chỉ bắt chước mà còn cải thiện quá trình của một tác giả có kiến ​​thức, có lương tâm kiểm tra trực quan các câu lệnh đầu ra của mã của họ khi chạy? Viết bài kiểm tra đơn vị trước sau đó viết mã để thực hiện bài kiểm tra đó. Khi bạn kết thúc, hãy để máy tính chạy thử nghiệm, chúng rất nhanh, chúng rất giỏi trong việc thực hiện các nhiệm vụ lặp đi lặp lại, chúng phù hợp lý tưởng với công việc.

Đảm bảo chất lượng kiểm tra bằng cách xem xét chúng mỗi khi bạn tắt mã mà chúng kiểm tra và chạy thử nghiệm cho mỗi bản dựng. Nếu một bài kiểm tra thất bại, sửa chữa nó ngay lập tức.

Chúng tôi tự động hóa quá trình chạy thử nghiệm để chúng được chạy mỗi khi chúng tôi thực hiện xây dựng dự án. Chúng tôi cũng tự động hóa việc tạo các báo cáo bảo hiểm mã chi tiết bao nhiêu phần trăm mã được bao phủ và thực hiện bằng các thử nghiệm. Chúng tôi cố gắng cho tỷ lệ phần trăm cao. Một số công ty sẽ ngăn các thay đổi mã được kiểm tra trong kiểm soát mã nguồn nếu họ không có đủ các bài kiểm tra đơn vị được viết để mô tả bất kỳ thay đổi nào trong hành vi đối với mã. Thông thường, một cặp mắt thứ hai sẽ xem xét các thay đổi mã kết hợp với tác giả của các thay đổi. Người đánh giá sẽ trải qua các thay đổi để đảm bảo rằng các thay đổi có thể hiểu được và được bao phủ đầy đủ bởi các thử nghiệm. Vì vậy, quá trình xem xét là thủ công, nhưng khi các bài kiểm tra (bài kiểm tra đơn vị và tích hợp và có thể là bài kiểm tra chấp nhận của người dùng) vượt qua quy trình xem xét thủ công này, thì nó trở thành một phần của quy trình xây dựng tự động. Chúng được chạy mỗi lần thay đổi được kiểm tra. Ahội nhập liên tục máy chủ thực hiện nhiệm vụ này như là một phần của quá trình xây dựng.

Các thử nghiệm được tự động chạy, duy trì tính toàn vẹn của hành vi của mã và giúp ngăn các thay đổi trong tương lai đối với cơ sở mã phá vỡ mã .

Cuối cùng, việc cung cấp các bài kiểm tra cho phép bạn tích cực tái lập mã yếu tố vì bạn có thể thực hiện các cải tiến mã lớn an toàn với kiến ​​thức rằng các thay đổi của bạn không phá vỡ các kiểm tra hiện có.

Có một sự cảnh báo để kiểm tra hướng phát triển và đó là bạn phải viết mã bằng mắt để làm cho nó có thể kiểm tra được. Điều này liên quan đến việc mã hóa các giao diện và sử dụng các kỹ thuật như Dependency Injection để khởi tạo các đối tượng cộng tác. Kiểm tra công việc của Kent Beck , người mô tả TDD rất tốt. Tra cứu mã hóa đến các giao diện và nghiên cứumẫu thiết kế

Khi bạn kiểm tra bằng cách sử dụng một cái gì đó như System.out, bạn chỉ kiểm tra một tập hợp nhỏ các trường hợp sử dụng có thể. Điều này không triệt để khi bạn xử lý các hệ thống có thể chấp nhận một lượng đầu vào khác nhau vô hạn.

Kiểm tra đơn vị được thiết kế để cho phép bạn nhanh chóng chạy thử nghiệm trên ứng dụng của mình bằng cách sử dụng một bộ dữ liệu đầu vào khác nhau rất lớn và đa dạng. Ngoài ra, các thử nghiệm đơn vị tốt nhất cũng chiếm các trường hợp ranh giới, chẳng hạn như các đầu vào dữ liệu nằm ngay trên cạnh của những gì được coi là hợp lệ.

Đối với một con người để kiểm tra tất cả các đầu vào khác nhau này có thể mất vài tuần trong khi có thể mất vài phút cho một máy.

Hãy nghĩ về nó như thế này: Bạn cũng không "thử nghiệm" thứ gì đó sẽ tĩnh. Ứng dụng của bạn rất có thể sẽ trải qua những thay đổi liên tục. Do đó, các thử nghiệm đơn vị này được thiết kế để chạy ở các điểm khác nhau trong chu trình biên dịch hoặc triển khai. Có lẽ ưu điểm lớn nhất là đây:

Nếu bạn phá vỡ thứ gì đó trong mã của mình, bạn sẽ biết về nó ngay bây giờ , không phải sau khi bạn triển khai, không phải khi người kiểm tra QA bắt lỗi, không phải khi khách hàng của bạn đã hủy. Bạn cũng sẽ có cơ hội tốt hơn để khắc phục sự cố ngay lập tức , vì rõ ràng điều đó đã phá vỡ phần mã được đề cập rất có thể đã xảy ra kể từ lần biên dịch cuối cùng của bạn. Vì vậy, số lượng công việc điều tra cần thiết để khắc phục vấn đề được giảm đáng kể.

Tôi đã thêm một số System.out khác KHÔNG thể làm:

• Làm cho mỗi trường hợp thử nghiệm trở nên độc lập (Điều quan trọng)

  JUnit có thể làm điều đó: mỗi lần trường hợp kiểm thử mới sẽ được tạo và @Befoređược gọi.

• Mã thử nghiệm riêng biệt từ nguồn

  JUnit có thể làm điều đó.

• Tích hợp với CI

  JUnit có thể làm điều đó với Ant và Maven.

• Sắp xếp và kết hợp các trường hợp kiểm tra dễ dàng

  JUnit có thể làm @Ignorevà kiểm tra bộ.

• Dễ dàng kiểm tra kết quả

  JUnit cung cấp nhiều phương thức Khẳng định ( assertEquals, assertSame...)

• Mock và stub làm cho bạn tập trung vào các mô-đun thử nghiệm.

  JUnit có thể làm: Sử dụng mock và stub giúp bạn thiết lập lịch thi đấu chính xác và tập trung vào logic mô-đun kiểm tra.

Kiểm tra đơn vị đảm bảo rằng mã làm việc như dự định. Chúng cũng rất hữu ích để đảm bảo rằng mã vẫn hoạt động như dự định trong trường hợp bạn phải thay đổi nó sau này để xây dựng các chức năng mới để sửa lỗi. Có phạm vi kiểm tra cao về mã của bạn cho phép bạn tiếp tục phát triển các tính năng mà không phải thực hiện nhiều thử nghiệm thủ công.

Cách tiếp cận thủ công của bạn System.outlà tốt nhưng không phải là cách tốt nhất. Đây là lần thử nghiệm duy nhất mà bạn thực hiện. Trong thế giới thực, các yêu cầu liên tục thay đổi và hầu hết thời gian bạn thực hiện rất nhiều sửa đổi cho các chức năng và các lớp hiện có. Vì vậy, không phải mỗi khi bạn kiểm tra đoạn mã đã được viết.

Ngoài ra còn có một số tính năng nâng cao hơn trong JUnit như like

Khẳng định

JUnit cung cấp các phương thức để kiểm tra các điều kiện nhất định, các phương thức này thường bắt đầu bằng các xác nhận và cho phép bạn chỉ định thông báo lỗi, dự kiến ​​và kết quả thực tế

Một số phương pháp này là

1. fail([message])- Cho phép thử nghiệm thất bại. Có thể được sử dụng để kiểm tra rằng một phần nhất định của mã không đạt được. Hoặc để kiểm tra thất bại trước khi mã kiểm tra được thực hiện.
2. assertTrue(true) / assertTrue(false) - Sẽ luôn luôn đúng / sai. Có thể được sử dụng để xác định trước kết quả thử nghiệm, nếu thử nghiệm chưa được thực hiện.
3. assertTrue([message,] condition) - Kiểm tra xem boolean condition có đúng không.
4. assertEquals([message,] expected, actual)- Kiểm tra xem hai giá trị có bằng nhau không (theo equalsphương pháp nếu được thực hiện, nếu không sử dụng ==so sánh tham chiếu). Lưu ý: Đối với mảng, đó là tham chiếu được kiểm tra và không phải nội dung, sử dụngassertArrayEquals([message,] expected, actual) cho điều đó.
5. assertEquals([message,] expected, actual, delta) - Kiểm tra xem hai giá trị float hoặc double nằm trong một khoảng cách nhất định với nhau, được điều khiển bởi delta giá trị.
6. assertNull([message,] object) - Kiểm tra xem đối tượng có null không

và như thế. Xem Javadoc đầy đủ cho tất cả các ví dụ ở đây .

Suites

Với các bộ Test, theo nghĩa nào đó, bạn có thể kết hợp nhiều lớp thử nghiệm thành một đơn vị để bạn có thể thực hiện tất cả chúng cùng một lúc. Một ví dụ đơn giản, kết hợp các lớp kiểm tra MyClassTestvà MySecondClassTestthành một Suite được gọi là AllTests:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ MyClassTest.class, MySecondClassTest.class })
public class AllTests { } 

Ưu điểm chính của JUnit là nó được tự động hóa thay vì bạn phải kiểm tra thủ công với bản in của mình. Mỗi bài kiểm tra bạn viết ở lại với hệ thống của bạn. Điều này có nghĩa là nếu bạn thực hiện một thay đổi có tác dụng phụ không mong muốn, thử nghiệm của bạn sẽ bắt được và thất bại thay vì bạn phải nhớ tự kiểm tra mọi thứ sau mỗi thay đổi.

JUnit là một khung kiểm tra đơn vị cho Ngôn ngữ lập trình Java. Điều này rất quan trọng trong sự phát triển theo hướng thử nghiệm và là một trong những nhóm các khung thử nghiệm đơn vị được gọi chung là xUnit.

JUnit thúc đẩy ý tưởng "thử nghiệm đầu tiên sau đó mã hóa", trong đó nhấn mạnh vào việc thiết lập dữ liệu thử nghiệm cho một đoạn mã có thể được thử nghiệm trước và sau đó có thể được thực hiện. Cách tiếp cận này giống như "kiểm tra một chút, viết mã một chút, kiểm tra một chút, viết mã một chút ..." giúp tăng năng suất lập trình và tính ổn định của mã chương trình giúp giảm căng thẳng cho lập trình viên và thời gian gỡ lỗi.

Tính năng JUnit là một khung công tác mã nguồn mở được sử dụng để viết và chạy thử nghiệm.

Cung cấp chú thích để xác định các phương pháp thử nghiệm.

Cung cấp các xác nhận để thử nghiệm kết quả mong đợi.

Cung cấp người chạy thử nghiệm để chạy thử nghiệm.

Kiểm tra JUnit cho phép bạn viết mã nhanh hơn mà tăng chất lượng

JUnit đơn giản thanh lịch. Nó ít phức tạp hơn và mất ít thời gian hơn.

Các bài kiểm tra JUnit có thể được chạy tự động và họ kiểm tra kết quả của chính họ và cung cấp phản hồi ngay lập tức. Không cần phải chải thủ công thông qua báo cáo kết quả kiểm tra.

Các bài kiểm tra JUnit có thể được tổ chức thành các bộ kiểm thử có chứa các trường hợp kiểm thử và thậm chí các bộ kiểm tra khác.

Junit cho thấy tiến trình kiểm tra trong một thanh màu xanh lá cây nếu thử nghiệm đang diễn ra tốt đẹp và nó chuyển sang màu đỏ khi thử nghiệm thất bại.

Tôi có quan điểm hơi khác nhau về lý do tại sao JUnit là cần thiết.

Bạn thực sự có thể tự viết tất cả các trường hợp kiểm tra nhưng nó cồng kềnh. Đây là những vấn đề:

1. Thay vì System.outchúng ta có thể thêm if(value1.equals(value2))và trả về 0 hoặc -1 hoặc thông báo lỗi. Trong trường hợp này, chúng tôi cần một lớp kiểm tra "chính" chạy tất cả các phương thức này và kiểm tra kết quả và duy trì trường hợp kiểm thử nào thất bại và được thông qua.

2. Nếu bạn muốn thêm một số bài kiểm tra nữa, bạn cũng cần thêm chúng vào lớp kiểm tra "chính" này. Thay đổi mã hiện có. Nếu bạn muốn tự động phát hiện các trường hợp kiểm thử từ các lớp kiểm tra, thì bạn cần sử dụng sự phản chiếu.

3. Tất cả các thử nghiệm của bạn và lớp chính của bạn để chạy thử nghiệm không bị nhật thực phát hiện và bạn cần phải viết các cấu hình gỡ lỗi / chạy tùy chỉnh để chạy các thử nghiệm này. Bạn vẫn không nhìn thấy những đầu ra màu xanh / đỏ đẹp.

Đây là những gì JUnit đang làm:

1. Nó có assertXXX()các phương thức hữu ích để in các thông báo lỗi hữu ích từ các điều kiện và truyền đạt kết quả đến lớp "chính".

2. Lớp "chính" được gọi là người chạy được cung cấp bởi JUnit, vì vậy chúng tôi không phải viết bất kỳ. Và nó tự động phát hiện các phương pháp kiểm tra bằng phản xạ. Nếu bạn thêm các bài kiểm tra mới với @Testchú thích thì chúng sẽ tự động được phát hiện.

3. JUnit cũng tích hợp nhật thực và tích hợp maven / gradle, vì vậy rất dễ để chạy thử nghiệm và bạn sẽ không phải viết cấu hình chạy tùy chỉnh.

Tôi không phải là một chuyên gia trong JUnit, vì vậy đó là những gì tôi hiểu cho đến bây giờ, sẽ bổ sung thêm trong tương lai.

Bạn không thể viết bất kỳ trường hợp thử nghiệm nào mà không sử dụng khung kiểm tra nếu không bạn sẽ phải viết framewok thử nghiệm của mình để đưa ra công lý cho các trường hợp thử nghiệm của bạn. Dưới đây là một số thông tin về JUnit Framework ngoài việc bạn có thể sử dụng khung TestNG.

Junit là gì?

Junit được sử dụng rộng rãi khung thử nghiệm cùng với Ngôn ngữ lập trình Java. Bạn có thể sử dụng khung tự động hóa này cho cả kiểm tra đơn vị và kiểm tra giao diện người dùng. Nó giúp chúng tôi xác định luồng thực thi mã của chúng tôi bằng các Chú thích khác nhau. Junit được xây dựng trên ý tưởng "thử nghiệm đầu tiên và sau đó mã hóa" giúp chúng tôi tăng năng suất của các trường hợp thử nghiệm và tính ổn định của mã.

Các tính năng quan trọng của thử nghiệm Junit -

1. Nó là khung thử nghiệm mã nguồn mở cho phép người dùng viết và chạy các trường hợp thử nghiệm một cách hiệu quả.
2. Cung cấp các loại chú thích khác nhau để xác định phương pháp thử nghiệm.
3. Cung cấp các loại xác nhận khác nhau để xác minh kết quả thực hiện trường hợp thử nghiệm.
4. Nó cũng cung cấp cho người chạy thử nghiệm để chạy thử nghiệm hiệu quả.
5. Nó rất đơn giản và do đó tiết kiệm thời gian.
6. Nó cung cấp các cách để tổ chức các trường hợp thử nghiệm của bạn dưới dạng phù hợp với thử nghiệm.
7. Nó cho kết quả trường hợp thử nghiệm theo cách đơn giản và thanh lịch.
8. Bạn có thể tích hợp jUnit với Eclipse, Android Studio, Maven & Ant, Gradle và Jenkins

JUNIT là phương thức thường được nhà phát triển java chấp nhận. Trường hợp họ có thể cung cấp đầu vào dự kiến ​​tương tự cho hàm và quyết định theo đó mã được viết hoàn hảo hoặc nếu trường hợp thử nghiệm thất bại thì cách tiếp cận khác cũng có thể cần phải thực hiện. JUNIT sẽ làm cho sự phát triển nhanh chóng và sẽ đảm bảo 0 lỗi trong chức năng.

THÁNG 6: QUAN SÁT VÀ ĐIỀU CHỈNH

Đây là quan điểm của tôi về JUNIT.

JUNIT có thể được sử dụng để,
1) Quan sát hành vi hệ thống khi một đơn vị mới được thêm vào trong hệ thống đó.
2) Thực hiện điều chỉnh trong hệ thống để chào đón đơn vị "mới" trong hệ thống.
Gì? Chính xác.

Cuộc sống thực, vd.

Khi người thân của bạn ghé thăm phòng ký túc xá đại học của bạn,
1) Bạn sẽ giả vờ có trách nhiệm hơn.
2) Bạn sẽ giữ tất cả những thứ cần có, như giày trong giá giày không phải trên ghế, quần áo trong tủ không phải trên ghế.
3) Bạn sẽ thoát khỏi tất cả các hàng lậu.
4) bạn sẽ bắt đầu dọn dẹp trong mọi thiết bị bạn sở hữu.

Về mặt lập trình

Hệ thống: Mã của bạn
ĐƠN VỊ: chức năng mới.
Vì khung JUNIT được sử dụng cho ngôn ngữ JAVA nên JUNIT = JAVA UNIT (Có thể).

Giả sử bạn đã có một mã chống đạn tốt, nhưng một yêu cầu mới đã xuất hiện và bạn phải thêm yêu cầu mới trong mã của mình. Yêu cầu mới này có thể phá vỡ mã của bạn cho một số đầu vào (testcase).

Cách dễ dàng để thích ứng với thay đổi này là sử dụng thử nghiệm đơn vị (JUNIT).
Vì vậy, bạn nên viết nhiều testcase cho mã của mình khi bạn đang xây dựng cơ sở mã của mình. Và bất cứ khi nào một yêu cầu mới xuất hiện, bạn chỉ cần chạy tất cả các trường hợp thử nghiệm để xem có trường hợp thử nghiệm nào thất bại không. Nếu Không thì bạn là một nghệ sĩ BadA ** và bạn đã sẵn sàng triển khai mã mới.
Nếu bất kỳ testcase nào thất bại thì bạn thay đổi mã của mình và chạy lại testcase cho đến khi bạn nhận được trạng thái màu xanh lá cây.