Exemple de test de régression et test d'unité - Application Windows Forms LOB

Question

Nous avons une application LOB Winforms qui suit autant que possible le modèle MVP.

À chaque nouvelle version, nous voulons tester contre toute régression.

L'approche actuelle est que chaque fois qu'un testeur est un bug/crash, nous reproduisons le bug, puis insérons un test en utilisant NUnit. Habituellement, ce test essaie de reproduire la chaîne d'actions suivie par l'utilisateur, donc nous finissons avec des tests comme:

Le test prépare généralement le contexte, charge les données, et exécute l'action cliquée par l'utilisateur pour reproduire le bug . Ensuite, le bug est corrigé et le test est réexécuté. Et ainsi de suite ..., jusqu'à ce que nous ayons une grande base de tests existants (régression?). Exemple d'un tel test est:

[Test] 
public void MenuX_OperationY_buttonDoZ_Click_ERROR_DESCRIPTION() 
{ 
    // The presenter prepares Context & Load Data associated with Menu X 
    PrsMenuX.PrepareContext(); 
    PrsMenuX.LoadData(); 

    // Do Operation Y 
    PrsMenuX.OperationY(); 

    // Click on Button Do Z 
    try 
    { 
     PrsMenuX.ButtonDoZ_Click(); 
    } 
    catch (Exception ex) 
    { 
     Assert.Fail(ex.Message); 
    } 
} 

Alors ma question, est-ce la bonne approche? NUnit est-il le bon outil pour cela, et comment l'améliorer? Les tests doivent-ils reproduire les actions de l'utilisateur ou faut-il tester uniquement les fonctions de bas niveau qui composent l'action de chaque utilisateur?

Answer 1

Cela dépend de ce qui échoue. Si c'est un bogue dans un algorithme de votre code qui échoue, alors il devrait probablement être testé par un test unitaire. S'il s'agit davantage d'un bug d'utilisation inattendu, il devrait s'agir d'un test d'acceptation/comportement de niveau plus élevé. Et juste parce que vous ajoutez un test unitaire ne signifie pas que vous ne devriez pas ajouter un test de plus haut niveau.

Il semble également qu'il soit un peu tard pour ajouter des tests uniquement après la détection des bogues. Il serait préférable que les tests soient écrits lorsqu'une nouvelle fonctionnalité a été ajoutée ou qu'une fonctionnalité existante a été modifiée. Il est généralement plus facile d'écrire de bons tests en même temps que le code, plutôt que d'écrire un test pour un code inconnu ou oublié plus tard. Pratiquer ceci empêchera plus de bogues de ne pas être introduits en premier lieu.