unitaire et SRP (portée/organisation méthode d'essai)

Question

Dire que j'ai une action MVC comme:

public ActionResult CustomerRecord(customerId) 
{ 
    if (_currentUser.CanViewCustomer(customerId)) 
     return View(); 

    else 
    { 
     // user has tried to access an unauthorised record, 
     // should not be here! 
     _logger.Log(new SecurityException()); 
     return View("UnauthorizedAccess"); 
    } 
} 

Pour tester le cas d'une tentative d'accès non autorisé, le nombre de méthodes en cas test soit?

-à-dire que j'écris un seul test:

CustomerRecord_WithUnauthorizedUser_LogsExceptionAndReturnsUnauthorizedView 

ou dois-je écrire deux tests:

CustomerRecord_WithUnauthorizedUser_LogsException 
CustomerRecord_WithUnauthorizedUser_ReturnsUnauthorizedView 

Je suppose que le problème est que techniquement le contrôleur viole SRP, mais je ne voir cela comme étant un problème en soi (veuillez me corriger si vous n'êtes pas d'accord). Je ne suis juste pas sûr de savoir comment cela mappe pour tester les méthodes. Un test par responsabilité de la méthode, ou un test par voie unique à travers la méthode?

Answer 1

Votre contrôleur est pas nécessairement viole SRP en faisant deux choses - il est toujours seulement obtenu une responsabilité (contrôle).

Dans cet exemple précis, je vous déconseille d'affirmer qu'un appel de journal est effectué. Cela n'affectera pas la fonctionnalité de votre application si vous supprimez l'instruction de journal. Les tests unitaires de surspécification les rendent cassants et douloureux à maintenir, ce qui explique en partie pourquoi j'aime tellement BDD.

Si vous deviez audit chaque tentative a échoué alors je suppose que ce test la valeur unitaire, donc si c'est ce que vous faites alors lire:

En général, vous ne devriez avoir une affirmation (peut-être vous Je devrais appeler une méthode Assert ou deux pour faire une assertion sémantique) par test unitaire - essentiellement parce que c'est agréable de pouvoir regarder le nom du test échoué et de savoir exactement ce qui ne va pas sans avoir à regarder le code . Donc je recommanderais d'avoir deux tests ...

Answer 2

Je préfère l'affirmation par test (ou la responsabilité comme vous l'avez dit) parce qu'il est immédiatement clair quelle partie du chemin du code a échoué s'il y a un problème. Cela suppose que vous nommez vos tests (vos exemples le font) d'une manière compréhensible lors de la lecture des résultats de vos tests.