Wiem, że jednym ze sposobów jest:

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

Czy jest na to lepszy sposób? (Prawdopodobnie używasz Junita @Rule?)

Podchodzisz do tego niewłaściwie. Po prostu przetestuj swoją funkcjonalność: jeśli zostanie zgłoszony wyjątek, test automatycznie się nie powiedzie. Jeśli nie zostanie zgłoszony żaden wyjątek, wszystkie testy zmienią kolor na zielony.

Od czasu do czasu zauważyłem, że to pytanie wzbudza zainteresowanie, więc trochę poszerzę.

Tło do testów jednostkowych

Podczas testowania jednostkowego ważne jest, aby określić, co uważasz za jednostkę pracy. Zasadniczo: ekstrakcja bazy kodu, która może, ale nie musi zawierać wiele metod lub klas reprezentujących jeden element funkcjonalności.

Lub, zgodnie z definicją w The Art of Unit Testing, 2nd Edition Roy Osherove , strona 11:

Testów jednostkowych jest zautomatyzowany kawałek kodu, który wywołuje jednostka pracy testowane, a następnie sprawdza pewne założenia dotyczące pojedynczego wyniku końcowym tej jednostki. Test jednostkowy prawie zawsze jest pisany przy użyciu frameworka testowego. Można go łatwo napisać i działa szybko. Jest godny zaufania, czytelny i łatwy w utrzymaniu. Jest spójny w wynikach, o ile kod produkcyjny się nie zmienił.

Ważne jest, aby zdawać sobie sprawę, że jedna jednostka pracy zwykle nie jest tylko jedną metodą, ale na bardzo podstawowym poziomie jest jedną metodą, a następnie jest kapsułkowana przez inną jednostkę pracy.

Najlepiej jest mieć metodę testową dla każdej oddzielnej jednostki pracy, aby zawsze można było natychmiast zobaczyć, co się dzieje. W tym przykładzie istnieje podstawowa metoda o nazwiegetUserById() która zwróci użytkownika, i są w sumie 3 jednostki pracy.

Pierwsza jednostka pracy powinna sprawdzić, czy prawidłowy użytkownik jest zwracany w przypadku prawidłowego i nieprawidłowego wprowadzenia.
Należy tutaj uwzględnić wszelkie wyjątki zgłaszane przez źródło danych: jeśli nie ma żadnego użytkownika, powinien zostać przeprowadzony test wykazujący, że wyjątek jest zgłaszany, gdy nie można go znaleźć. Przykładem może być ten, IllegalArgumentExceptionktóry został złapany z @Test(expected = IllegalArgumentException.class)adnotacją.

Po obsłużeniu wszystkich przypadków użycia dla tej podstawowej jednostki pracy, przechodzisz na wyższy poziom. Tutaj robisz dokładnie to samo, ale radzisz sobie tylko z wyjątkami pochodzącymi z poziomu tuż poniżej bieżącego. Dzięki temu kod testowy jest dobrze ustrukturyzowany i pozwala szybko przeszukać architekturę, aby sprawdzić, gdzie coś pójdzie nie tak, zamiast przeskakiwać wszędzie.

Obsługa prawidłowych i błędnych danych wejściowych testu

W tym momencie powinno być jasne, jak poradzimy sobie z tymi wyjątkami. Istnieją 2 rodzaje danych wejściowych: prawidłowe dane wejściowe i błędne dane wejściowe (dane wejściowe są prawidłowe w ścisłym tego słowa znaczeniu, ale nie są prawidłowe).

Kiedy pracujesz z prawidłowymi danymi wejściowymi, ustawiasz niejawne oczekiwanie, że dowolny test, który napiszesz, zadziała.

Taka metoda połączenie może wyglądać następująco: existingUserById_ShouldReturn_UserObject. Jeśli ta metoda zawiedzie (np. Zgłoszony zostanie wyjątek), wiesz, że coś poszło nie tak i możesz zacząć kopać.

Dodając kolejny test ( nonExistingUserById_ShouldThrow_IllegalArgumentException), który wykorzystuje błędne dane wejściowe i oczekuje wyjątku, możesz sprawdzić, czy twoja metoda robi to, co powinna zrobić z nieprawidłowymi danymi wejściowymi.

TL; DR

Próbowałeś zrobić dwie rzeczy w teście: sprawdź, czy dane wejściowe są prawidłowe i błędne. Dzieląc to na dwie metody, z których każda robi jedną rzecz, uzyskasz o wiele jaśniejsze testy i znacznie lepszy przegląd tego, co się nie powiedzie.

Pamiętając o warstwowej jednostce prac, możesz również zmniejszyć liczbę testów potrzebnych dla warstwy znajdującej się wyżej w hierarchii, ponieważ nie musisz uwzględniać wszystkich rzeczy, które mogły pójść nie tak w niższych warstwach: warstwy poniżej bieżącej są wirtualną gwarancją, że twoje zależności działają, a jeśli coś pójdzie nie tak, znajduje się w twojej bieżącej warstwie (zakładając, że niższe warstwy nie powodują żadnych błędów).

Natknąłem się na to z powodu zasady SonarQube „squid: S2699”: „Dodaj co najmniej jedno stwierdzenie do tego przypadku testowego”.

Miałem prosty test, którego jedynym celem było przejście bez rzucania wyjątków.

Rozważ ten prosty kod:

public class Printer {

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

Jakiego rodzaju twierdzenie można dodać, aby przetestować tę metodę? Jasne, możesz spróbować go złapać, ale to tylko rozdęcie kodu.

Rozwiązanie pochodzi od samego JUnit.

Jeśli nie zostanie zgłoszony żaden wyjątek i chcesz jawnie zilustrować to zachowanie, po prostu dodaj, expectedjak w poniższym przykładzie:

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

Test.None.class jest domyślną wartością oczekiwaną.

Dzięki płynnym stwierdzeniom AssertJ 3.7.0 :

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

JUnit 5 (Jupiter) zapewnia trzy funkcje sprawdzania nieobecności / obecności wyjątku:

● assertAll​()

  Zapewnia, że wszystkie dostarczone executables
  nie wyrzucają wyjątków.

● assertDoesNotThrow​()

  Zapewnia, że wykonanie
  dostarczonego executable/ supplier
  nie rzuca żadnego wyjątku .

  Ta funkcja jest dostępna
  od wersji JUnit 5.2.0 (29 kwietnia 2018 r.).

● assertThrows​()

  Zapewnia, że wykonanie dostarczonego executable
  generuje wyjątek 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));
    }

}

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

Możemy napisać małą klasę użytkową

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 }

a 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 starej funkcji Java: bloki kodu aribitrary i prosty komentarz

//setup
Component component = new Component();

//act
configure(component);

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

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

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

Chociaż jest dużo miejsca na majstrowanie przy tym, jak chcesz to wyrazić, zawsze byłem fanem płynnych zapewnień .

Jeżeli chodzi o

Podchodzisz do tego niewłaściwie. Po prostu przetestuj swoją funkcjonalność: jeśli zostanie zgłoszony wyjątek, test automatycznie się nie powiedzie. Jeśli nie zostanie zgłoszony żaden wyjątek, wszystkie testy zmienią kolor na zielony.

Zasadniczo jest to poprawne, ale wniosek jest błędny.

Java dopuszcza wyjątki dla przepływu kontroli. Odbywa się to przez samo środowisko wykonawcze JRE w interfejsach API, takich jak Double.parseDoublea NumberFormatExceptioni Paths.geta InvalidPathException.

Biorąc pod uwagę, że napisałeś komponent, który sprawdza ciągi liczbowe Double.ParseDouble, być może przy użyciu Regex, może ręcznie analizatora składni lub może coś, co zawiera inne reguły domeny, które ograniczają zakres liczby podwójnej do czegoś konkretnego, jak najlepiej to przetestować składnik? Myślę, że oczywistym testem byłoby stwierdzenie, że podczas analizowania łańcucha wynikowego nie jest zgłaszany żaden wyjątek. Chciałbym napisać ten test przy użyciu powyższego assertDoesNotThrowlub /*comment*/{code}bloku. 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 sparametryzowania tego testu przy inputużyciu Theorieslub w Parameterizedcelu łatwiejszego ponownego użycia tego testu dla innych danych wejściowych. Alternatywnie, jeśli chcesz iść egzotycznie, możesz wybrać narzędzie do generowania testów (i to ). TestNG ma lepszą obsługę testów sparametryzowanych.

Szczególnie nieprzyjemne jest dla mnie zalecenie użycia @Test(expectedException=IllegalArgumentException.class), ten wyjątek jest niebezpiecznie szeroki . Jeśli Twój kod zmieni się tak, że ma to w konstruktorze testowanego komponentuif(constructorArgument <= 0) throw IllegalArgumentException() , a Twój test podaje 0 dla tego argumentu, ponieważ jest to wygodne - i jest to bardzo powszechne, ponieważ dobre generowanie danych testowych jest zaskakująco trudnym problemem - wtedy twój test pojawi się zielony pasek, mimo że nic nie testuje. Taki test jest gorszy niż bezużyteczny.

Jeśli masz pecha, aby złapać 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);
    }
}

JUnit5 dodaje metodę assertAll () właśnie w tym celu.

assertAll( () -> foo() )

źródło: JUnit 5 API

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

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

Dawny:

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 korzystającym z nowszej wersji Junit5

Jeśli chcesz sprawdzić, czy cel testowy korzysta z wyjątku. Po prostu zostaw test jako (próbny współpracownik używający jMock2):

@Test
public void consumesAndLogsExceptions() throws Exception {

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

    target.doSth();
 }

Test zostanie zaliczony, jeśli Twój cel wykorzysta zgłoszony wyjątek, w przeciwnym razie test się nie powiedzie.

Jeśli chcesz przetestować logikę zużycia wyjątków, sprawy stają się bardziej złożone. Sugeruję przekazanie konsumpcji współpracownikowi, który mógłby zostać wyszydzony. Dlatego 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();
 }

Ale czasami jest przeprojektowany, jeśli chcesz go tylko zalogować. W takim przypadku ten artykuł ( http://java.dzone.com/articles/monitoring-declarative-transac , http://blog.novoj.net/2008/09/20/testing-aspect-pointcuts-is-there -an-easy-way / ) może pomóc, jeśli nalegasz na tdd w tym przypadku.

Użyj assertNull (...)

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

Można oczekiwać, że wyjątek nie zostanie zgłoszony 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 zostanie zgłoszony 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ą @Rule, a następnie wywołać metodę reportMissingExceptionWithMessage, jak pokazano poniżej: To jest kod Scala.

Następujący test kończy się niepowodzeniem dla wszystkich wyjątków, zaznaczonych lub niezaznaczonych:

@Test
public void testMyCode() {

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

Możesz tworzyć dowolne własne asercje na podstawie asercji 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 przetestuj:

//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 testu („bla bla bla”) 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 testowym:

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

Oto próbka metody, którą testujemy, zakładając, że mamy taką metodę, która nie może zawieść w określonych okolicznościach, ale może się nie powieść:

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

Powyższa metoda jest prostą próbką. Ale działa to w skomplikowanych sytuacjach, w których awaria nie jest tak oczywista. Istnieją import:

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