Natknąłem się na to z powodu Zasady SonarQube "squid: S2699": "Dodaj przynajmniej jedno twierdzenie do tego przypadku testowego."

Miałem prosty test, którego jedynym celem było przejść bez rzucania WYJĄTKÓW.

Rozważ ten prosty kod:

public class Printer {

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

Jaki rodzaj twierdzenia można dodać, aby przetestować tę metodę? Jasne, można spróbować złapać wokół niego, ale to jest tylko kod nadęty.

W przypadku, gdy żaden wyjątek nie zostanie wyrzucony, a Ty aby wyraźnie zobrazować to zachowanie, po prostu dodaj expected jak w poniższym przykładzie:

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

Test.None.class jest wartością domyślną dla wartości oczekiwanej.

JUnit 5 (Jupiter) udostępnia trzy funkcje do sprawdzania nieobecności/obecności WYJĄTKÓW:

● assertAll​()

twierdzenia , że Wszystkie dostarczone executables
  nie rzucaj WYJĄTKÓW.

● assertDoesNotThrow​()

zapewnia , że wykonanie
  dostarczony executable/supplier
  Nie Rzuca żadnego rodzaju wyjątku .

Ta funkcja jest dostępne
  od JUnit 5.2.0 (29 kwietnia 2018).

● assertThrows​()

twierdzenia , że wykonanie dostarczonego executable
  wyjątek od expectedType
  i zwraca wyjątek .

Przykład

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));
    }

}

Z twierdzeniami 3.7.0:

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

Java 8 sprawia, że jest to dużo łatwiejsze, a Kotlin / Scala podwójnie.

Możemy napisać małą klasę użyteczności

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 }

I wtedy twój kod staje się po prostu:

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

Jeśli nie masz dostępu do Java-8, użyłbym boleśnie starego obiektu java: aribitrary bloków kodu i prosty komentarz

//setup
Component component = new Component();

//act
configure(component);

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

I wreszcie, z kotlinem, językiem, w którym ostatnio się zakochałam:

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()
}

Choć jest dużo miejsca, aby bawić się dokładnie tak, jak chcesz wyrażaj to, zawsze byłem fanem płynnych twierdzeń.

Odnośnie

Podchodzisz do tego w złą stronę. Po prostu przetestuj swoją funkcjonalność: jeśli zostanie wyrzucony wyjątek, test automatycznie się nie powiedzie. Jeśli żaden wyjątek nie zostanie wyrzucony, wszystkie testy zmienią kolor na zielony.

Jest to zasadniczo poprawne, ale błędne w konkluzji.

Java dopuszcza wyjątki dla przepływu sterowania. Odbywa się to przez samo środowisko uruchomieniowe JRE w interfejsach API, takich jak Double.parseDouble przez a NumberFormatException i Paths.get przez a InvalidPathException.

Biorąc pod uwagę, że napisałeś komponent, który waliduje ciągi liczb dla Double.ParseDouble, może używając Regex, może ręcznie pisanego parsera, a może czegoś, co osadza inne reguły domeny, które ograniczają zakres podwójnego do czegoś konkretnego, jak najlepiej przetestować ten komponent? Myślę, że oczywistym testem byłoby stwierdzenie, że gdy wynikowy ciąg jest parsowany, żaden wyjątek nie jest wyrzucany. Napisałbym ten test używając albo powyższego assertDoesNotThrow albo /*comment*/{code} blok. Coś jak

@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));
}

Zachęcam również do parametryzacji tego testu na input za pomocą Theories lub Parameterized tak, że można łatwiej ponownie użyć tego testu dla innych wejść. Alternatywnie, jeśli chcesz przejść egzotyczne, możesz wybrać narzędzie do generowania testów (i to ). TestNG ma lepsze wsparcie dla testów parametryzowanych.

