Jak sprawdzić, czy nie zgłoszono wyjątku?

238

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?)

Ankit Dhingra
źródło
10
Test JUnit uznaje się za nieudany, jeśli zgłasza wyjątek inny niż oczekiwany. Zwykle nie oczekuje się żadnych wyjątków.
Raedwald,
Czy w JUnit nie ma rozróżnienia między awarią a błędem? Pierwszy oznacza, że ​​test się nie powiódł, drugi oznacza, że ​​stało się coś nieoczekiwanego.
Vituel,
1
możliwy duplikat Jak mogę sprawdzić, czy dany wyjątek nie został zgłoszony?
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Odpowiedzi:

198

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.

wprowadź opis zdjęcia tutaj

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).

Jeroen Vannevel
źródło
2
Chodzi o to, że próbuję TDD, a jeden z współpracowników, których używam, zgłasza wyjątek. Muszę więc przetestować fakt, że spożywam wyjątek zgłoszony przez współpracownika
Ankita Dhingrę
6
Czy mówisz, że twoja funkcjonalność zależy od obsługi wyjątku? To zapach kodu: wyjątki pozwalają elegancko wychwycić problemy; nie są używane do kontroli przepływu. Jeśli chcesz przetestować scenariusz, w którym powinien zostać zgłoszony wyjątek, powinieneś użyć expectedadnotacji. Jeśli chcesz przetestować scenariusz, w którym kod zawiedzie i chcesz sprawdzić, czy błąd został poprawnie obsłużony: użyj expectedi być może użyj aserts, aby ustalić, czy problem został rozwiązany.
Jeroen Vannevel
Chodzi o to, że nie mogę odzyskać z wyjątku, który wystąpił we współpracy, a wszystko, co robię, to po prostu zarejestrować problem za pomocą log.debug („Komunikat o błędzie”). Więc nie ma żadnych efektów ubocznych w ramach bloku catch, który mógłbym ewentualnie potwierdzić.
Ankit Dhingra
5
@JeroenVannevel jest całkowicie poprawne sprawdzenie, czy sytuacja błędu, która powoduje zgłoszenie wyjątku, jest właściwie obsługiwana.
Thorbjørn Ravn Andersen
1
@dpk tak, możesz. Dodajesz throws IllegalArgumentExceptiondo testu. Na końcu chcesz, aby Twój test zmienił kolor na czerwony, jeśli istnieje wyjątek. Zastanów się? Nie musisz pisać fail(). Jak napisał @Jeroen Vannevel: „jeśli zostanie
Amedee Van Gasse
132

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ą.

Sven Döring
źródło
30
Myślę, że to najlepsza odpowiedź. Przyjęta odpowiedź jest świetna, a autor słusznie wskazuje zapach kodu. Jednak tak naprawdę nie odpowiedział na konkretne pytanie.
HellishHeat
4
warto zauważyć, że domyślną wartością oczekiwaną jest None, więc wystarczy dodać adnotację do metody @Test.
oziomajnr
42

Dzięki płynnym stwierdzeniom AssertJ 3.7.0 :

Assertions.assertThatCode(() -> toTest.method())
    .doesNotThrowAnyException();
denu
źródło
1
@ emeraldhieu Pytanie nie dotyczy nawet assertJ, więc w jaki sposób to „bezpośrednio” odpowiada na pytanie OP?
MauriceNino,
41

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

}
olibre
źródło
1
To najlepsza odpowiedź teraz. Inne odpowiedzi omawiają starsze wersje JUnit
Tejesh Raut
29

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.

Groostav
źródło
2
(dotyczy użycia oczekiwanego wyjątku) Od wersji JUnit 4.13 można użyć, Assert.assertThrowsaby sprawdzić, czy jakiś kod zgłasza wyjątek.
MageWind
22

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);
    }
}
Ben Tennyson
źródło
1
Tylko mała sugestia, Exception expowinna być = null;zanim będziesz mógł ją przetestować.
Denees
4
To nie jest świetne rozwiązanie. Jeśli metoda, która nie powinna generować wyjątku, wyrzuci, nie pojawi się przydatny komunikat o błędzie. Wystarczy wywołać metodę, która nie powinna zgłaszać wyjątku, i przetestować jego wartość zwracaną (lub skutki uboczne, takie jak rejestrowanie wyjątku). Jeśli później nieoczekiwanie zgłosi wyjątek, test zakończy się niepowodzeniem.
NamshubWriter,
3
Lub po prostu umieść Assert.fail () w catch, łatwiejszym i ładniejszym IMO.
isaac.hazan
Tak, zgadzam się z tobą. Jeszcze jednym sposobem jest dodanie adnotacji na górze metody @Test (oczekiwany = InvalidRequestException.class)
Ben Tennyson
Twoja błędna pisownia jest myląca: thisShouldThroughError -> thisShouldThrowError .
Oscar Bravo,
7

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

