Dois-je utiliser try catch dans mes méthodes de test?

18

Je fais des tests unitaires.

J'essaie de tester une fonction.

Je l'appelle depuis mon composant de test. Mais si la fonction distante ne peut pas gérer l'exception, mon composant de testeur recevra également une exception, je suppose.

Dois-je donc m'inquiéter d'obtenir une exception dans mon composant de testeur?

Merci.

ÉDITER:

PS:

Lancer une erreur est une bonne chose, mais uniquement pour d'autres fonctions, pas pour les utilisateurs finaux jusqu'à ce que ce soit une dernière option!

OMG j'ai écrit un devis de programmation !!

testing unit-testing exceptions

— Vikas
source

Je suis nouveau dans les tests et dois-je tester uniquement le comportement de la fonction. Je pense que cela s'appelle des tests de boîte noire et de boîte blanche. Oh je m'en souviens. J'ai étudié ça au collège!

— Vikas

Quel langage et framework xUnit utilisez-vous spécifiquement? Je dirais oui dans certains cas.

— Greg K

J'utilise MXUnit avec MockBox et ColdBox pour le langage ColdFusion.

— Vikas

23

Réponse courte: NON.

N'attrapez pas d'exceptions dans les tests unitaires. Vous effectuez des tests unitaires pour rechercher des erreurs et des situations dans lesquelles des exceptions sont déclenchées.

Le cadre de test unitaire doit gérer les exceptions de manière sensée. La plupart (sinon la totalité) des frameworks xUnit ont une construction pour s'attendre à certaines exceptions que vous utilisez lorsque vous souhaitez induire une condition d'exception particulière dans le système testé et avoir une réussite de test si l'exception attendue est déclenchée mais échoue si ce n'est pas le cas.

— mcottle
source

Je pense que le cadre de test avancé peut très bien gérer les exceptions, même si je trouve que dans Visual studio, nous pouvons tester des exceptions comme vous l'avez dit "exception attendue". Donc c'est bon à savoir et à partager. Merci ..

— Vikas

Parfois, vous voulez vérifier si une exception est levée, car de bons tests ne testent pas uniquement les cas où les choses fonctionnent, mais aussi les cas où ils échouent.

— deadalnix

1

Vous voulez intercepter des exceptions, comme vous voulez tester les situations dans lesquelles des exceptions se produisent (en particulier vos propres exceptions). Si vous écrivez du code conçu pour échouer avec une exception dans certaines conditions, ces conditions doivent faire partie de votre suite de tests et doivent donc être testées. Dans le cadre de ces tests, ces exceptions devraient être détectées et analysées.

— jwenting

1

@Jwenting Lisez le deuxième paragraphe - Les frameworks de tests unitaires interceptent les exceptions et permettent aux tests de passer si certaines exceptions sont levées et échouent si elles ne le sont pas

— mcottle

5

(Contrairement à la réponse de mcottle) Réponse longue: NON ... la plupart du temps

Lorsque vous dites que vous vous attendez à ce qu'un test déclenche une exception particulière, vous saurez quand N'IMPORTE QUELLE ligne de ce test déclenche cette exception particulière.

Ce n'est pas tout à fait la même chose que de savoir que la méthode testée lève l'exception.

Si votre test implique la mise en place d'un objet ou d'un contexte (dans le test, pas dans la version de votre framework SetUp), vous feriez peut-être mieux d'encapsuler la seule ligne que vous souhaitez réellement tester dans un try / catch, éventuellement avec une aide.

Par exemple,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

puis

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

Si ce test échoue, je sais que ma méthode en cours de test a levé l'exception, et pas quelque chose dans la configuration aléatoire.

(Vous devriez essayer d'éviter les choses de configuration aléatoire. Parfois, il est plus facile d'avoir du code de configuration dans le test.)

— Frank Shearar
source

Bon exemple! J'essaie de faire très attention à ne pas limiter la phase "test" au test précis, mais je me souviendrai de cette astuce lorsque je n'arrive pas à trouver un moyen d'y parvenir (par exemple, lors d'un test de conditions de course). et besoin de "configuration" près du "test" pour atteindre la condition).

— Ethel Evans

1

En général, vous devez simplement laisser l'exception, et le cadre de test vous donnera un bon rapport avec toutes les informations dont vous avez besoin.

Mais dans la méthodologie TDD, nous devons suivre ces étapes:

Écrivez un test
Regardez-le échouer et rendez l'erreur compréhensible
Corrigez le code
Refactoriser le code et le test

Lorsque vous laissez sortir une exception, si l'erreur est claire, alors ça va. Mais parfois, l'exception est obscure, voire erronée. Comment pourriez-vous laisser cela figurer dans votre code (pour vous plus tard, lorsque vous aurez oublié, ou pour un membre de l'équipe qui perdra beaucoup de temps à résoudre le problème)? Donc ma politique est: " S'il est nécessaire de clarifier un échec, vous devez attraper l'exception ".

— KLE
source