To, co uważam za szczególnie nieprzyjemne, to zalecenie użycia @Test(expectedException=IllegalArgumentException.class), to wyjątek jest niebezpiecznie szeroki . Jeśli twój kod zmieni się tak, że komponent testowy ma if(constructorArgument <= 0) throw IllegalArgumentException(), a twój test dostarczał 0 dla tego argumentu, ponieważ był wygodny-i jest to bardzo powszechne, ponieważ dobre generowanie danych testowych jest zaskakująco trudnym problemem -, wtedy twój test będzie zielony pasek, nawet jeśli nie testuje niczego. Taki test jest gorszy niż bezużyteczny.

Jeśli masz pecha wychwycić wszystkie błędy w kodzie. Możesz głupio zrobić

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

Chociaż ten post ma już 6 lat, jednak wiele się zmieniło w świecie Junit. Z Junit5 możesz teraz użyć

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

Ex:

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

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

Mam nadzieję, że pomoże to osobom używającym nowszej wersji Junit5

JUnit5 dodaje do tego celu metodę assertAll ().

assertAll( () -> foo() )

Źródło: JUnit 5 API

Aby przetestować scenariusz za pomocą metody void, takiej jak

void testMeWell() throws SomeException {..}

To not throw an exception:

Junit5

assertDoesNotThrow(() -> {
    testMeWell();
});

Use assertNull(...)

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

Jeśli chcesz sprawdzić, czy twój cel testowy zużywa wyjątek. Po prostu zostaw test jako (mock collaborator using jMock2):

@Test
public void consumesAndLogsExceptions() throws Exception {

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

    target.doSth();
 }

Test przejdzie, jeśli twój cel pochłonie wyrzucony wyjątek, w przeciwnym razie test się nie powiedzie.

Jeśli chcesz przetestować swoją logikę konsumpcji WYJĄTKÓW, sprawy stają się bardziej złożone. Proponuję powierzyć konsumpcję kolaborantowi, który mógłby być wyśmiany. Zatem test może być:

@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();
 }

Możesz oczekiwać, że wyjątek nie zostanie wyrzucony przez utworzenie reguły.

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

To może nie być najlepszy sposób, ale zdecydowanie upewnia się, że wyjątek nie jest wyrzucany z testowanego bloku kodu.

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
    }
}

Możesz to zrobić za pomocą reguły@, a następnie wywołać metodę reportMissingExceptionWithMessage, jak pokazano poniżej: To jest kod Scala.

Stanąłem w tej samej sytuacji, musiałem sprawdzić, czy wyjątek jest wyrzucany wtedy, kiedy powinien i tylko wtedy, gdy powinien. Skończyło się na użyciu obsługi wyjątków na moją korzyść z następującym kodem:

    try {
        functionThatMightThrowException()
    }catch (Exception e){
        Assert.fail("should not throw exception");
    }
    RestOfAssertions();

Główną korzyścią dla mnie było to, że jest to całkiem proste i sprawdzić drugą stronę "jeśli i tylko jeśli" jest naprawdę łatwe w tej samej strukturze

Możesz tworzyć dowolne własne twierdzenia na podstawie twierdzeń z 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);
    }
}

I test:

//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");

Ogólnie rzecz biorąc, istnieje możliwość natychmiastowego niepowodzenia("bla bla bla") testu w dowolnym scenariuszu, w dowolnym miejscu, w którym ma to sens. Na przykład użyj go w bloku try/catch, aby zawieść, jeśli coś zostanie rzucone w przypadku testu:

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

To jest próbka metody, którą testujemy, przypuśćmy, że mamy taką metodę, która nie może zawieść w określonych okolicznościach, ale może się nie udać:

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

Powyższa metoda jest prostą próbką. Ale to działa w złożonych sytuacjach, gdzie awaria nie jest tak oczywiste. Są importowane:

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.*;

Poniższy test nie sprawdza wszystkich wyjątków, zaznaczonych lub niezaznaczonych:

@Test
public void testMyCode() {

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