Xác nhận nhiều điều kiện trong một thử nghiệm đơn lẻ hoặc chia thành nhiều thử nghiệm?

Question

Nếu bạn đang thử nghiệm một hàm đếm giống như dưới đây, nó được coi là 'đúng' hoặc 'sai' để kiểm tra nhiều thứ cho hàm trong một hàm và có hàm kiểm tra cho mỗi thử nghiệm không?

function testGetKeywordCount() { 
    $tester = $this -> getDatabaseTester($this -> CompleteDataFile); 
    $tester -> onSetUp(); 

    $KeywordID = 0; 
    $this -> setExpectedException('InvalidArgumentException'); 
    $this -> keyword -> getKeywordCount($KeywordID,'Active'); 

    $KeywordID = 1; 
    $this -> setExpectedException('InvalidArgumentException'); 
    $this -> keyword -> getKeywordCount($KeywordID,'InvalidStatus'); 

    $this -> assertEquals(1, $this -> keyword -> getKeywordCount($KeywordID,'Active')); 

    $tester -> onTearDown(); 
} 

Answer 1

Bạn nên có nhiều chức năng kiểm tra, trong đó mỗi chức năng kiểm tra điều kiện riêng của nó. Bằng cách đó, nó dễ dàng hơn để phát hiện ra một sự thất bại mà không cần gỡ lỗi.

Answer 2

Có một trường hợp thử nghiệm cho từng trường hợp là lý tưởng. Tuy nhiên, trong một số trường hợp, nó thuận tiện hơn (hiệu quả từ quan điểm thực hiện nỗ lực xem) để kiểm tra nhiều hơn một kịch bản trong một trường hợp thử nghiệm. Nếu bạn sử dụng một khuôn khổ không dừng lại trên lần đầu tiên thất bại, nhưng cố gắng thực hiện càng nhiều càng tốt trong một trường hợp thử nghiệm, khung đó là thích hợp cho nhiều kịch bản cho mỗi trường hợp thử nghiệm.

Tôi muốn dành ít thời gian nhất có thể cho thử nghiệm đơn vị và vẫn nhận được mức độ phù hợp nhất có thể trong thời gian đó.

Cuối cùng, điều quan trọng là bạn phải thực hiện bài kiểm tra đơn vị như thế nào, nhưng tính chính xác hơn của các bài kiểm tra đó.

Answer 3

Các khuôn khổ thử nghiệm không phải lúc nào cũng làm cho bạn xứng đáng với nỗ lực của bạn để thực hiện theo một xác nhận cho mỗi quy tắc thử nghiệm.

Một trong số đó là RSpec cho Ruby, cho phép bạn thiết lập nested example groups. Ví dụ:

• Một tài
  • không có mật khẩu
    • không hợp lệ
    • ném ngoại lệ
  • với một mật khẩu
    • đã được sử dụng trước
      • không hợp lệ
      • ném ngoại lệ
      • chuyến đi cảnh báo bảo mật
    • mà không được sử dụng trước đó
      • là hợp lệ
      • chuyển hướng đến trang tài khoản

Bằng dần dần xây dựng kịch bản và thử nghiệm từng bước trên đường đi, nó dễ dàng hơn để dính vào một sự khẳng định cho mỗi phương pháp kiểm tra. Nó cũng làm cho nó dễ dàng hơn để phát hiện các kịch bản chưa được kiểm tra.

Answer 4

Tôi sẽ không nói về bài kiểm tra Đơn vị trong mã ví dụ của bạn ở trên.
Ví dụ của bạn là một thử nghiệm chức năng tự động hơn, kiểm tra dòng chảy của các hàm.

NHƯNG Trong trường hợp này, bạn có nhiều xác nhận.

Chỉ cần đảm bảo rằng 2 xác nhận không nằm phía sau mục còn lại.

Bad dụ

public void ValidateRulesEntry_Valid_ValidConditionsFromFile() 
{ 
    string condition = "Target.HasValue"; 
    string returnMessage; 

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage); 


    Assert.IsTrue(successFul); 
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage)); 
    Assert.IsTrue(returnMessage == "OK"); 

} 

