Dove devo fare i test di integrazione in un progetto multi-pacchetto

Question

Dove devo fare i test di integrazione in un progetto multi-pacchetto

#1 da (3 voti)

2

Sfondo:

Sto lavorando su un progetto di nodo che consiste in un pacchetto principale e diversi pacchetti di addon. Affinché il prodotto finale funzioni, è necessario integrare il pacchetto principale e almeno uno dei pacchetti di addon. Questi pacchetti di addon sono fondamentalmente adattatori di database. I pacchetti Addon hanno una dipendenza dalla produzione sul pacchetto principale. Tutti i pacchetti sono pianificati per essere distribuiti come pacchetti npm separati.

Posso fare test unitari e testare la funzionalità di tutti i componenti separatamente. Ma per me, i test di integrazione sono importanti e mettono alla prova un vero database. Dovrei essere in grado di mettere insieme il nucleo e gli addon, per testarli in integrazione.

La domanda è, in quale pacchetto devo fare il test di integrazione?

Esegui i test nei pacchetti di addon. Questo sembra il più "giusto" ed è la prima cosa che ho pensato. Tuttavia, poiché la funzionalità di ciascun addon è molto simile, anche i test sono simili. L'implementazione di centinaia di test simili per ognuno di essi porterà la duplicazione del codice.
Esegui i test nel pacchetto principale. Questo eliminerà definitivamente la duplicazione del codice. Ma causerà una dipendenza di sviluppo dal core agli addon. Inoltre, se è necessario implementare un nuovo componente aggiuntivo, la suite di test di base cambierà?
Crea un pacchetto separato solo per i test di integrazione. Ciò impedirà la duplicazione del codice. Ma è qualcosa di cui non ho mai visto un esempio. Inoltre, l'aggiunta di addon farà cambiare questo pacchetto.

bdd testing integration-tests javascript node.js

posta Gökhan Kurt 03.09.2017 - 13:19

fonte

1 risposta

Leggi altre domande sui tag bdd testing integration-tests javascript node.js

Ricevi i dati in ordine casuale, invia in ordine Sta usando Microsoft Hooks un processo etico per ottenere informazioni non sensibili

score 3 · Accepted Answer

In qualsiasi integrazione esiste una relazione depener e dipendente. Raccomando di creare i test nel dipendente.

Nella tua domanda i pacchetti di addon dipendono dal pacchetto principale, quindi è giusto che tu abbia la prima inclinazione a scrivere i test lì.

since the functionality of each addon is very similar, the tests are also similar. Implementing hundreds of similar tests for each of them will bring code duplication

Create a separate package just for integration testing. This will prevent code duplication.

Questo è un buon approccio al problema. Questi pacchetti vengono solitamente chiamati "suite di test automatizzati" e sono utili in situazioni in cui una specifica (ad esempio l'integrazione con il core) viene testata in modo agnostico rispetto all'implementazione.

But it is something I have never seen an example of

Java ha la suite di test dell'API JDBC per testare i driver del database in modo che terze parti possano creare driver e testarli.

Tinkerpop ha una suite di test per verificare correttamente i database dei grafici di terze parti implementare l'API Tinkerpop

Also, adding addons will cause this package to change.

L'approccio corretto a questo problema, la suite di test non dovrebbe essere accoppiata a qualsiasi specifico addon. Proprio come la suite di test JDBC sopra non sa nulla di ogni driver. Questo pacchetto dovrebbe includere il codice di test, ma ogni addon concreto dovrebbe configurare ed eseguire la suite di test personalizzata in base alle loro esigenze.

In psuedo-code la tua suite di test avrebbe avuto dei test in questo modo:

function testDelete(addon) {
  addon.insert(1, "foo")
  assert(addon.select(1) === "foo")
  addon.delete(1)
  assert(addon.select(1) === null)
}

e il tuo pacchetto addon avrebbe un test come questo:

const addon = new PostgresAddon("localhost", "5432", "user", "pass")
testSuite.testDelete(addon)