Ogni metodo restituisce un valore per Unit Testing?

Question

Ogni metodo restituisce un valore per Unit Testing?

#1 da (19 voti)

9

Sto imparando a creare semplici unit test per eventualmente (e spero) iniziare a fare solo TDD; per ora sto provando a scrivere test per il codice già scritto per vedere cosa potrebbe causare problemi. Questo è uno di questi.

Diciamo che ho questa semplice classe (con Typescript- > Javascript):

class PrivateStuff {
    greeting: string;
    private _thisIsPrivate;

    constructor(isPrivate: boolean) {
        this._thisIsPrivate = isPrivate;
    }

    setPrivate(option) {
        this._thisIsPrivate = option;
        console.log("_thisIsPrivate changed to : " + option);
    }

    getPrivate() {
        console.log("_thisIsPrivate is : " + this._thisIsPrivate);
        return this._thisIsPrivate;        
    }
}

E lo uso in questo modo:

let privateStuff = new PrivateStuff(false);

let buttonSet = document.createElement('button');
buttonSet.textContent = "Set True";
buttonSet.onclick = function () {
    privateStuff.setPrivate(true);
}

let buttonGet = document.createElement('button');
buttonGet.textContent = "Get";
buttonGet.onclick = function() {
    console.log(privateStuff.getPrivate());
}
document.body.appendChild(buttonSet);
document.body.appendChild(buttonGet);

setPrivate() non ha bisogno di restituire nulla, ma a causa di ciò non posso testarlo. Quando creo un test unitario, dovrei rifattorizzare il codice?

Se facessi TDD, dovrei sempre creare metodi che restituiscano qualcosa solo per poterlo testare? O mi manca qualcosa?

P.S. Puoi vedere ed eseguire il codice qui

tdd unit-testing

posta distante 14.02.2017 - 22:16

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing

Quanto è utile il "vero" dimensionamento delle variabili di C? Quanto tempo può un programmatore concentrarsi in un giorno? [chiuso]

score 19 · Accepted Answer

Immagino che il tuo equivoco qui sia che un "soggetto sotto test" deve essere sempre un metodo a sé stante. Ma non è vero, anche se alcuni metodi possono essere testati senza usare altri metodi, la dimensione tipica di un SUT è una classe, o alcuni metodi e funzioni di interazione di una classe. Quindi se hai un metodo che modifica lo stato interno di un oggetto, ci deve essere sempre qualche cambiamento visibile esternamente al comportamento di quell'oggetto (altrimenti non avrebbe senso avere il metodo nel primo posto). E in un test unitario, puoi validare esattamente questo comportamento.

Ad esempio, supponiamo di avere una classe NumberFormatter con la responsabilità di formattare i numeri in virgola mobile in un modo predefinito. Supponiamo che contenga un metodo FormatToString(double d) . Supponiamo inoltre che abbia un metodo setDecimalSeparator , ma non getDecimalSeparator . Tuttavia puoi facilmente scrivere un test se dopo una chiamata a setDecimalSeparator il metodo FormatToString si comporta in un modo desiderato. Un test del genere potrebbe assomigliare a questo

  var nf = new NumberFormatter();
  nf.setDecimalSeparator(".");
  AssertEqual("12.34",nf.FormatToString(12.34))
  nf.setDecimalSeparator(",");
  AssertEqual("12,34",nf.FormatToString(12.34))

Quindi questo è un test significativo di setDecimalSeparator , un metodo senza un valore di ritorno.