Comment puis-je obtenir SpecFlow pour s'attendre à une exception?

Question

J'utilise SpecFlow, et je voudrais écrire un scénario comme ce qui suit:

C'est que ça va jeter une exception, alors comment puis-je gérer cela dans la méthode marquée ?

Answer 1

Grande question. Je ne suis ni une bdd ou specflow expert, cependant, mon premier conseil serait de prendre du recul et d'évaluer votre scénario.

Voulez-vous vraiment utiliser les termes "jeter" et "exception" dans cette spécification? Gardez à l'esprit l'idée avec bdd, est l'utilisation omniprésente de la langue avec l'entreprise. Idéalement, ils devraient être en mesure de lire ces scénarios et de les interpréter.

Pensez à changer votre "puis" phrase d'inclure quelque chose comme ceci:

Scenario: Pressing add with an empty stack displays an error
    Given I have entered nothing into the calculator
    When I press add
    Then the user is presented with an error message

L'exception est toujours jeté dans le fond, mais le résultat final est un simple message d'erreur.

Scott Bellware touche ce concept dans ce Troupeau Code podcast: http://herdingcode.com/?p=176

Answer 2

Comme un débutant à SpecFlow je wan pas vous dire que c'est la façon de le faire, mais une façon de le faire serait d'utiliser l' ScenarioContext pour le stockage de l'exception levée dans le Lorsque;

try
{
    calculator.Add(1,1);
}
catch (Exception e)
{
    ScenarioContext.Current.Add("Exception_CalculatorAdd", e);
}

Dans votre Ensuite , vous pouvez vérifier la levée d'une exception et affirme sur elle;

var exception = ScenarioContext.Current["Exception_CalculatorAdd"];
Assert.That(exception, Is.Not.Null);

Avec cela dit, je suis d'accord avec scoarescoare quand il dit que vous devez formuler le scénario un peu plus "business-friendly" de formulations. Cependant, l'utilisation de SpecFlow de conduire la mise en œuvre de votre domaine-modèle, d'intercepter les exceptions et faire des assertions sur eux peuvent venir dans maniable.

Btw: découvrez Rob Conery du screencast sur au TekPub pour vraiment de bons conseils sur l'utilisation de SpecFlow: http://tekpub.com/view/concepts/5

Answer 3

BDD peut être pratiqué sur le niveau de fonctionnalité comportement ou/et sur le niveau de l'unité de comportement.

SpecFlow est une BDD outil qui met l'accent sur le niveau de fonctionnalité de comportement. Les Exceptions ne sont pas quelque chose que vous devez spécifier/observer sur le niveau de fonctionnalité de comportement. Les Exceptions doivent être spécifiés/observé sur le niveau de l'unité de comportement.

Pensez à SpecFlow scénarios sous la forme d'une spécification pour les non technique des parties prenantes. Vous aussi de ne pas écrire dans le cahier des charges qu'une exception est levée, mais comment le système se comporte dans un tel cas.

Si vous n'avez pas tout non technique des parties prenantes, puis SpecFlow est le mauvais outil pour vous! Ne pas gaspiller son énergie dans la création d'entreprise lisible spécifications si personne n'est intéressé par la lecture de!

Il y a des BDD outils qui mettent l'accent sur le niveau de l'unité de comportement. Dans .NET le plus populaire est MSpec (http://github.com/machine/machine.specifications). BDD sur le niveau de l'unité peut également être facilement pratiques standard de l'unité de test de cadres.

Cela dit, vous pourriez toujours vérifier une exception dans SpecFlow.

Voici un peu plus de discussion de la bdd sur le niveau de l'unité vs bdd sur les longs-niveau: SpecFlow/BDD vs Tests Unitaires BDD pour les Tests d'Acceptation vs BDD pour les Tests Unitaires (ou: ATDD vs ATS)

Aussi un coup d'oeil à ce blog: La classification des Outils de BDD (Unité-Test-Driven vs Test d'Acceptation) et un peu de BDD histoire

Answer 4

En changeant le scénario de ne pas avoir une exception est un bon moyen d'avoir le scénario plus orientée sur l'utilisateur. Toutefois, si vous avez toujours besoin d'avoir de travail, veuillez considérer les points suivants:

1. Intercepter une exception (je vous recommande vraiment attraper les exceptions spécifiques, à moins que vous vraiment besoin de rattraper toutes) dans l'étape qui appelle une opération et de le transmettre au scénario de contexte.

   [When("I press add")]
   public void WhenIPressAdd()
   {
      try
      {
        _calc.Add();
      }
      catch (Exception err)
      {
         ScenarioContext.Current[("Error")] = err;
      }
   }
   

2. Valider que l'exception est stocké dans le scénario de

   [Then(@"it should throw an exception")]
   public void ThenItShouldThrowAnException()
   {
         Assert.IsTrue(ScenarioContext.Current.ContainsKey("Error"));
   }
   

P. S. Il est très proche de l'un de ces réponses. Toutefois, si vous essayez d'obtenir la valeur de ScenarioContext en utilisant la syntaxe comme ci-dessous:

var err = ScenarioContext.Current["Error"]

il va lever une exception dans le cas où si "l'Erreur" la clé n'existe pas (et qui ne manquera pas de tous les scénarios d'effectuer des calculs avec les paramètres corrects). Donc, ScenarioContext.Current.ContainsKey peut-être un peu plus approprié

Answer 5

Dans le cas où vous êtes tester les interactions de l'utilisateur, je ne conseil ce qui a déjà été dit à ce sujet en se concentrant sur l'expérience de l'utilisateur: "Ensuite, l'utilisateur est présenté avec un message d'erreur". Mais, dans le cas où vous essai d'un niveau en dessous de l'INTERFACE utilisateur, j'aimerais partager mon expérience:

Je suis en utilisant SpecFlow de développer une couche de gestion. Dans mon cas, je ne se soucient pas de l'INTERFACE utilisateur interactions, mais je trouve toujours très utile à l'approche BDD et SpecFlow.

Dans la couche de je ne veux pas les specs qui disent "Ensuite, l'utilisateur est présenté avec un message d'erreur", mais en fait, la vérification que le service répond correctement à une saisie erronée. Je l'ai fait pendant un moment ce qui a déjà été dit à propos de la capture de l'exception à la "Quand" et en vérifiant à l' "Alors", mais je trouve que cette option n'est pas optimal, car si vous réutilisez le "Quand" étape vous pourriez avaler une exception dans le cas où vous ne l'attendez pas.

Actuellement, je suis en utilisant explicite "Puis" clauses, quelques fois sans le "Quand", de cette façon:

Scenario: Adding with an empty stack causes an error
     Given I have entered nothing into the calculator
     Then adding causes an error X

Cela me permet de m'spécifiquement code de l'action et à l'exception de détection en une seule étape. Je peux le réutiliser pour tester que de nombreux cas d'erreur que je veux et ça ne fait pas de moi d'ajouter un code non lié à la non faute de "Quand" étapes.