Devo scrivere test unitari e test di integrazione per un progetto.
Se li tengo insieme, ci sono vantaggi o svantaggi con questo approccio?
In generale: sì, dovresti inserire test di integrazione e unit test in diverse cartelle. Spesso i programmatori non tracciano una linea chiara tra questi due tipi di test e scrivono semplicemente che qualsiasi tipo di test è utile. Ma i test di integrazione tendono ad essere più lenti, perché spesso implicano:
Al contrario, un test unitario potrebbe prendere in giro qualsiasi operazione costosa, quindi i test unitari tendono a essere eseguiti rapidamente (in effetti, la parte più lenta dell'esecuzione del test è spesso il framework di test stesso).
Quando un programmatore sta lavorando sul sistema, si trovano in un ciclo di test di modifica. Più velocemente ricevono feedback di prova e più breve è il ciclo, più sono produttivi. Quindi, vogliamo solo eseguire test importanti che si completino rapidamente. La suite di test completa verrebbe eseguita solo come parte di un processo di controllo qualità, ad es. su un server CI.
Ciò significa che le suite di test di grandi dimensioni dovrebbero essere categorizzate. Possiamo selezionare solo unit test per un particolare componente? Possiamo escludere i test lenti? Un modo semplice per farlo è quello di mantenere diverse suite di test in diverse directory. Se hai solo pochissimi test, una singola directory sarebbe anche OK se un programmatore può facilmente selezionare un sottoinsieme di test.
Qualsiasi cosa permetta a un programmatore di ottenere un feedback velocemente è buona. La suite di test più completa non ha importanza se non viene eseguita regolarmente.
Ulteriori letture:
Leggi altre domande sui tag unit-testing integration-tests architecture