Comment tester qu'aucune exception n'est levée?

Vous vous approchez de cette façon le mal. Il suffit de tester votre fonctionnalité: si une exception est levée, le test échouera automatiquement. Si aucune exception n'est levée, vos tests va jusqu'vert.

J'ai remarqué que cette question suscite l'intérêt, de temps en temps, donc je vais développer un peu.

Arrière-plan de tests unitaires

Quand vous êtes les tests unitaires, il est important de définir pour vous-même ce que vous considérez comme une unité de travail. En gros: une extraction de votre base de code qui peut ou peut ne pas inclure plusieurs méthodes ou classes qui représente un seul morceau de fonctionnalité.

Ou, comme défini dans L'art de Tests Unitaires, 2e Édition par Roy Osherove, page 11:

Un de test de l'unité est un système automatisé de bout de code qui appelle à l'unité de travail mis à l'essai, et vérifie ensuite quelques hypothèses à propos d'un seul résultat final de cette unité. Un test unitaire est presque toujours écrit à l'aide d'un framework de test unitaire. Il peut être écrit facilement et s'exécute rapidement. Il est digne de confiance, lisible et maintenable. Il est cohérent dans ses résultats, à condition que le code de production n'a pas changé.

Ce qui est important à comprendre, c'est que l'on unité de travail habituellement n'est pas seulement une méthode, mais à la base c'est une méthode, et après qu'il est encapsulé par une autre unité de l'œuvre.

Idéalement, vous devriez avoir une méthode de test pour chaque unité de travail de sorte que vous pouvez toujours consulter immédiatement lorsque les choses vont mal. Dans cet exemple, il existe une méthode de base appelé getUserById() qui vous permettra de revenir à un utilisateur et il y a un total de 3 unités d'œuvres.

La première unité de travail doit tester si oui ou non un utilisateur valide est retourné dans le cas d'entrée valides et invalides.

Toutes les exceptions qui sont levées par la source de données doivent être traitées ici: si aucun utilisateur n'est présent, il devrait y avoir un test qui démontre qu'une exception est levée lorsque l'utilisateur ne peut pas être trouvé. Un exemple de cela pourrait être le IllegalArgumentException qui est pris avec le @Test(expected = IllegalArgumentException.class) annotation.

Une fois que vous avez traité tous vos usecases pour cette unité de base de travail, vous montez d'un niveau. Ici vous faire exactement la même chose, mais vous ne gérer les exceptions qui viennent à partir du niveau juste en dessous de l'actuel. Cela permet à vos tests de code bien structuré et permet d'exécuter rapidement grâce à l'architecture de trouver l'endroit où les choses vont mal, au lieu d'avoir à sauter dans tous les sens.

La manipulation d'un des tests de validité et la mauvaise entrée

À ce stade, il devrait être clair de la façon dont nous allons gérer ces exceptions. Il y a 2 types d'entrée: valide d'entrée et de défectueux entrée (l'entrée est valable dans le sens le plus strict, mais il n'est pas correct).

Lorsque vous travaillez avec des valide entrée de la configuration de l'implicite de l'espérance que quelque soit le test que vous écrivez, fonctionne.

Tel un appel de méthode peut ressembler à ceci: existingUserById_ShouldReturn_UserObject. Si cette méthode échoue (par exemple: une exception est levée), alors vous savez que quelque chose s'est mal passé et vous pouvez commencer à creuser.

Par l'ajout d'un autre test (nonExistingUserById_ShouldThrow_IllegalArgumentException) qui utilise le défectueux d'entrée et s'attend à une exception près, vous pouvez voir si votre méthode est ce qu'il est censé faire l'erreur de saisie.

TL;DR

Que vous étiez en train de faire deux choses dans votre test: vérifier la validité et la mauvaise entrée. En scindant en deux méthode que chacun de faire une chose, vous aurez beaucoup plus claire des tests et une bien meilleure vue d'ensemble de l'endroit où les choses vont mal.

En gardant les couches de l'unité des œuvres à l'esprit que vous pouvez également réduire le nombre de tests que vous besoin d'une couche est plus élevé dans la hiérarchie, parce que vous n'avez pas de compte pour chaque chose qui pourrait mal tourner dans les basses couches: les couches au-dessous de l'actuel sont une quasi-garantie de vos dépendances et si quelque chose va mal, il est dans votre calque courant (en supposant que les couches inférieures ne jetez pas les erreurs elles-mêmes).

Java 8 qui rend ce beaucoup plus facile, et Kotlin/Scala doublement.

