Creazione di assiemi separati per diversi tipi di test per lo stesso componente?

Naviga le tue risposte
3

Mi è stato detto da alcuni membri che separare i miei test unitari in diversi gruppi per componenti diversi è il modo migliore per strutturare i test unitari. Ora, ho alcune domande su questa idea.

  1. Quali sono i vantaggi di questo? Organizzazione e isolamento degli errori?
  2. Diciamo che ho un componente chiamato "calculator", e creo un assembly per i test unitari su "calculator". Dovrei creare un assembly separato per i test di integrazione che voglio eseguire su "calculator"? Oppure la definizione di un test di integrazione è un test su più componenti, come "calcolatrice" e quant'altro, che richiederebbe un assembly separato per testarli insieme? In tal caso, avrei un unico assembly per eseguire tutti i test di integrazione per ogni combinazione di componenti?
posta sooprise 31.05.2011 - 23:11
fonte

3 risposte

5

Questa potrebbe essere una strana cosa semantica, ma sembra che tu stia equipaggiando "componente" a "classe". Assocerei normalmente "componente" con "assemblaggio".

In altre parole, un gruppo di test unitario per assemblaggio sotto test. Questa è una configurazione abbastanza comune nella mia esperienza. Lo fai per minimizzare il numero di dipendenze dei tuoi test. Idealmente dovrebbero dipendere solo dall'assemblaggio specifico in fase di test, ma anche nel peggiore dei casi, dipendono ancora solo dalle dipendenze indirette di AUT.

Il test di integrazione è un intero altro animale; Normalmente vorresti che sia totalmente segregato dai test delle tue unità, dal momento che un test di integrazione avrà tutti i tipi di dipendenze ripiegati da varie parti dell'applicazione (ecco perché è chiamato test di integrazione ...). Tieniti lontano, lontano dai test delle tue unità, altrimenti ti troverai a cercare di gestire gli errori di test delle unità e allo stesso tempo. Non divertente.

    
risposta data 01.06.2011 - 04:33
fonte
1

se devi eseguire i test separatamente - ad esempio test unitari su ogni build, test di integrazione una volta al giorno - potrebbe essere utile

o se gli assiemi di test diventano troppo grandi per trovare facilmente le cose in essi

altrimenti non vedo il punto

    
risposta data 01.06.2011 - 04:18
fonte
0

Rispondi a un domanda simile :

In my opinion, unit tests should be placed in a separate assembly from production code. Here are just a few cons of placing unit tests in the same assembly or assemblies as production code are:

Unit tests get shipped with production code. The only thing shipped with product code is production code. Assemblies will be unnecessarily bloated by unit tests. Unit tests can affect build processes like automated or continuous build. I don't really know of any pros. Having an extra project (or 10) isn't a con.

Edit: More Info On Build and Shipping

I would further recommend that any automated build process place production and unit tests into different locations. Ideally, the unit test build process only runs if the production code builds, and copies the product files into the unit tests directory. Doing it this way results in the actual bits being separated for shipping, etc. Additionally, it is fairly trivial to run automated unit testing at this point on all tests in a particular directory.

    
risposta data 27.06.2012 - 22:33
fonte

Leggi altre domande sui tag

Qual è il modo migliore per uno sviluppatore esperto di lavorare su un blog WordPress Come e quando le dimensioni vengono riempite in uno schema di data warehouse?