Qual è il metodo per articolare i compromessi tra i test JUnit simulati a breve termine e i test di integrazione più lenti?

Question

Qual è il metodo per articolare i compromessi tra i test JUnit simulati a breve termine e i test di integrazione più lenti?

#1 da (7 voti)

6

L'assunto è che stiamo lavorando su una base di codice Java legacy di grandi dimensioni, con uno sviluppo continuo attivo.

Ho avuto un membro del team dire:

We should use lots of smaller JUnit tests that are focused on one class - because the fast feedback and ease of maintanence gives us value.

Ho avuto un altro membro del team dire:

We should focus on integrating several classes (and external files) in integration tests, because the bugs happen at the integration points between classes - and this is how we'll deliver business value. This is because the more you mock out, the less value your unit tests will have.

Sto cercando di giudicare questa discussione e ottenere un consenso. Sto cercando un modo per convincere le persone a concordare i compromessi tra i test JUnit più brevi e beffati e test di integrazione leggermente più integrati. Questo è così che possiamo concentrarci su un obiettivo particolare.

La mia domanda è: Qual è il metodo per articolare i compromessi tra i test JUnit simulati a breve termine e i test di integrazione più lenti?

test-coverage junit

posta hawkeye 20.12.2016 - 06:31

fonte

1 risposta

Leggi altre domande sui tag test-coverage junit

Parametrizza i metodi rispetto alle variabili globali La C in ACID non è la C in CAP?

score 7 · Accepted Answer

Ferma, hanno entrambi ragione.

Ogni classe merita test unitari che esercitino ogni riga di codice.

Ogni punto di integrazione merita di essere esercitato in un test di integrazione.

L'unico compromesso è quando li usi. I test di integrazione non ti aiutano a sviluppare il funzionamento interno della classe. Fare test unitari I test unitari non aiutano a configurare le interconnessioni tra i componenti. I test di integrazione fanno.

Che cosa significa? Che se stai eseguendo test di integrazione quando rifatti il funzionamento interno, stai perdendo tempo. Esegui solo i test di integrazione quando devi essere sicuro di essere correttamente integrato. Dì come, prima di fare il check-in a un ramo condiviso da altri. È un modo pratico per essere sicuro di non rompere la build.

I test unitari dovrebbero essere eseguiti molto velocemente. Abbastanza veloce da non pensarci due volte prima di eseguirli ogni volta che lo compili. Hai solo bisogno di eseguire quelli che sono per la classe su cui stai lavorando.

I test di integrazione dovrebbero essere automatizzati. Dovrebbero esercitare più componenti per dimostrare che lavorano insieme. I test di integrazione sono più importanti da eseguire quando sono state apportate modifiche alla configurazione.

Se la tua squadra sta pensando che devono scegliere di sviluppare l'uno o l'altro, semplicemente non capiscono a cosa servono questi tipi di test. Non sono affatto esclusivi. Semplicemente diverso.