Ho iniziato a scrivere alcuni test unitari per il mio progetto attuale. Non ho davvero esperienza con esso però. Prima voglio "capirlo" completamente, quindi attualmente non sto usando né il mio framework IoC né una libreria beffarda.

Mi chiedevo se ci fosse qualcosa di sbagliato nel fornire argomenti nulli ai costruttori di oggetti nei test unitari. Lasciami fornire un codice di esempio:

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){...}
}

Ancora un altro esempio di codice auto (TM), ridotto solo alle parti importanti per la domanda. Ora ho scritto un test simile a questo:

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));
    }
}

Il test funziona bene. SpeedLimitha bisogno di un Carcon un Motorper fare la sua cosa. Non è affatto interessato a CarRadioa, quindi ho fornito null per quello.

Mi chiedo se un oggetto che fornisce la corretta funzionalità senza essere completamente costruito sia una violazione di SRP o un odore di codice. Ho questa fastidiosa sensazione che lo faccia, ma speedLimit.IsViolatedBy(motor)non mi sento bene - un limite di velocità viene violato da un'auto, non da un motore. Forse ho solo bisogno di una prospettiva diversa per i test unitari rispetto al codice di lavoro, perché l'intera intenzione è testare solo una parte del tutto.

Costruire oggetti con null in unit test è un odore di codice?

Nel caso dell'esempio precedente, è ragionevole che a Carpossa esistere senza a CarRadio. In tal caso, direi che non solo è accettabile passare un null a CarRadiovolte, direi che è obbligatorio. I test devono garantire che l'implementazione della Carclasse sia solida e che non generi eccezioni di puntatore null quando noCarRadio è presente.

Tuttavia, facciamo un esempio diverso: consideriamo a SteeringWheel. Supponiamo che a Cardebba avere un SteeringWheel, ma al test di velocità non interessa davvero. In questo caso, non vorrei passare un null SteeringWheelpoiché questo sta spingendo la Carclasse in luoghi dove non è progettata per andare. In questo caso, faresti meglio a creare una sorta di DefaultSteeringWheelquale (per continuare la metafora) è bloccato in linea retta.

Costruire oggetti con null in unit test è un odore di codice?

Sì. Nota la definizione C2 di odore di codice : "un CodeSmell è un suggerimento che qualcosa potrebbe essere sbagliato, non una certezza".

Il test funziona bene. SpeedLimit ha bisogno di un'auto con un motore per fare la sua cosa. Non è affatto interessato a un CarRadio, quindi ho fornito null per questo.

Se stai cercando di dimostrare che speedLimit.IsViolatedBy(car)non dipende dalCarRadio dall'argomento passato al costruttore, probabilmente sarebbe più chiaro al futuro manutentore rendere esplicito quel vincolo introducendo un doppio di test che fallisce il test se viene invocato.

Se, come è più probabile, stai solo cercando di salvarti il ​​lavoro di creazione di un CarRadioche sai che non è usato in questo caso, dovresti notare che

• questa è una violazione dell'incapsulamento (stai lasciando che il fatto che CarRadionon sia utilizzato fuoriesca dal test)
• hai scoperto almeno un caso in cui desideri creare un Carsenza specificare aCarRadio

Sospetto fortemente che il codice stia cercando di dirti che vuoi un costruttore che assomigli

public Car(IMotor motor) {...}

e quindi quel costruttore può decidere cosa fare con il fatto che non c'èCarRadio

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

o

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

o

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

eccetera.

Si tratta di passare null a qualcos'altro durante il test di SpeedLimit. Puoi vedere che il test si chiama "SpeedLimitTest" e l'unico Assert sta controllando un metodo di SpeedLimit.

Questo è un secondo odore interessante - per testare SpeedLimit, devi costruire un'intera macchina attorno a una radio, anche se l'unica cosa a cui probabilmente importa il controllo SpeedLimit è la velocità .

Questo potrebbe essere un suggerimento che SpeedLimit.isViolatedBydovrebbe accettare un'interfaccia di ruolo implementata dall'auto , piuttosto che richiedere un'intera auto.

interface IHaveSpeed {
    float speed();
}

class Car implements IHaveSpeed {...}

IHaveSpeedè un nome davvero schifoso; speriamo che il tuo linguaggio di dominio abbia un miglioramento.

Con questa interfaccia attiva, il test SpeedLimitpotrebbe essere molto più semplice

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

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

Costruire oggetti con null in unit test è un odore di codice?

No

Affatto. Al contrario, se NULLè un valore disponibile come argomento (alcune lingue potrebbero avere costrutti che non consentono il passaggio di un puntatore null), è necessario verificarlo.

Un'altra domanda è cosa succede quando passi NULL. Ma questo è esattamente ciò che riguarda un test unitario: assicurarsi che si stia verificando un risultato definito per ogni possibile input. Ed NULL è un potenziale input, quindi dovresti avere un risultato definito e dovresti avere un test per quello.

