Tôi biết rằng một cách để làm điều đó sẽ là:

@Test
public void foo(){
   try{
      //execute code that you expect not to throw Exceptions.
   }
   catch(Exception e){
      fail("Should not have thrown any exception");
   }
}

Có cách nào sạch hơn để làm điều này. (Có lẽ là sử dụng Junit @Rule?)

Bạn đang tiếp cận điều này sai cách. Chỉ cần kiểm tra chức năng của bạn: nếu ném ngoại lệ, kiểm tra sẽ tự động thất bại. Nếu không có ngoại lệ được ném, tất cả các bài kiểm tra của bạn sẽ chuyển sang màu xanh lá cây.

Thỉnh thoảng tôi nhận thấy câu hỏi này thu hút sự quan tâm vì vậy tôi sẽ mở rộng thêm một chút.

Bối cảnh để kiểm tra đơn vị

Khi bạn kiểm tra đơn vị, điều quan trọng là xác định cho chính bạn những gì bạn coi là một đơn vị công việc. Về cơ bản: trích xuất cơ sở mã của bạn có thể bao gồm hoặc không bao gồm nhiều phương thức hoặc lớp đại diện cho một phần chức năng.

Hoặc, như được định nghĩa trong Nghệ thuật kiểm tra đơn vị, Ấn bản thứ 2 của Roy Osherove , trang 11:

Một thử nghiệm đơn vị là một mảnh tự động mã mà gọi các đơn vị của công việc đang được thử nghiệm, và sau đó kiểm tra một số giả định về một kết quả cuối cùng duy nhất của đơn vị đó. Một bài kiểm tra đơn vị hầu như luôn được viết bằng khung kiểm tra đơn vị. Nó có thể được viết dễ dàng và chạy nhanh. Nó đáng tin cậy, có thể đọc và duy trì. Nó phù hợp với kết quả của nó miễn là mã sản xuất không thay đổi.

Điều quan trọng cần nhận ra là một đơn vị công việc thường không chỉ là một phương thức mà ở cấp độ rất cơ bản, đó là một phương thức và sau đó nó được gói gọn bởi một đơn vị công việc khác.

Tốt nhất bạn nên có một phương pháp kiểm tra cho từng đơn vị công việc riêng biệt để bạn luôn có thể xem ngay lập tức mọi thứ đang xảy ra. Trong ví dụ này, có một phương thức cơ bản được gọi là getUserById()sẽ trả về người dùng và có tổng cộng 3 đơn vị công việc.

Đơn vị công việc đầu tiên nên kiểm tra xem người dùng hợp lệ có được trả lại hay không trong trường hợp đầu vào hợp lệ và không hợp lệ.
Bất kỳ trường hợp ngoại lệ nào đang bị ném bởi nguồn dữ liệu phải được xử lý ở đây: nếu không có người dùng nào xuất hiện, cần có một thử nghiệm chứng minh rằng một ngoại lệ được ném khi không thể tìm thấy người dùng. Một mẫu của điều này có thể là IllegalArgumentExceptioncái được bắt với @Test(expected = IllegalArgumentException.class)chú thích.

Khi bạn đã xử lý tất cả các giai đoạn của bạn cho đơn vị công việc cơ bản này, bạn tiến lên một cấp độ. Ở đây bạn làm chính xác như vậy, nhưng bạn chỉ xử lý các ngoại lệ xuất phát từ cấp độ ngay bên dưới mức hiện tại. Điều này giữ cho mã kiểm tra của bạn có cấu trúc tốt và cho phép bạn nhanh chóng chạy qua kiến ​​trúc để tìm nơi xảy ra sự cố, thay vì phải nhảy khắp nơi.

Xử lý đầu vào bị lỗi và hợp lệ của bài kiểm tra

