Unité testant les méthodes void/signes de contes d'objets moqueurs

Question

Lorsque vous testez une base de code, quels sont les signes révélateurs dont j'ai besoin pour utiliser des objets fictifs?

Serait-ce aussi simple que de voir beaucoup d'appels à d'autres objets dans le code?

De même, comment est-ce que je pourrais tester des méthodes qui ne renvoient pas de valeurs? Donc, si une méthode renvoie void mais imprime dans un fichier, est-ce que je vérifie simplement le contenu du fichier? Mocking est pour les dépendances externes, donc c'est littéralement tout, non? Système de fichiers, db, réseau, etc ...

Answer 1

Si quoi que ce soit, j'utilise probablement trop de mocks.

Chaque fois qu'une classe appelle une autre, en général je moque cet appel, et je vérifie que l'appel a été fait avec les paramètres corrects. Sinon où, je vais avoir un test unitaire qui vérifie le code concret de l'objet mocké se comporte correctement.

Exemple:

[Test] 
public void FooMoo_callsBarBaz_whenXisGreaterThan5() 
{ 
    int TEST_DATA = 6; 
    var bar = new Mock<Bar>(); 
    bar.Setup(x => x.Baz(It.Is<int>(i == TEST_DATA))) 
     .Verifiable(); 

    var foo = new Foo(bar.Object); 

    foo.moo(TEST_DATA); 

    bar.Verify(); 
} 

... 
[Test] 
public void BarBaz_doesSomething_whenCalled() 
{ 
    // another test 
} 

La chose pour moi, si j'essaie de tester beaucoup de classes comme un grand glob, alors il est généralement tonnes de code de configuration. Non seulement cela est assez déroutant à lire que vous essayez de comprendre toutes les dépendances, mais c'est très fragile quand des changements doivent être faits. Je préfère de loin les petits tests succincts. Plus facile à écrire, plus facile à maintenir, plus facile à comprendre l'intention du test.

Answer 2

Les tests unitaires sont uniquement pour un morceau de code qui fonctionne de manière autonome en lui-même. Cela signifie qu'il ne dépend pas d'autres objets pour faire son travail. Vous devriez utiliser des simulacres si vous faites de la programmation pilotée par les tests ou de la programmation Test-First. Vous créez un simulacre (ou stub comme j'aime l'appeler) de la fonction que vous allez créer et définissez certaines conditions pour que le test passe. A l'origine, la fonction renvoie false et le test échoue, ce qui est attendu ... alors vous écrivez le code pour faire le vrai travail jusqu'à ce qu'il passe. Mais ce que je pense que vous faites allusion à est des tests d'intégration, pas des tests unitaires. Dans ce cas, vous devez utiliser des mock si vous attendez que d'autres programmeurs terminent leur travail et que vous n'ayez pas accès aux fonctions ou aux objets qu'ils sont en train de créer. Si vous connaissez l'interface, qui, je l'espère, vous raillez autrement est inutile et une perte de temps, alors vous pouvez créer une version simplifiée de ce que vous espérez obtenir dans le futur.

En bref, les mocks sont mieux utilisés lorsque vous attendez d'autres personnes et que vous avez besoin de quelque chose pour terminer votre travail.

Vous devriez toujours retourner une valeur si possible. Parfois, vous rencontrez des problèmes lorsque vous renvoyez déjà quelque chose, mais en C et C++, vous pouvez avoir des paramètres de sortie, puis utiliser la valeur de retour pour la vérification des erreurs.

Answer 3

Mock/stubs/fakes/test double/etc. sont bien dans les tests unitaires, et permettent de tester la classe/système sous test en isolation. Les tests d'intégration peuvent ne pas utiliser de faux-semblant; ils frappent réellement la base de données ou toute autre dépendance externe.

Vous utilisez un simulacre ou un bout quand vous en avez besoin. En général, cela est dû au fait que la classe que vous essayez de tester dépend d'une interface. Pour TDD, vous voulez programmer des interfaces, pas des implémentations, et utiliser l'injection de dépendance (en général).

Un cas très simple:

public class ClassToTest 
{ 
    public ClassToTest(IDependency dependency) 
    { 
     _dependency = dependency; 
    } 

    public bool MethodToTest() 
    { 
     return _dependency.DoSomething(); 
    } 
} 

IDependency est une interface, peut-être un avec des appels coûteux (accès à la base, les appels de service Web, etc.). Une méthode d'essai peut contenir un code similaire à:

// Arrange 

var mock = new Mock<IDependency>(); 

mock.Setup(x => x.DoSomething()).Returns(true); 

var systemUnderTest = new ClassToTest(mock.Object); 

// Act 

bool result = systemUnderTest.MethodToTest(); 

// Assert 

Assert.That(result, Is.True); 

Notez que je fais des tests d'état (comme suggéré @Finglas), et je ne faire valoir contre le système en cours de test (l'instance de la classe I » m test). Je peux vérifier les valeurs de propriété (état) ou la valeur de retour d'une méthode, comme le montre ce cas. Je recommande de lire The Art of Unit Testing, surtout si vous utilisez .NET.