Comment se fait que vous ne pouvez pas attraper Contrat de Code exceptions?

Système.Diagnostics.Des contrats.ContractException n'est pas accessible dans mon projet de test. Remarque: ce code est purement moi-même de déconner avec mes shiney nouvelle copie de Visual Studio, mais j'aimerais savoir ce que je fais mal.

Je suis à l'aide de l'édition professionnelle de VS, donc je n'ai pas de vérification statique. Afin de toujours utiliser des contrats de code (que j'aime) j'ai pensé que la seule façon de ma méthode de travail est d'attraper l'exception est levée lors de l'exécution, mais je ne suis pas à trouver ce possible.

TestMethod

[TestMethod, ExpectedException(typeof(System.Diagnostics.Contracts.ContractException))]
public void returning_a_value_less_than_one_throws_exception()
{
    var person = new Person();
    person.Number();
}

Méthode

public int Number()
{
    Contract.Ensures(Contract.Result<int>() >= 0);
    return -1;
}

Erreur

Erreur De 1 'Système.Diagnostics.Des contrats.ContractException' est inaccessible 
en raison de son niveau de protection.

Modifier

Après certains plus de pensée, je suis venu à la conclusion discuté dans les commentaires, ainsi que les suivants. Étant donné une méthode, si cela avait une exigence qui peut être exprimé dans le Code du formulaire de Contrat, je ferais des tests en tant que tel.