Dinesh Arora
źródło
Chciałbym, aby istniał tutaj sposób na określenie konkretnej klasy wyjątku. Muszę zrobić to wnętrze Awaitility„s untilAsserted(ThrowingRunnable assertion). Testowany system obecnie rzuca określony wyjątek na udostępnianą przeze mnie funkcję ThrowingRunnable, ale chcę dać temu trochę czasu, aż przestanie to robić. Jeśli jednak rzuciłby to inny wyjątek, chciałbym, aby test natychmiast się nie powiódł.
Ubeogesh
1

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.

Yugang Zhou
źródło
1

Użyj assertNull (...)

@Test
public void foo() {
    try {
        //execute code that you expect not to throw Exceptions.
    } catch (Exception e){
        assertNull(e);
    }
}
Mike Rapadas
źródło
6
Powiedziałbym, że to wprowadza w błąd. Blok przechwytywania nigdy nie jest osiągany, więc też assertNullnigdy nie jest wykonywany. Jednak szybki czytelnik ma wrażenie, że poczyniono stwierdzenie, które naprawdę weryfikuje przypadek nieprzerzucania. Innymi słowy: jeśli zostanie osiągnięty blok catch, wyjątek jest zawsze różny od zera - można go zatem zastąpić prostym fail.
Andreas
wprawdzie wprowadza w błąd ..... ale czekaj ... och, rozumiem ... assertNull(e)zgłosi test jako nieudany, jak stwierdzono, enie może być nullw catchbloku ... Mike, to jest po prostu dziwne programowanie: - /. .. tak przynajmniej użyj, fail()jak mówi Andreas
Julien
1

Można oczekiwać, że wyjątek nie zostanie zgłoszony przez utworzenie reguły.

@Rule
public ExpectedException expectedException = ExpectedException.none();
LazerBanana
źródło
Oczekiwane wyjątki służą do zgłaszania zgłoszonych wyjątków. Podany kod służy tylko do zainicjowania reguły, aby można było dodać wymagania dotyczące asercji. Sam kod nie wnosi żadnej wartości. Javadoc stwierdza również: „/ ** * Zwraca {@linkplain TestRule regułę}, która nie oczekuje, że zostanie zgłoszony wyjątek * (identyczny z zachowaniem bez tej reguły). * /" Więc będzie miał dokładnie taki sam wynik jak bez niej .
Pim Hazebroek
Zgadzam się z tobą i nie użyłbym tego w ten sposób, ale można stwierdzić, że nie zgłoszono żadnego wyjątku. Jeśli test się powiedzie, powinno wystarczyć stwierdzenie, że wyjątek nie został zgłoszony, ale z drugiej strony, jeśli istnieje pytanie, musi być potrzebne. I rzadko, ale wciąż czasem dobrze jest mieć to widoczne. Co się stanie, jeśli kod i okoliczności ulegną zmianie i nie będziemy testować konkretnego przypadku krawędzi?
LazerBanana
Jestem ciekawy, jak byś to potwierdził z oczekiwanym wyjątkiem. I tak, jeśli wymagania się zmienią i nie masz testu na konkretną obudowę, którą masz przykręconą ;-) zawsze pokrywaj wszystkie skrzynki narożne.
Pim Hazebroek
co masz na myśli? nie wyznajesz tego, oczekujesz tego. W takim przypadku nie oczekuje się wyjątku. Nie jestem pewien, co masz na myśli.
LazerBanana
0

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
    }
}
MLS
źródło
0

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

wprowadź opis zdjęcia tutaj

Crenguta S
źródło
1
private val? Co to za język? Najwyraźniej nie Java; p Proszę nie podawać kodu jako zrzutu ekranu, nie jest mile widziany.
Andremoniy
Widzę, że wspomniałeś, że to Scala, ale stwierdzenie, że można to łatwo zrobić w Javie, nie jest mocnym argumentem, przepraszam
Andremoniy,
Usunąłem część, która cię niepokoiła. Spróbuję również zastąpić obraz. Jeszcze nie wymyśliłem, jak dodać kod.
Crenguta S
-1

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!");
    }
}
Rocky Inde
źródło
-1

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.*;
armagedescu
źródło
Istnieje o wiele lepsza opcja sprawdzenia, czy asercja nie została zgłoszona, co nie wymaga tworzenia niestandardowego kodu. @Rule jest jednym z nich
Vargan
@ Vargan Wskazałem metodę tworzenia własnych asercji w sposób, w jaki została zaprojektowana przez JUnit, szczególnie w celu tworzenia własnych asercji. JUnit zapewnia, że ​​zgodnie z projektem, zwłaszcza w tym celu, aby stworzyć własne reguły, rozszerzaj zachowanie JUnit o aserty, które nie zostały jeszcze zaimplementowane. Ponieważ nie wszystko jest zaimplementowane w tym świecie Asercje te działają tak samo, jak asercje JUnit pod względem przekazywania lub niepowodzenia, a także zgłaszania awarii.
armagedescu