J'ai commencé à écrire des tests unitaires pour mon projet actuel. Je n'ai pas vraiment d'expérience avec cela cependant. Je veux d’abord complètement "comprendre", donc je n’utilise actuellement ni mon framework IoC ni une bibliothèque moqueuse.

Je me demandais s'il y avait un problème avec la fourniture d'arguments nuls aux constructeurs des objets dans les tests unitaires. Laissez-moi vous donner un exemple de code:

public class CarRadio
{...}


public class Motor
{
    public void SetSpeed(float speed){...}
}


public class Car
{
    public Car(CarRadio carRadio, Motor motor){...}
}


public class SpeedLimit
{
    public bool IsViolatedBy(Car car){...}
}

Encore un autre exemple de code de voiture (MC), réduit aux seules parties importantes de la question. J'ai maintenant écrit un test qui ressemble à ceci:

public class SpeedLimitTest
{
    public void TestSpeedLimit()
    {
        Motor motor = new Motor();
        motor.SetSpeed(10f);
        Car car = new Car(null, motor);

        SpeedLimit speedLimit = new SpeedLimit();
        Assert.IsTrue(speedLimit.IsViolatedBy(car));
    }
}

Le test fonctionne bien. SpeedLimita besoin d'un Caravec un Motorafin de faire sa chose. Cela ne l’intéresse pas CarRadiodu tout, alors j’ai fourni null pour cela.

Je me demande si un objet fournissant une fonctionnalité correcte sans être entièrement construit est une violation de SRP ou une odeur de code. J'ai l'impression que c'est le cas, mais speedLimit.IsViolatedBy(motor)je ne me sens pas bien non plus: une limite de vitesse est violée par une voiture, pas par un moteur. Peut-être ai-je simplement besoin d'une perspective différente pour les tests unitaires par rapport au code fonctionnel, parce que l'objectif est de tester uniquement une partie du tout.

La construction d'objets avec null dans les tests unitaires a-t-elle une odeur de code?

Dans le cas de l'exemple ci-dessus, il est raisonnable qu'un Carpeut exister sans un CarRadio. Dans ce cas, je dirais que non seulement il est acceptable de passer à zéro CarRadioparfois, je dirais que c'est obligatoire. Vos tests doivent s'assurer que l'implémentation de la Carclasse est robuste et ne lève pas d'exceptions de pointeur nul lorsque aucun CarRadion'est présent.

Cependant, prenons un exemple différent - considérons a SteeringWheel. Supposons qu'un Cara doit avoir un SteeringWheel, mais le test de vitesse ne s'en soucie pas vraiment. Dans ce cas, je ne passerais pas un zéro SteeringWheelcar cela pousserait la Carclasse dans des endroits où elle n’aurait pas été conçue. Dans ce cas, vous feriez mieux de créer une sorte de DefaultSteeringWheelqui (pour continuer la métaphore) est bloqué en ligne droite.

La construction d'objets avec null dans les tests unitaires a-t-elle une odeur de code?

Oui. Notez la définition C2 de l' odeur de code : "un CodeSmell est un indice que quelque chose pourrait être faux, pas une certitude."

Le test fonctionne bien. SpeedLimit a besoin d'une voiture avec un moteur pour faire son travail. CarRadio ne l’intéresse pas du tout, j’ai donc fourni null pour cela.

Si vous essayez de démontrer que speedLimit.IsViolatedBy(car)cela ne dépend pas de l' CarRadioargument transmis au constructeur, il serait probablement plus clair pour le futur responsable de la maintenance de rendre cette contrainte explicite en introduisant un double test qui échoue au test s'il est appelé.

Si, comme il est plus probable, vous essayez simplement de vous épargner le travail de création d’une application CarRadioque vous savez inutilisée dans ce cas, vous devriez remarquer que

• il s'agit d'une violation de l'encapsulation (vous laissez CarRadiole test non utilisé s'infiltrer dans le test)
• vous avez découvert au moins un cas où vous souhaitez créer un Carsans spécifierCarRadio

