L'iniezione di dipendenza non spinge il carico di test più in basso nella catena?

8

Sto imparando sull'integrazione delle dipendenze e mentre riesco a vedere il fascino di questo quando scrivo le librerie funzionali, non riesco a vedere come risolve nulla quando sarai anche quello che usa le librerie.

Rende la verifica della libreria molto più semplice, perché non c'è molto da testare.

Ma alla fine dovrai testare la tua funzione iniettata quando usi la libreria e devi occuparti delle funzioni di mocking e stub dalla libreria standard.

Questo è un caso concreto di cui mi occupo in Node.js :

function compile(options) {
  var files = options.files;
  var texCompiler = options.texCompiler;
  var pdfMerger = options.pdfMerger;

  return Promise.all(files.map(texCompiler(files)))
    .then(pdfMerger);
}

È banale da testare: iniettare oggetti mock o spiare come texCompiler e pdfMerger è un pezzo di torta perché la funzione in realtà non fa molto. Tutto quello che posso testare è che entrambe le funzioni sono chiamate nella giusta sequenza.

Tuttavia, non mi salva dal testare le mie funzioni texCompiler e pdfMerger . Sembrano qualcosa del genere:

var tex2Pdf = Promise.method(function tex2Pdf(tex_doc) {
    var latex_command = 'pdflatex';
    var pdf_output_filename = path.parse(tex_doc).name + '.pdf';
    var cmd = latex_command + ' ' + tex_doc;
    var options = {
      cwd: path.resolve(tex_doc, '..') // pdflatex will only look for custom
      // cls files in the cwd and includes relative to the cwd
    };
    child_process.spawn(cmd, options)
      .on('end', function() {
        console.log('tex2Pdf finish');
        debugger;
        return path.resolve(tex_doc, '..', pdf_output_filename);
      })
      .on('error', function(e) {
        throw e;
      });
});


var mergeTwoPdf = Promise.method(function mergeTwoPdf(pdf_files) {
  var output_file = randomId() + '.pdf';
  var cmd = 'gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=' + output_file + ' ' + pdf_files[0] + ' ' + pdf_file[1];
  child_process.spawn(cmd)
    .on('finish', function() {
      return output_file;
    })
  .on('error', function(e) {
    throw (e);
  });
});

Questa è la cosa reale, ed è un dolore più grande da testare. Devo simulare child_process.spawn con una spia per assicurarmi che venga chiamato con gli argomenti giusti, ma in realtà non fa nulla, perché non voglio in realtà unire alcun file PDF quando eseguo i test e le mie mamme hanno per emettere gli eventi giusti in modo che la funzione non sia bloccata.

Questi sono problemi che avrei avuto se non avessi iniettato la dipendenza nel mio primo snippet e usato invece queste funzioni. E mi sembra davvero di spingere il problema più in basso senza risolverlo.

Sto fraintendendo l'iniezione di dipendenza? Sto sbagliando?

    
posta springloaded 13.10.2015 - 18:32
fonte

2 risposte

8

Ti manca il punto di test sembra.

That is trivial to test: injecting mocks or spies as the texCompiler and pdfMerger is a piece of cake because the function really doesn't do much at all. All I can test is that both functions are called in the right sequence.

Impressionante! se la funzione sta facendo un lavoro banale, allora il test dovrebbe essere banale. Allo stesso modo, se tutta quella funzione in realtà sta chiamando A e poi B, non stai convalidando gran parte del tuo codice.

L'intero punto dei buoni test è isolare ciò che stai testando, quindi quando il test fallisce, puoi sapere meglio cosa è andato storto. L'iniezione di dipendenza lo aiuta.

And it really feels like I'm pushing the problem further down without solving it.

Certo, in questo caso non lo stai "risolvendo" perché il tuo codice ha delle brutte dipendenze difficili da isolare. Devi lavorare con il filesystem. Devi chiamare questi processi esterni. A volte questa è la natura della bestia.

Iniezione delle dipendenze non rimuove le dipendenze, le capovolge semplicemente in modo che tu possa scegliere quello che sono. Questo aiuta a isolare il codice per i test. Aiuta il codice a essere più flessibile quando quelle dipendenze cambiano inevitabilmente. Ma non li uccide: il tuo codice deve ancora essere in grado di fare tutte le stesse cose da qualche parte .

    
risposta data 13.10.2015 - 19:27
fonte
2

Penso che sia il test che stai fraintendendo semmai.

Vorrei testare la tua creazione di file PDF creando un file PDF e confrontandolo con uno conosciuto.

Vorrei testare la fusione dei tuoi file PDF unendo due file PDF e confrontando l'output con, ancora, un file noto.

    
risposta data 13.10.2015 - 18:51
fonte