Tại thời điểm này, rõ ràng chúng ta sẽ xử lý những ngoại lệ này như thế nào. Có 2 loại đầu vào: đầu vào hợp lệ và đầu vào bị lỗi (đầu vào hợp lệ theo nghĩa chặt chẽ, nhưng nó không chính xác).

Khi bạn làm việc với đầu vào hợp lệ, bạn sẽ đặt kỳ vọng ngầm định rằng bất kỳ bài kiểm tra nào bạn viết, sẽ hoạt động.

Một cuộc gọi phương thức như vậy có thể trông như thế này : existingUserById_ShouldReturn_UserObject. Nếu phương pháp này thất bại (ví dụ: một ngoại lệ được ném) thì bạn biết có gì đó không ổn và bạn có thể bắt đầu đào.

Bằng cách thêm một thử nghiệm khác ( nonExistingUserById_ShouldThrow_IllegalArgumentException) sử dụng đầu vào bị lỗi và mong đợi một ngoại lệ, bạn có thể biết liệu phương thức của mình có thực hiện đúng với đầu vào sai hay không.

TL; DR

Bạn đã cố gắng thực hiện hai điều trong bài kiểm tra của mình: kiểm tra đầu vào hợp lệ và bị lỗi. Bằng cách chia phương pháp này thành hai phương pháp mà mỗi phương pháp thực hiện một việc, bạn sẽ có các bài kiểm tra rõ ràng hơn nhiều và tổng quan tốt hơn nhiều về những điều sai lầm.

Bằng cách ghi nhớ đơn vị phân lớp của các tác phẩm, bạn cũng có thể giảm số lượng bài kiểm tra bạn cần cho một lớp cao hơn trong hệ thống phân cấp vì bạn không phải tính đến mọi điều có thể sai ở các lớp thấp hơn: các lớp bên dưới lớp hiện tại là một đảm bảo ảo rằng các phần phụ thuộc của bạn hoạt động và nếu có lỗi xảy ra, nó nằm trong lớp hiện tại của bạn (giả sử các lớp thấp hơn không tự ném bất kỳ lỗi nào).

Tôi vấp phải điều này vì quy tắc "mực: S2699" của SonarQube: "Thêm ít nhất một khẳng định vào trường hợp thử nghiệm này."

Tôi đã có một bài kiểm tra đơn giản với mục tiêu duy nhất là vượt qua mà không đưa ra ngoại lệ.

Hãy xem xét mã đơn giản này:

public class Printer {

    public static void printLine(final String line) {
        System.out.println(line);
    }
}

Những loại khẳng định có thể được thêm vào để kiểm tra phương pháp này? Chắc chắn, bạn có thể thực hiện một thử bắt xung quanh nó, nhưng đó chỉ là sự phình to mã.

Giải pháp đến từ chính JUnit.

Trong trường hợp không có ngoại lệ nào được đưa ra và bạn muốn minh họa rõ ràng hành vi này, chỉ cần thêm expectednhư trong ví dụ sau:

@Test(expected = Test.None.class /* no exception expected */)
public void test_printLine() {
    Printer.printLine("line");
}

Test.None.class là mặc định cho giá trị mong đợi.

Với các xác nhận thông thạo AssertJ 3.7.0 :

Assertions.assertThatCode(() -> toTest.method())
    .doesNotThrowAnyException();

JUnit 5 (Sao Mộc) cung cấp ba chức năng để kiểm tra sự vắng mặt / hiện diện ngoại lệ:

● assertAll​()

  Khẳng định rằng tất cả các cung cấp executables
  không ném ngoại lệ.

● assertDoesNotThrow​()

  Khẳng định rằng việc thực thi
  được cung cấp executable/ supplier
  không ném bất kỳ loại ngoại lệ nào .

  Chức năng này có sẵn
  kể từ JUnit 5.2.0 (29 tháng 4 năm 2018).

● assertThrows​()

  Khẳng định rằng việc thực thi được cung cấp executable
  sẽ ném ngoại lệ expectedType
  và trả về ngoại lệ đó .