Je soupçonne fortement que le code essaie de vous dire que vous voulez un constructeur qui ressemble à

public Car(IMotor motor) {...}

et puis ce constructeur peut décider quoi faire avec le fait qu'il n'y a pasCarRadio

public Car(IMotor motor) {
    this(null, motor);
}

ou

public Car(IMotor motor) {
    this( new ICarRadio() {...} , motor);
}

ou

public Car(IMotor motor) {
    this( new DefaultRadio(), motor);
}

etc.

Il s’agit de passer null à quelque chose d’autre en testant SpeedLimit. Vous pouvez voir que le test s'appelle "SpeedLimitTest" et que le seul Assert vérifie une méthode de SpeedLimit.

C'est une deuxième odeur intéressante: pour tester SpeedLimit, vous devez construire une voiture entière autour d'une radio, même si la seule chose qui intéresse le contrôle SpeedLimit est probablement la vitesse .

Cela pourrait être un indice qui SpeedLimit.isViolatedBydevrait accepter une interface de rôle que la voiture implémente , plutôt que d'exiger une voiture entière.

interface IHaveSpeed {
    float speed();
}

class Car implements IHaveSpeed {...}

IHaveSpeedest un nom vraiment moche; Espérons que votre langue de domaine aura une amélioration.

Avec cette interface en place, votre test SpeedLimitpourrait être beaucoup plus simple.

public void TestSpeedLimit()
{
    IHaveSpeed somethingTravelingQuickly = new IHaveSpeed {
        float speed() { return 10f; }
    }

    SpeedLimit speedLimit = new SpeedLimit();
    Assert.IsTrue(speedLimit.IsViolatedBy(somethingTravelingQuickly));
}

La construction d'objets avec null dans les tests unitaires a-t-elle une odeur de code?

Non