On peut écrire un petit utilitaire de la classe

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 }

et puis votre code devient simplement:

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

Si vous n'avez pas d'accès à Java 8, je voudrais utiliser une douloureusement old java installation: aribitrary des blocs de code et un simple commentaire

//setup
Component component = new Component();

//act
configure(component);

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

Et enfin, avec kotlin, une langue que je suis récemment tombé en amour avec:

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

Si il y a beaucoup de place pour jouer avec exactement comment vous souhaitez exprimer cela, j'ai toujours été un fan de couramment affirmations.

---

Concernant

Vous vous approchez de cette façon le mal. Il suffit de tester votre fonctionnalité: si une exception est levée, le test échouera automatiquement. Si aucune exception n'est levée, vos tests va jusqu'vert.

C'est correct, en principe, mais incorrecte dans la conclusion.

Java permet des exceptions pour les flux de contrôle. Ceci est fait par le JRE runtime lui-même dans l'Api comme Double.parseDouble via un NumberFormatException et Paths.get via un InvalidPathException.

Donné que vous avez écrit un composant qui permet de valider le Nombre de chaînes de Double.ParseDouble, peut-être à l'aide d'une Regex, peut-être écrite à la main de l'analyseur, ou peut-être quelque chose qui incorpore certaines autres règles de domaine qui limite la portée d'un double à quelque chose de spécifique, la meilleure façon de tester ce composant? Je pense qu'un évident test consisterait à affirmer que, lorsque la chaîne est analysée, aucune exception n'est levée. Je voudrais écrire ce test en utilisant soit le au-dessus de assertDoesNotThrow ou /*comment*/{code} bloc. Quelque chose comme

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

Je voudrais aussi vous encourager à paramétrer ce test sur input à l'aide de Théories ou Paramétrée de sorte que vous pouvez plus facilement ré-utiliser ce test pour les autres entrées. Alternativement, si vous souhaitez aller plus exotique, vous pouvez aller faire un test de l'outil de production (et cette). TestNG a un meilleur support pour les tests paramétrés.

Ce que je trouve particulièrement désagréable est la recommandation de l'utilisation de @Test(expectedException=IllegalArgumentException.class), cette exception est dangereusement large. Si votre code des changements tels que le composant sous test, le constructeur a if(constructorArgument <= 0) throw IllegalArgumentException(), et votre test a été la fourniture de 0 pour cet argument parce que c'était pratique-et cela est très fréquent, en raison de la bonne génération de données de test est étonnamment un problème difficile--, puis votre test sera vert-bar même si il teste rien. Un tel test est pire qu'inutile.

Avec AssertJ couramment affirmations 3.7.0:

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

JUnit5 ajoute le assertAll() méthode pour cet objectif précis.

assertAll( () -> foo() )

source: JUnit 5 de l'API

Si vous voulez tester que si votre cible de test consomme de l'exception. Il suffit de laisser le test (simulation d'un collaborateur à l'aide de jMock2):

@Test
public void consumesAndLogsExceptions() throws Exception {

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

    target.doSth();
 }

Le test ne serait pass si votre cible ne consomment de l'exception levée, sinon le test échoue.

Si vous voulez tester votre exception de la consommation de la logique, les choses deviennent plus complexes. Je suggère de déléguer la consommation à un collaborateur qui pourrait se moque de lui. Par conséquent, le test pourrait être:

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

Mais parfois, il est plus conçu si vous voulez juste de l'enregistrer. Dans ce cas, cet article(http://java.dzone.com/articles/monitoring-declarative-transac, http://blog.novoj.net/2008/09/20/testing-aspect-pointcuts-is-there-an-easy-way/) peuvent vous aider si vous insistez tdd dans ce cas.

Vous pouvez vous attendre que l'exception n'est pas générée par la création d'une règle.

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

Vous pouvez créer n'importe quel type de vos propres affirmations basées sur des assertions de 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);
    }
}

Et de 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");

En général il y a la possibilité instantanément fail("bla bla bla") le test dans tous les scénarios, dans un endroit où il fait sens. Par exemple l'utiliser dans un bloc try/catch à l'échec si tout est jeté dans le cas du test:

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

C'est l'exemple de la méthode que nous avons test, supposons que nous avons une méthode qui ne doit pas échouer dans des circonstances particulières, mais il peut échouer:

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

La méthode ci-dessus est un exemple simple. Mais cela fonctionne pour les situations complexes, où l'échec n'est pas si évident.
Il y a les importations:

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