Come posso iniziare i test in un'anticultura di test? [chiuso]

Ho una confessione da fare: i test automatizzati formalizzati non hanno mai fatto parte del mio background di programmazione. Ora lavoro in una società molto grande con molti sviluppatori (molti dei quali sviluppatori Web di un tipo o di un altro), ed è evidente che molti di loro non testano *. (* Non continuerò a dire formalmente ; per favore, deducilo.)

Se aspetto di avere il supporto della mia organizzazione per iniziare i test, non accadrà mai. Se provo a "cambiare le cose dall'interno" spingendo i test alla direzione, finirò il vapore prima che avvenga il cambiamento. Devo iniziare i test ora.

Ma con TDD e il suo genere finirò con un sacco di codice di test insieme al codice di produzione. I nostri sistemi di controllo della versione (tutti centralizzati) non sono organizzati per l'archiviazione del codice di test. Dovrò trovare un posto per tutto ciò sulla mia postazione di lavoro.

È possibile iniziare una pratica personale di test del software in una cultura che non valorizza o fornisce gli strumenti per farlo? Quali tecniche e strumenti usi per permetterti di testare quando gli strumenti e l'organizzazione ufficiali non hanno spazio per test, framework e automazioni?

L'ho fatto personalmente con notevole successo. I fattori chiave per il successo:

• Ottieni supporto gestionale (provvisorio). I vantaggi dei test automatici sono ben documentati e dovrebbero convincere qualsiasi manager a provarlo. Ciò include la ricerca di un posto nel VCS e un server di compilazione, perché
• I test automatizzati forniscono il loro pieno valore solo se vengono eseguiti frequentemente e automaticamente in modo da conoscere presto i problemi e non dover fare affidamento su persone che non dimenticano di eseguirli. È necessario un server di build che li esegua almeno quotidianamente. Questa può essere una vecchia workstation. Jenkins richiede pochissimo lavoro per iniziare a correre.
• Dare l'esempio. Scrivi test, parla dei vantaggi che ti stanno offrendo e quando rivelano errori introdotti da altri sviluppatori ne parlano in termini di come sono stati protetti da un potenziale imbarazzo molto maggiore.
• Scegli il frutto a bassa pendenza. Alcune parti dell'applicazione saranno difficili da testare, altre facili. Alcuni saranno robusti, altri fragili. Scrivere test per parti fragili ma facili da testare fornisce il massimo valore nel minor tempo possibile.
• Vedi se riesci a scrivere test riutilizzabili, ad esempio quel test convenzioni o funzionalità che devono avere tutti i moduli (pagine Web, servizi REST, qualunque cosa) ma che spesso vengono dimenticati.

Senza il supporto gestionale sei morto in acqua. La direzione dichiarerà che non stai facendo un lavoro utile, sarai penalizzato nelle tue recensioni e alla fine verrai licenziato. Ci sono modi per portare il management a vedere che i primi test costano meno e tutto il resto. È possibile cambiare la cultura ma stai mettendo il collo sul ceppo.

Suggerirei di leggere il capitolo Machiavelli The Prince su come introdurre il cambiamento prima di fare qualsiasi cosa.

Nella mia esperienza se la cultura è anti-test, non è possibile introdurla ragionevolmente. O i test saranno visti come una perdita di tempo e verrai rimproverato per "perdere tempo" o "impiegare troppo tempo", oppure il codice è peggiorato da anni in cui non è stato scritto in modo testabile (ad es. Nessuna interfaccia, tutto strettamente accoppiati) e dovrai dedicare molto tempo al refactoring e / o alla riscrittura del codice (correndo così il rischio di "impiegare troppo tempo" e "perdere tempo") per renderlo testabile in modo da poter scrivere i test in primo luogo .

Potresti avere una possibilità se stai facendo cose greenfield che devono solo interagire con cose esistenti (creare un bel involucro attorno alle aree cattive) o se puoi farlo in piccole quantità dove non causerà problemi o richiederai di "lavorare su compiti non assegnati a te" che può metterti nella cuccia.

Non credo che andrai molto lontano fino a quando non sarai in grado di dimostrare che esiste un problema (che al momento potrebbe non essere riconosciuto) che i test automatici possono affrontare.

Se esiste una cultura di test manuali rispetto a script definiti, il costo dell'esecuzione di tali script è associato a un rischio di risultati incompleti o imprecisi. Potrebbe esserci una storia (documentata o in forma di "storia di guerra") di questo. Suggerire un progetto pilota per automatizzare alcuni di questi test manuali al fine di offrire un risparmio sui costi a lungo termine.

Se non esiste nemmeno una funzione di test manuale, suggerirei che l'azienda non percepisce che qualsiasi tipo di test formale, automatizzato o meno, ha valore. In tal caso, riterrei che la strada da percorrere sia lunga e ripidamente in salita, ma è probabile che abbia bisogno di una chiara dimostrazione che l'azienda può trarre vantaggio dall'adozione di un approccio meno informale alla qualità del software. Se non riesci a farlo, è difficile capire come potrebbe esserci un supporto per l'idea per motivi commerciali.

Un'idea è che miri a scrivere un test che dimostri che il codice che qualcun altro ha scritto è difettoso. Dovrebbe vendere il concetto.