Pas du tout. Au contraire, si NULLest une valeur qui est disponible comme argument (certaines langues ont des constructions qui DISALLOW passant d'un pointeur NULL), vous devez le tester.

Une autre question est ce qui se passe lorsque vous passez NULL. Mais c’est exactement ce qu’est un test unitaire: s’assurer qu’un résultat défini est obtenu pour chaque entrée possible. Et NULL est une entrée potentielle, vous devriez donc avoir un résultat défini et vous devriez avoir un test pour cela.

Donc, si votre voiture est censée être constructible sans radio, vous devriez écrire un test pour cela. Si ce n'est pas le cas et est supposé lancer une exception, vous devriez écrire un test pour cela.

De toute façon, oui, vous devriez écrire un test NULL. Ce serait une odeur de code si vous l'omettiez. Cela signifierait que vous avez une branche de code non testée qui, comme vous venez de l’imaginer, serait exempte de bugs.

Veuillez noter que je suis d’accord avec les autres réponses pour dire que votre code testé pourrait être amélioré. Néanmoins, si le code amélioré a des paramètres qui sont des pointeurs, le passage NULLmême pour le code amélioré est un bon test. Je voudrais un test pour montrer ce qui se passe lorsque je passe en NULLtant que moteur. Ce n'est pas une odeur de code, c'est le contraire d'une odeur de code. C'est tester.

Personnellement, j'hésiterais à injecter des valeurs nulles. En fait, chaque fois que j'injecte des dépendances dans un constructeur, l'une des premières choses que je fais est de générer une exception ArgumentNullException si ces injections sont nulles. De cette façon, je peux les utiliser en toute sécurité dans ma classe, sans avoir recours à des dizaines de contrôles nuls répartis. Voici un modèle très commun. Notez l'utilisation de readonly pour vous assurer que les dépendances définies dans le constructeur ne peuvent pas être définies sur null (ou toute autre chose) par la suite:

class Car
{
   private readonly ICarRadio _carRadio;
   private readonly IMotor _motor;

   public Car(ICarRadio carRadio, IMotor motor)
   {
      if (carRadio == null)
         throw new ArgumentNullException(nameof(carRadio));

      if (motor == null)
         throw new ArgumentNullException(nameof(motor));

      _carRadio = carRadio;
      _motor = motor;
   }
}

Avec ce qui précède, je pourrais peut-être avoir un ou deux tests unitaires, dans lesquels j'injecte des valeurs null, juste pour m'assurer que mes contrôles des valeurs Null fonctionnent correctement.

Cela dit, cela ne pose plus aucun problème, une fois que vous faites deux choses:

1. Programmez aux interfaces au lieu des classes.
2. Utilisez un framework moqueur (comme Moq pour C #) pour injecter des dépendances simulées au lieu de NULL.

Donc, pour votre exemple, vous auriez:

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

...
var car = new Car(new Moq<ICarRadio>().Object, new Moq<IMotor>().Object);

Plus de détails sur l'utilisation de Moq peuvent être trouvés ici .

Bien sûr, si vous voulez comprendre sans vous moquer, vous pouvez toujours le faire, du moment que vous utilisez des interfaces. Créez simplement une CarRadio et un moteur factices comme suit, puis injectez-les:

class DummyCarRadio : ICarRadio
{
   ...
}
class DummyMotor : IMotor
{
   ...
}

...
var car = new Car(new DummyCarRadio(), new DummyMotor())

Ce n'est pas juste d'accord, c'est une technique bien connue de rupture de dépendance pour obtenir du code hérité dans un faisceau de test. (Voir «Utilisation efficace du code hérité» par Michael Feathers.)

Ça sent? Bien...

Le test ne sent pas. Le test fait son travail. Il déclare «cet objet peut être nul et le code testé continue à fonctionner correctement».

L'odeur est dans la mise en œuvre. En déclarant un argument constructeur, vous déclarez que «cette classe a besoin de cette chose pour fonctionner correctement». Évidemment, c'est faux. Tout ce qui est faux est un peu malodorant.

Revenons aux premiers principes.

Un test unitaire teste certains aspects d'une classe.

Il y aura cependant des constructeurs ou des méthodes qui prendront d'autres classes en tant que paramètres. Votre façon de les gérer varie d’un cas à l’autre, mais la configuration doit être minimale, car elles sont tangentes à l’objectif. Il peut arriver que le passage d'un paramètre NULL soit parfaitement valide, par exemple une voiture sans radio.

Je suppose ici que nous testons simplement la ligne de course pour commencer (pour continuer le thème de la voiture), mais vous pouvez également passer à NULL à d’autres paramètres pour vérifier que tout code défensif et mécanisme de remise d’exception fonctionnent comme prévu. Champs obligatoires.

Jusqu'ici tout va bien. Cependant, que se passe-t-il si NULL n'est pas une valeur valide? Eh bien, vous êtes ici dans le monde trouble des moqueurs, des talons, des mannequins et des faux .

Si tout cela vous semble trop compliqué, vous utilisez déjà un mannequin en passant NULL dans le constructeur Car, car il s'agit d'une valeur qui ne sera pas potentiellement utilisée.

Ce qui devrait devenir clair assez rapidement, c’est que vous êtes potentiellement en train de manipuler votre code avec beaucoup de manipulations NULL. Si vous remplacez les paramètres de classe par des interfaces, vous ouvrez également la voie au mocking, aux DI, etc., ce qui les rend beaucoup plus simples à gérer.

Jetant un coup d'oeil à votre conception, je suggérerais qu'un Carest composé d'un ensemble de Features. Une fonctionnalité peut-être une CarRadio, ou EntertainmentSystemqui peut être composée d'éléments tels qu'un CarRadio, DvdPlayeretc.

Donc, au minimum, vous devriez construire un Caravec un ensemble de Features. EntertainmentSystemet CarRadioseraient des implémenteurs de l'interface (Java, C #, etc.) de public [I|i]nterface Featureet ceci serait une instance du modèle de conception Composite.

Par conséquent, vous construirez toujours un Caravec Featureset un test unitaire n’instanciera jamais un Carsans Features. Bien que vous puissiez envisager de vous moquer d'un ensemble BasicTestCarFeatureSetcomportant un ensemble minimal de fonctionnalités requises pour votre test le plus élémentaire.

Juste quelques pensées.

John