Come previene i test confusi? [duplicare]

Il test del codice per la correttezza è importante. Sia che facciate rigoroso TDD o no, i test sono davvero l'unico modo in cui un progetto può scalare le dimensioni oltre un punto in cui ogni membro del team può ragionevolmente mantenere tutte le conoscenze del codice caricate nel loro cervello in una sola volta. Dopo questo punto, i test sono indispensabili per garantire che le future modifiche non interrompano la vecchia logica (o se stai bruciando molte risorse facendo la stessa cosa manualmente).

La maggior parte delle persone capisce cosa ho detto sopra - non c'è molto da discutere con lì. Tuttavia, senza molto di un background di CS, c'è molto spazio per l'interpretazione. Ingenitamente, test probabilmente significhino semplicemente codice che esegue un altro codice . Mentre questo è vero, non dipinge l'intera immagine. Senza molta preoccupazione per i test corretti, nella mia esperienza, le persone tenderanno a generare un gruppo di integration o functional test quando viene richiesto di scrivere test unit .

Se non sei al corrente di testare le sfumature o se semplicemente scegli di ignorarle (nell'interesse del tempo o perché non ti piacciono i test), il risultato è lo stesso. Si ottiene un progetto con una serie di "test confusi" o test che non rispettano realmente la linea tra unità, funzionale e stili di test di integrazione. In altre parole, si ottengono test che non hanno uno scopo chiaro diverso da quello di esercitare il maggior numero possibile di codice. Questo è frustrante perché diventa sempre più complicato analizzare i risultati di tali test per informazioni significative.

• I test sono falliti perché il mio server remoto non funziona, o la mia logica è errata?
• Perché questo test "unità" fallisce quando scambio [un] componente di sistema relativo x per componente y ?

E così via. Come puoi illustrare questa distinzione in un modo in cui qualcuno con una mentalità più ingegneristica / preparata può identificarsi con? In sostanza, come fai a prendersi cura delle persone riguardo alla distinzione?

In effetti, in occasione di un recente meeting di test su Android su Twitter, il team ha affermato che il testing completo del software è un progetto a sé stante. E i progetti richiedono risorse. Non puoi semplicemente passare i test dal lato e non pensare molto a questo. Le risorse devono essere allocate e gli sviluppatori devono prenderle seriamente .

È un buon inizio, ma non possiamo semplicemente gettare risorse e attenzione retrospettive al codice che è già stato scritto. Sono curioso, quali approcci funzionano per rimediare a un panorama di test confuso e come puoi evitare che i test confusi si verifichino in primo luogo?