Quindi, se la tua auto dovrebbe essere costruibile senza una radio, dovresti scrivere un test per questo. Se non lo è e dovrebbe generare un'eccezione, dovresti scrivere un test per questo.

Ad ogni modo, sì, dovresti scrivere un test per NULL. Sarebbe un odore di codice se lo lasciassi fuori. Ciò significherebbe che hai un ramo di codice non testato che hai appena assunto sarebbe magicamente privo di bug.

Nota che sono d'accordo con le altre risposte che il tuo codice in prova potrebbe essere migliorato. Tuttavia, se il codice migliorato ha parametri che sono puntatori, passare NULLanche per il codice migliorato è un buon test. Vorrei un test per mostrare cosa succede quando passo NULLcome motore. Non è un odore di codice, è l'opposto di un odore di codice. Sta testando.

Personalmente, esiterei a iniettare null. In effetti, ogni volta che inietto dipendenze in un costruttore, una delle prime cose che faccio è sollevare ArgumentNullException se quelle iniezioni sono nulle. In questo modo posso tranquillamente usarli all'interno della mia classe, senza dozzine di controlli null sparsi in giro. Ecco un modello molto comune. Nota l'uso di sola lettura per garantire che quelle dipendenze impostate nel costruttore non possano essere impostate su null (o qualsiasi altra cosa) in seguito:

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;
   }
}

Con quanto sopra, potrei forse avere un test di unità o due, in cui iniettare valori null, solo per assicurarmi che i miei controlli null funzionino come previsto.

Detto questo, questo diventa un problema, una volta che fai due cose:

1. Programma per interfacce anziché per classi.
2. Utilizzare un framework beffardo (come Moq per C #) per iniettare dipendenze beffe invece di null.

Quindi per il tuo esempio avresti:

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

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

Maggiori dettagli sull'uso di Moq sono disponibili qui .

Ovviamente, se vuoi capirlo senza prima deridere, puoi comunque farlo, purché utilizzi le interfacce. Basta creare un finto CarRadio e Motor come segue e iniettare quelli invece:

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

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

Non è solo ok, è una tecnica di rottura delle dipendenze ben nota per ottenere il codice legacy in un cablaggio di prova. (Vedi "Lavorare efficacemente con il codice legacy" di Michael Feathers.)

Puzza? Bene...

Il test non ha odore. Il test sta facendo il suo lavoro. Sta dichiarando "questo oggetto può essere nullo e il codice sotto test funziona ancora correttamente".

L'odore è in fase di implementazione. Dichiarando un argomento del costruttore, stai dichiarando "questa classe ha bisogno di questa cosa per funzionare correttamente". Ovviamente, non è vero. Qualcosa di falso è un po 'puzzolente.

Facciamo un passo indietro ai primi principi.

Un test unitario verifica alcuni aspetti di una singola classe.

Vi saranno tuttavia costruttori o metodi che accettano altre classi come parametri. Il modo in cui gestirli varierà da caso a caso, ma l'installazione dovrebbe essere minima poiché sono tangenziali all'obiettivo. Ci possono essere scenari in cui il passaggio di un parametro NULL è perfettamente valido, ad esempio un'auto senza radio.

Sto assumendo qui, che stiamo solo testando la linea di corsa per cominciare (per continuare il tema auto), ma si può anche voler passare NULL ad altri parametri per controllare che qualsiasi meccanismo di codice e distribuendo eccezione difensive funzionano come necessario.

Fin qui tutto bene. Tuttavia, cosa succede se NULL non è un valore valido. Bene, qui sei nel mondo oscuro di beffe, tronconi, manichini e falsi .

Se tutto questo sembra un po 'troppo da affrontare, in realtà stai già utilizzando un manichino passando NULL nel costruttore di auto poiché è un valore che potenzialmente non verrà utilizzato.

Ciò che dovrebbe diventare chiaro abbastanza rapidamente, è che stai potenzialmente sparando il tuo codice con molta gestione NULL. Se sostituisci i parametri di classe con le interfacce, allora apri anche la strada per deridere, DI ecc. Che li rendono molto più semplici da gestire.

Dando un'occhiata al tuo design, suggerirei che a Carsia composto da un set di Features. Una caratteristica può essere una CarRadio, o EntertainmentSystemche può consistere in cose come una CarRadio, DvdPlayerecc.

Quindi, come minimo, dovresti costruire un Carcon un set di Features. EntertainmentSysteme CarRadiosarebbero implementatori dell'interfaccia (Java, C # ecc.) dipublic [I|i]nterface Feature e questa sarebbe un'istanza del modello di progettazione composita.

Pertanto, costruiresti sempre un Carcon Featurese un test unitario non creerebbe mai un'istanza Carsenza Features. Anche se potresti considerare di deridere aBasicTestCarFeatureSet che ha un set minimo di funzionalità richieste per il tuo test di base.

Solo alcuni pensieri.

John