[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void value_input_must_be_greater_than_zero()
{
    //Arrange
    var person = new Person();
    //Act
    person.Number(-1);
}

Cela permettrait de s'assurer que le contrat est une partie du code, il ne sera pas supprimé. Ceci nécessiterait un Contrat de Code pour réellement lancer l'exception spécifiée, cependant. Dans certains cas, cela ne serait pas nécessaire, cependant.

InformationsquelleAutor Finglas | 2010-04-14
  1. 69

    C'est délibéré - bien qu'une légère douleur pour les tests.

    Le point est que dans le code de production ne doit jamais vous voulez prendre un contrat d'exception; il indique un bug dans votre code, vous ne devriez pas attendre plus que arbitraire exceptions inattendues qui peuvent vous voulez prendre à droite en haut de votre pile d'appel de sorte que vous pouvez passer à la prochaine demande. Fondamentalement, vous ne devriez pas voir contrat d'exceptions qui peuvent être "gérée" en tant que tel.

    Maintenant, pour les tests c'est une douleur... mais avez-vous vraiment envie de tester vos contrats de toute façon? N'est-ce pas un peu comme les tests que le compilateur ne vous empêche de passer dans un string une méthode qui a un int paramètre? Vous avez déclaré le contrat, il peut être documentés de façon appropriée, et appliquées de manière appropriée (en fonction de paramètres, de toute façon).

    Si vous ne voulez tester contrat exceptions, vous pouvez prendre un nu Exception dans le test et la vérification de son nom complet, ou vous pouvez s'amuser avec les Contrat.ContractFailed événement. J'attendrais les tests unitaires des cadres pour la prise en charge intégrée pour cela, au fil du temps - mais ça va prendre un peu de temps pour y arriver. En attendant, vous souhaitez probablement une méthode utilitaire de s'attendre à une violation de contrat. Une implémentation possible:

    const string ContractExceptionName =
    "System.Diagnostics.Contracts.__ContractsRuntime.ContractException";

public static void ExpectContractFailure(Action action)
{
    try
    {
        action();
        Assert.Fail("Expected contract failure");
    }
    catch (Exception e)
    {
        if (e.GetType().FullName != ContractExceptionName)
        {
            throw;
        }
        //Correct exception was thrown. Fine.
    }
}
    • Je vois ce que vous obtenez en. Et que vous faites un bon point sur les tests unitaires de soutien dans l'avenir. Dans mon exemple, la méthode, l'utilisation d'un contrat de code est inutile alors? Si c'était une vraie méthode, de code/code de test serait plus approprié.
    • J' personnellement ne pense pas que les contrats doivent être testés au moins, sauf s'ils sont complexes, et, généralement, ils ne devraient pas l'être. Toutefois, c'est seulement un point de vue personnel, et vous devez vous absolument s'attendre à l'écoute des autres. Pensez à ce que j'ai écrit, mais s'il vous plaît ne sentent aucune obligation d'accepter 🙂 j'espère que le code dans la réponse va vous aider si vous vous sentez ne vous voulez tester le contrat.
    • non, il fait juste cliqué. Voir: stackoverflow.com/questions/1383535/... La réponse et les commentaires ici un sens aujourd'hui j'ai effectivement joué avec CC. Mes tests échouerait si un contrat n'est pas respecté, mes tests passerait si mon contrat est remplie, et mon test est satisfait. Ceci est en contraste à l'essai le contrat, qui est ce que je faisais avant.
    • Il est intéressant de noter que le Pex sera effectivement ajouter des tests pour le contrat d'échecs.
    • Skeet: je ne suis pas sûr si je suis d'accord que les contrats n'ont pas besoin de test. Plus précisément, ce n'est pas le contrat qui est en train d'être testé, mais plutôt le comportement de la méthode de jeter lorsqu'un contrat est violé. Disons que la spécification d'une méthode void M(string s) exige que M jeter si s est null ou un espace blanc. Une façon de mettre en œuvre consiste à utiliser Contract.Requires. Une autre manière classique, c'est la if-throw construire, ou éventuellement utiliser un haut -Guard.Against. Le point est, un test ne devrait pas être l'essai le contrat, mais que M est conforme à la spécification.
    • Skeet: Donc, je ne pense pas que le type d'exception spécifique devrait être testé (parce que c'est un détail d'implémentation), mais plutôt qu'une exception est levée lorsque la condition n'est pas respectée (sauf si le cahier des charges est qu'un type particulier d'exception est levée).
    • Mais le contrat est le cahier des charges. Si elle est exprimée de manière déclarative, d'une manière qui peut être documenté automatiquement, vu etc, quel est l'avantage de ce test? Je peux comprendre qu'il y a un complexe contrat qui pourrait avoir besoin de quelques exemples pour expliquer, mais je ne vois pas l'intérêt pour un simple argument null.
    • Skeet: En Désaccord. Le contrat est d'une mise en œuvre de la partie de la spécification. Donc, si je suis pour mettre en œuvre une méthode void M(string s) qui jette si s est nul ou blanc de l'espace et sinon imprime s à la console, qui est la spécification. Je risque de ne pas mettre pleinement en œuvre la spécification par négliger d'inclure un Contract.Requires ou un if-throw construire. Le point de l'unité de test est de s'assurer que je mettre pleinement en œuvre le cahier des charges, ainsi que de les protéger contre le refactoring et de maintenance.
    • Avez-vous aussi tester que la méthode ne peut être appelée avec le mauvais types d'argument, trop? Je veux dire sûrement la signature de la méthode est la partie de la spécification, trop... donc, avez-vous une unité de test qui utilise la réflexion pour essayer d'appeler une méthode qui prend une chaîne de caractère, mais à l'aide d'un argument de type int? Si non, ne veut pas dire que vous n'êtes pas le test de la spécification de complètement? Quelle est la différence entre que sorte de aspect déclaratif (la signature de la méthode) et le contrat? Nous pouvons accepter de différer à la fin, mais c'est une discussion intéressante...
    • je pense que je pensais que les Contrats d'énoncer des choses qui n'ont pas besoin d'être testé. Par exemple, le Pex de ne pas poursuivre les chemins de code qui sont coupées par un contrat.
    • Pourriez-vous pas aussi faire cette logique dans une classe dérivée à partir de ExpectedExceptionBaseAttribute, en remplaçant les Vérifier(à l'Exception de la méthode?
    • Peut - être- je ne sais pas. Cependant, je ne suis pas vif sur la décoration de tests avec des attributs attendus exceptions: d'habitude, je veux faire en sorte que l'exception n'est levée où, je l'attends.
    • Skeet: Il est vraiment facile de mettre le contrat, mais ne pas activer la compilation de réécriture, de sorte que le contrat ne fait rien. Unité de contrôle de mauvais arguments sont rejetés permet d'éviter (même si tout ce que vous testez est le code de la mise en œuvre du contrat), mais je voudrais essayer et éviter de faire le test de "savoir" que CodeContracts sont la mise en œuvre.
    • Dans ce cas, je serais probablement le faire pour un de la méthode au sein de l'assemblée - c'est pas comme si vous avez accidentellement va tourner réécrire pour qu'une méthode, mais pas d'autres. L'ajout de tests unitaires pour chaque contrat unique se sent comme une perte de temps pour moi.
    • moi, la différence essentielle est que le compilateur m'empêcher d'appeler void M(string s) avec un int paramètre. Le test unitaire doit code de test comportement, donc si je m'attends à une exception lorsque je l'appelle avec la valeur null, alors je devrais être en mesure de vérifier le comportement à adopter avec un test unitaire.
    • Mais l'outil d'analyse statique va vous empêcher de l'appel de la méthode, avec un argument null trop... si vous êtes à l'aide de l'outil d'analyse statique, bien sûr.
    • Jon - vous avez raison, ExpectedException et d'autres attributs ne sont pas la voie à suivre. J'ai codé une Assertion extension Affirmer.Jette<T>() similaire à xUnit et c'est beaucoup plus propre et plus précis. En ce qui concerne les contrats de contrôle, de sûr, vous devriez le faire. Si quelqu'un supprime ou modifie le contrat de telle manière que les changements de comportement, vous obtenez un test en échec indiquant une modification de rupture. Ceci est particulièrement important pour le développement des bibliothèques.
    • Le truc, c'est de constater que l'argument, les types et les contrats sont la spécification. Maintenant, les spécifications et le code ne peut pas sortir de la synchronisation. (Cependant, je voudrais le test de spécification de contrôle est activé, si elle peut être désactivée).
    • Je suis un peu en retard à la conversation ici, mais je crois que la principale différence entre une signature de méthode et un contrat est que les Contrats ne pas briser la construction par défaut. Il n'est pas possible de compiler votre code lorsque vous appelez une méthode avec un int lorsqu'il attend une chaîne. Il est possible (via la configuration) pour appeler une méthode d'une manière qui constitue une violation du contrat. Je dirais donc, si votre système de construction nécessite l'analyseur statique passe au vert, puis déposer les tests. Si votre système de construction ne dépend pas de l'analyseur statique de passage puis ajouter les tests à la place.
    • vous pouvez facilement passer le mauvais type de méthode et ne pas avoir le compilateur se plaindre. La réflexion, la boîte/cast, et la dynamique de mots clés pour les débutants.
    • Pour que tout le monde est inquiet de Contrat écrit mal, car vous avez le dev de faire le travail lorsque vous avez votre architecte/lead écrire la spécification de test. Vous pouvez mettre en œuvre des contrats sur vos interfaces. La chose impressionnante, c'est que vous n'avez pas à dupliquer le contrat pour chaque mise en œuvre et la vérification statique sera d'assurer la mise en œuvre est correcte.
    • Je suis d'accord. De Plus, de plus en plus complexe contrat peut elle-même avoir un bug et si vous n'avez pas le couvrir avec des tests, il s'affichera dans la production.

    InformationsquelleAutor Jon Skeet
  2. 8

    EDIT: j'ai eu une conversion et de ne plus utiliser ExpectedException ou cet attribut ci-dessous, mais plutôt codé des méthodes d'extension:

    AssertEx.Throws<T>(Action action);
AssertEx.ThrowsExact<T>(Action action);
AssertEx.ContractFailure(Action action);

    Ces permettez-moi d'être plus précis sur l'endroit où l'exception est soulevée.

    Exemple de ContractFailure méthode:

        [SuppressMessage("Microsoft.Design", "CA1031:DoNotCatchGeneralExceptionTypes", Justification = "Cannot catch ContractException")]
    public static void ContractFailure(Action operation)
    {
        try
        {
            operation();
        }
        catch (Exception ex)
        {
            if (ex.GetType().FullName == "System.Diagnostics.Contracts.__ContractsRuntime+ContractException")
                return;

            throw;
        }

        Assert.Fail("Operation did not result in a code contract failure");
    }

    J'ai créé un attribut pour MSTest, qui se comporte de façon similaire à la
    ExpectedExceptionAttribute:

    public sealed class ExpectContractFailureAttribute : ExpectedExceptionBaseAttribute
{
    const string ContractExceptionName = "System.Diagnostics.Contracts.__ContractsRuntime+ContractException";

    protected override void Verify(Exception exception)
    {
        if (exception.GetType().FullName != ContractExceptionName)
        {
            base.RethrowIfAssertException(exception);
            throw new Exception(
                string.Format(
                    CultureInfo.InvariantCulture,
                    "Test method {0}.{1} threw exception {2}, but contract exception was expected. Exception message: {3}",
                    base.TestContext.FullyQualifiedTestClassName,
                    base.TestContext.TestName,
                    exception.GetType().FullName,
                    exception.Message
                )
            );
        }
    }
}

    Et cela peut être utilisé de la même façon:

        [TestMethod, ExpectContractFailure]
    public void Test_Constructor2_NullArg()
    {
        IEnumerable arg = null;

        MyClass mc = new MyClass(arg);
    }
    • Pouvez-vous partager le code pour ContractFailure extension?
    • J'ai édité ma réponse à montrer cette extension.
    InformationsquelleAutor Stephen Drew
  3. 2

    dans le vs2010 rtm, le nom complet a été changé pour "le Système de.Diagnostics.Des contrats.__ContractsRuntime+ContractException". HTH

    InformationsquelleAutor user341451
  4. 1

    Si cette question se fait vieux, et la réponse a déjà été fournie, je me sens comme j'ai une belle solution qui garde les choses simples et lisibles.
    En fin de compte, il nous permet d'écrire des tests sur les conditions préalables aussi simple que:

    [Test]
public void Test()
{
    Assert.That(FailingPrecondition, Violates.Precondition);
}

public void FailingPrecondition() {
    Contracts.Require(false);
}

    Ok, donc l'idée est de fournir le Code de Contrats de graveur avec un contrat personnalisé d'exécution de la classe.
    Ce peut être configuré dans l'assemblée des propriétés dans la section "Custom Graveur Méthodes" (voir le Code des Contrats Manuel de l'Utilisateur section 7.7):

    Comment se fait que vous ne pouvez pas attraper Contrat de Code exceptions?

    N'oubliez pas aussi de vérifier Call-site Requires Checking!

    La classe personnalisée ressemble à quelque chose comme ceci:

    public static class TestFailureMethods
{
    public static void Requires(bool condition, string userMessage, string conditionText)
    {
        if (!condition)
        {
            throw new PreconditionException(userMessage, conditionText);
        }
    }

    public static void Requires<TException>(bool condition, string userMessage, string conditionText) where TException : Exception
    {
        if (!condition)
        {
            throw new PreconditionException(userMessage, conditionText, typeof(TException));
        }
    }
}

    À l'aide d'un custom PreconditionException classe (il ne contient rien de fantaisie!).
    Nous avons en outre l'ajout d'une petite classe d'aide:

    public static class Violates
{
    public static ExactTypeConstraint Precondition => Throws.TypeOf<PreconditionException>();
}

    Cela nous permet d'écrire simple, lisible essais sur la condition des violations, comme indiqué ci-dessus.

    InformationsquelleAutor Mikkel R. Lund