2010-06-20 4 views
2

Ceci est une question débutant FitNesse, si nue avec moi. Gojko Adzic, dans son livre Test Driven .NET Development with FitNesse, donne quelques conseils de base sur la réduction du code de test. Il existe une méthode appelée LogIn qui, en fonction du nom d'utilisateur et du mot de passe, renvoie l'identifiant du joueur ou déclenche une exception lorsqu'il n'y a pas de tel joueur enregistré. Voici la version initiale du code de test:Gestion des exceptions dans FitNesse

public class CheckLogIn : fit.ColumnFixture 
{ 
    public string username; 
    public string password; 

    public int LoggedInAsPlayerId() 
    { 
     try 
     { 
      SetUpTestEnvironment.playerManager.LogIn(username, password); 
      return true; 
     } 
     catch (Exception) 
     { 
      return false; 
     } 
    } 
} 

Il est ensuite remplacé par une version plus courte:

public class CheckLogIn : fit.ColumnFixture 
{ 
    public string username; 
    public string password; 

    public int LoggedInAsPlayerId() 
    { 
     return SetUpTestEnvironment.playerManager.LogIn(username, password); 
    } 
} 

Maintenant, le second test a un bonus supplémentaire de vérifier si un identifiant correct est retourné, mais cela ne vous permet pas de vérifier si le système rejette un utilisateur inconnu/mot de passe incorrect. Y at-il une valeur spéciale qui peut être utilisée dans une colonne pour indiquer une exception? Ou dois-je combiner les deux tests pour couvrir tous les scénarios? Je me souviens, même si vaguement en ce moment même, qu'il y avait une sorte de test d'unité pour gérer les exceptions, mais je suis sûr que quelqu'un a déjà posé des questions à ce sujet, donc je ne veux pas répéter. À moins que la communauté ne soit d'accord avec cela, veuillez suggérer une meilleure pratique pour tester de telles méthodes.

Dans le cas où je ne suis pas clair:

Dire que je suis un joueur inscrit: john.doe/test123/101 (nom d'utilisateur/mot de passe/identifiant). Deux des combinaisons que je voudrais tester le système contre sont john.doe/test123/101 et john.doe/johnny/<WrongUserOrPasswordException>

Répondre

0

Il y a deux mots-clés de fixation qui permettent la vérification des exceptions:

  • error - quand une exception doit être levée pendant le test
  • exception - pour vérifier une exception particulière

Cela a été fait bien expliqué sur le following page du livre ... Mon mauvais pour ne pas le remarquer tout de suite. Peut-être que quelqu'un trouvera cette information utile, alors je ne supprime pas la question.