Các khẳng định cuối cùng 2 phụ thuộc của sự khẳng định 1 IsTrue (thành công).

Hãy suy nghĩ về: Nếu thử nghiệm thất bại -> Nói cho tôi biết tại sao (mà không nhìn vào sản lượng Debug)

Answer 5

Một lập luận cho việc tách các khẳng định vào hai bài kiểm tra riêng biệt là, nếu một trong các khẳng định thất bại, bạn' sẽ nhận được một thất bại; nếu cả hai xác nhận không thành công, bạn sẽ nhận được hai lỗi.

Ngoài ra, bằng cách đặt tên cho mỗi bài kiểm tra càng gợi ý càng tốt, bạn sẽ nhận được thêm manh mối khi có điều gì đó bị hỏng.

Answer 6

Đây là câu hỏi có câu trả lời khác nhau tùy thuộc vào người bạn hỏi và phụ thuộc chủ yếu vào ý kiến ​​cá nhân hoặc kinh nghiệm chuyên môn của họ. Một số người lý thuyết siêu sẽ cho bạn biết rằng có nhiều hơn một khẳng định trong một thử nghiệm là một tội lỗi tối cao và bạn sẽ phải chịu số phận mãi mãi. Nhưng những người khác có nhiều kinh nghiệm thực tế hơn có thể cho bạn biết rằng có những tình huống khi nó hoàn toàn tốt để có 10 hoặc thậm chí 50 khẳng định cho mỗi thử nghiệm.

Vì vậy, ai là đúng?

Tôi luôn cố gắng đạt mục tiêu khi đối mặt với loại dilemas này, và quyết định thực hiện một nghiên cứu nhỏ với một số repo github phổ biến nhất hiện đang được phát triển bởi các chuyên gia có kinh nghiệm và được chứng nhận.

Vì vậy, người chơi lớn thử nghiệm các dự án của riêng mình như thế nào? Và quan trọng hơn, các đơn vị thử nghiệm đơn vị được kiểm tra như thế nào?

Hãy xem một vài ví dụ:

Hibernate

https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/EntityEntryTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/NonSortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/SortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-envers/src/test/java/org/hibernate/envers/test/JpaStaticMetamodelTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-hikaricp/src/test/java/org/hibernate/test/hikaricp/HikariCPConnectionProviderTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-proxool/src/test/java/org/hibernate/test/proxool/ProxoolConnectionProviderTest.java

Xuân

https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/AntPathMatcherTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/ClassUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/ObjectUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/AutoPopulatingListTests.java

JUnit 4

https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/extensions/ActiveTestTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/extensions/RepeatedTestTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/runner/ResultTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/org/junit/rules/TimeoutRuleTest.java

junit 5

https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/DefaultLauncherTests.java https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilderTests.java https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/listener/SummaryGenerationTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test/java/org/junit/jupiter/engine/StandardTestClassTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test/java/org/junit/jupiter/engine/DiscoveryFilterApplierTests.java

Google Truth

https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/DoubleSubjectTest.java https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/BigDecimalSubjectTest.java https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/DoubleSubjectTest.java

Như chúng ta có thể thấy trong các ví dụ trên, các nhà phát triển chuyên nghiệp dường như không quan tâm nhiều về điều răn khẳng định duy nhất. Trong thực tế, họ phá vỡ quy tắc này hầu hết thời gian và có vẻ như họ hoàn toàn ổn với nó. Có lẽ họ bỏ qua nó bởi vì nó không phải là một quy tắc nghiêm ngặt mà chỉ là một khuyến nghị. Điều đáng nói là ngay cả các khuôn khổ thử nghiệm đơn vị kiểm tra bản thân với nhiều hơn một khẳng định cho mỗi thử nghiệm hầu hết thời gian.

Vì vậy, kết luận của tôi là rõ ràng: Về mối quan tâm này, nó là hoàn toàn hợp lệ để có càng nhiều khẳng định như bạn muốn trong một thử nghiệm duy nhất. Nếu các nhà phát triển chuyên nghiệp đang làm điều đó, bạn cũng có thể làm điều đó.