Thí dụ

package test.mycompany.myapp.mymodule;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class MyClassTest {

    @Test
    void when_string_has_been_constructed_then_myFunction_does_not_throw() {
        String myString = "this string has been constructed";
        assertAll(() -> MyClass.myFunction(myString));
    }

    @Test
    void when_string_has_been_constructed_then_myFunction_does_not_throw__junit_v520() {
        String myString = "this string has been constructed";
        assertDoesNotThrow(() -> MyClass.myFunction(myString));
    }

    @Test
    void when_string_is_null_then_myFunction_throws_IllegalArgumentException() {
        String myString = null;
        assertThrows(
            IllegalArgumentException.class,
            () -> MyClass.myFunction(myString));
    }

}

Java 8 làm cho điều này dễ dàng hơn nhiều và Kotlin / Scala gấp đôi như vậy.

Chúng ta có thể viết một lớp tiện ích nhỏ

class MyAssertions{
  public static void assertDoesNotThrow(FailingRunnable action){
    try{
      action.run()
    }
    catch(Exception ex){
      throw new Error("expected action not to throw, but it did!", ex)
    }
  }
}

@FunctionalInterface interface FailingRunnable { void run() throws Exception }

và sau đó mã của bạn trở nên đơn giản:

@Test
public void foo(){
  MyAssertions.assertDoesNotThrow(() -> {
    //execute code that you expect not to throw Exceptions.
  }
}

Nếu bạn không có quyền truy cập vào Java-8, tôi sẽ sử dụng một tiện ích java cũ kỹ: các khối mã aribitrary và một nhận xét đơn giản

//setup
Component component = new Component();

//act
configure(component);

//assert 
/*assert does not throw*/{
  component.doSomething();
}

Và cuối cùng, với kotlin, một ngôn ngữ mà gần đây tôi đã yêu:

fun (() -> Any?).shouldNotThrow() 
    = try { invoke() } catch (ex : Exception){ throw Error("expected not to throw!", ex) }

@Test fun `when foo happens should not throw`(){

  //...

  { /*code that shouldn't throw*/ }.shouldNotThrow()
}

Mặc dù có rất nhiều chỗ để tìm hiểu chính xác cách bạn muốn thể hiện điều này, tôi luôn là một người hâm mộ của những xác nhận trôi chảy .

Về

Bạn đang tiếp cận điều này sai cách. Chỉ cần kiểm tra chức năng của bạn: nếu ném ngoại lệ, kiểm tra sẽ tự động thất bại. Nếu không có ngoại lệ được ném, tất cả các bài kiểm tra của bạn sẽ chuyển sang màu xanh lá cây.

Điều này đúng về nguyên tắc nhưng không chính xác trong kết luận.

Java cho phép các ngoại lệ cho luồng điều khiển. Điều này được thực hiện bởi chính bộ thực thi JRE trong các API như Double.parseDoublethông qua a NumberFormatExceptionvà Paths.getthông qua a InvalidPathException.

Do bạn đã viết một thành phần xác thực các chuỗi Số cho Double.ParseDouble, có thể sử dụng Regex, có thể là trình phân tích cú pháp viết tay hoặc có thể là một thứ gì đó nhúng một số quy tắc miền khác giới hạn phạm vi gấp đôi thành một thứ cụ thể, cách tốt nhất để kiểm tra điều này thành phần nào? Tôi nghĩ rằng một thử nghiệm rõ ràng sẽ là để khẳng định rằng, khi chuỗi kết quả được phân tích cú pháp, không có ngoại lệ nào được đưa ra. Tôi sẽ viết bài kiểm tra đó bằng cách sử dụng ở trên assertDoesNotThrowhoặc /*comment*/{code}khối. Cái gì đó như

@Test public void given_validator_accepts_string_result_should_be_interpretable_by_doubleParseDouble(){
  //setup
  String input = "12.34E+26" //a string double with domain significance

  //act
  boolean isValid = component.validate(input)

  //assert -- using the library 'assertJ', my personal favourite 
  assertThat(isValid).describedAs(input + " was considered valid by component").isTrue();
  assertDoesNotThrow(() -> Double.parseDouble(input));
}

Tôi cũng khuyến khích bạn tham số hóa thử nghiệm này inputbằng cách sử dụng Theorieshoặc Parameterizedđể bạn có thể dễ dàng sử dụng lại thử nghiệm này cho các đầu vào khác. Ngoài ra, nếu bạn muốn trở nên kỳ lạ, bạn có thể sử dụng một công cụ tạo thử nghiệm (và cái này ). TestNG có hỗ trợ tốt hơn cho các bài kiểm tra tham số.

Điều tôi thấy đặc biệt không đồng ý là khuyến nghị sử dụng @Test(expectedException=IllegalArgumentException.class), ngoại lệ này rất nguy hiểm . Nếu mã của bạn thay đổi sao cho thành phần trong hàm tạo của thử nghiệm có if(constructorArgument <= 0) throw IllegalArgumentException()và thử nghiệm của bạn cung cấp 0 cho đối số đó vì nó thuận tiện - và điều này rất phổ biến, vì dữ liệu thử nghiệm tạo tốt là một vấn đề khó khăn đáng ngạc nhiên--, thì thử nghiệm của bạn sẽ là thanh màu xanh mặc dù nó không kiểm tra gì cả. Một bài kiểm tra như vậy là tồi tệ hơn vô dụng.

Nếu bạn không đủ may mắn để bắt tất cả các lỗi trong mã của bạn. Bạn có thể ngu ngốc làm

class DumpTest {
    Exception ex;
    @Test
    public void testWhatEver() {
        try {
            thisShouldThrowError();
        } catch (Exception e) {
            ex = e;
        }
        assertEquals(null,ex);
    }
}

JUnit5 thêm phương thức assertAll () cho mục đích chính xác này.

assertAll( () -> foo() )

nguồn: API JUnit 5

Mặc dù bài viết này đã được 6 tuổi, tuy nhiên, rất nhiều điều đã thay đổi trong thế giới Junit. Với Junit5, giờ bạn có thể sử dụng

org.junit.jupiter.api.Assertions.assertDoesNotThrow()

Ví dụ:

public void thisMethodDoesNotThrowException(){
   System.out.println("Hello There");
}

@Test
public void test_thisMethodDoesNotThrowException(){
  org.junit.jupiter.api.Assertions.assertDoesNotThrow(
      ()-> thisMethodDoesNotThrowException()
    );
}

Hy vọng nó sẽ giúp những người đang sử dụng phiên bản mới hơn của Junit5

Nếu bạn muốn kiểm tra xem liệu mục tiêu thử nghiệm của bạn có tiêu thụ ngoại lệ hay không. Chỉ cần để lại thử nghiệm là (cộng tác viên giả bằng jMock2):

@Test
public void consumesAndLogsExceptions() throws Exception {

    context.checking(new Expectations() {
        {
            oneOf(collaborator).doSth();
            will(throwException(new NullPointerException()));
        }
    });

    target.doSth();
 }

Thử nghiệm sẽ vượt qua nếu mục tiêu của bạn tiêu thụ ngoại lệ, nếu không thử nghiệm sẽ thất bại.

Nếu bạn muốn kiểm tra logic tiêu thụ ngoại lệ của mình, mọi thứ trở nên phức tạp hơn. Tôi đề nghị ủy thác tiêu thụ cho một cộng tác viên có thể bị chế giễu. Do đó, bài kiểm tra có thể là:

@Test
public void consumesAndLogsExceptions() throws Exception {
    Exception e = new NullPointerException();
    context.checking(new Expectations() {
        {
            allowing(collaborator).doSth();
            will(throwException(e));

            oneOf(consumer).consume(e);
        }
    });

    target.doSth();
 }

Nhưng đôi khi nó được thiết kế quá mức nếu bạn chỉ muốn đăng nhập nó. Trong trường hợp này, bài viết này ( http://java.dzone.com/articles/monitoring-declarative-transac , http://blog.novoj.net/2008/09/20/testing-aspect-pointcut-is-there -an-easy-way / ) có thể giúp đỡ nếu bạn khăng khăng tdd trong trường hợp này.

Sử dụng assertNull (...)

@Test
public void foo() {
    try {
        //execute code that you expect not to throw Exceptions.
    } catch (Exception e){
        assertNull(e);
    }
}

Bạn có thể mong đợi rằng ngoại lệ không bị ném bằng cách tạo quy tắc.

@Rule
public ExpectedException expectedException = ExpectedException.none();

Đây có thể không phải là cách tốt nhất nhưng nó chắc chắn đảm bảo rằng ngoại lệ không bị ném ra khỏi khối mã đang được thử nghiệm.

import org.assertj.core.api.Assertions;
import org.junit.Test;

public class AssertionExample {

    @Test
    public void testNoException(){
        assertNoException();
    }    

    private void assertException(){
        Assertions.assertThatThrownBy(this::doNotThrowException).isInstanceOf(Exception.class);
    }

    private void assertNoException(){
        Assertions.assertThatThrownBy(() -> assertException()).isInstanceOf(AssertionError.class);
    }

    private void doNotThrowException(){
        //This method will never throw exception
    }
}

Bạn có thể làm điều đó bằng cách sử dụng @Rule và sau đó gọi phương thức reportMissingExceptionWithMessage như dưới đây: Đây là mã Scala.

Sau đây không kiểm tra tất cả các trường hợp ngoại lệ, được kiểm tra hoặc không được kiểm tra:

@Test
public void testMyCode() {

    try {
        runMyTestCode();
    } catch (Throwable t) {
        throw new Error("fail!");
    }
}

Bạn có thể tạo bất kỳ loại xác nhận nào của mình dựa trên các xác nhận từ Junit:

static void assertDoesNotThrow(Executable executable) {
    assertDoesNotThrow(executable, "must not throw");
}
static void assertDoesNotThrow(Executable executable, String message) {
    try {
        executable.execute();
    } catch (Throwable err) {
        fail(message);
    }
}

Và kiểm tra:

//the following will succeed
assertDoesNotThrow(()->methodMustNotThrow(1));
assertDoesNotThrow(()->methodMustNotThrow(1), "fail with specific message: facepalm");
//the following will fail
assertDoesNotThrow(()->methodMustNotThrow(2));
assertDoesNotThrow(()-> {throw new Exception("Hello world");}, "Fail: must not trow");

Nói chung, có khả năng thất bại ngay lập tức ("bla bla bla") thử nghiệm trong bất kỳ tình huống nào, ở bất kỳ nơi nào có ý nghĩa. Chẳng hạn, sử dụng nó trong khối thử / bắt để thất bại nếu có bất cứ thứ gì được ném trong trường hợp thử nghiệm:

try{methodMustNotThrow(1);}catch(Throwable e){fail("must not throw");}
//or
try{methodMustNotThrow(1);}catch(Throwable e){Assertions.fail("must not throw");}

Đây là mẫu của phương pháp mà chúng tôi kiểm tra, giả sử chúng tôi có một phương pháp như vậy không được thất bại trong các trường hợp cụ thể, nhưng nó có thể thất bại:

void methodMustNotThrow(int x) throws Exception{
    if (x == 1) return;
    throw new Exception();
}

Phương pháp trên là một mẫu đơn giản. Nhưng điều này hoạt động cho các tình huống phức tạp, trong đó sự thất bại không quá rõ ràng. Có hàng nhập khẩu:

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.function.Executable;
import static org.junit.jupiter.api.Assertions.*;