Chi fa lo sviluppo test-driven?

Ho lavorato nello spazio aziendale negli ultimi 4 anni e mezzo e ho notato che in generale, le imprese non sono ambienti favorevoli per lo stile di sviluppo test-first. I progetti sono generalmente a costo fisso, a linea fissa e stile a cascata. Qualsiasi test unitario, se eseguito, di solito viene dopo lo sviluppo nella fase di controllo qualità e fatto da un altro team.

Prima di lavorare per un'impresa, ho consultato molte piccole e medie imprese, e nessuna di loro era disposta a pagare per un progetto di sviluppo test-first-style. Di solito volevano che lo sviluppo iniziasse immediatamente, o dopo un breve periodo di progettazione: cioè qualcosa di più simile ad Agile, anche se alcuni clienti volevano che tutto fosse mappato in modo simile a cascata.

Con quali tipi di negozi, aziende e clienti funziona meglio lo sviluppo guidato dai test? Quali tipi di progetti tendono a favorire la TDD?

Ogni riga di codice che scrivo utilizza lo sviluppo test driven. Se la direzione non è a bordo con i test di scrittura prima, non lo dico alla direzione. Ritengo che lo sviluppo guidato dai test sia un processo migliore.

Il mio capo mi ha dato da mangiare oggi, penso che lo ruberò come se lo stesse rubando a qualcun altro.

"Ti aspetteresti che un falegname misuri la tavola prima di tagliarla?"

Ho frequentato le lezioni di falegnameria al liceo e ho lavorato alla costruzione durante la scuola. Il nostro mantra era sempre "misura due volte, taglia una volta", seguito dal sarcastico "l'ho tagliato e tagliato di nuovo ed era ancora troppo corto!"

Se esegui il test dopo, crei rielaborazioni poiché il codice che avrai scritto sarà difficile da testare. Quando esegui il test per primo, o addirittura testerai un po 'nel mezzo ma prima di eseguire il commit, il software che creerai sarà più facile da testare. Un'azienda che crea test unitari dopo aver scritto il codice di produzione per soddisfare una lista di controllo sta sprecando sforzi.

L'integrazione con i software già difficili da testare creerà ulteriore sforzo, poiché sarà necessario creare cuciture di prova per essere in grado di controllare le dipendenze consumate dal nuovo brillante codice guidato dai test. In alcuni casi, come nel caso di strutture che fanno un uso pesante dello stato globale e degli oggetti divini, questo può essere molto difficile da raggiungere. La difficoltà percepita dello sviluppo guidato dai test dipende spesso da una combinazione di inesperienza con la scrittura di buoni test e il tentativo di testare codice strettamente accoppiato.

Puoi testare il codice di guida anche in un progetto a cascata, è una disciplina ingegneristica e non una tecnica di gestione del progetto.

Non sono affatto un fanatico di TDD, ma ti insegna molto sulla progettazione del software.

Abbi pazienza con me, poiché avrà un sapore decisamente netto: p

Per quanto riguarda i tipi di progetti suscettibili dell'approccio test-first, alcune cose che vorrei cercare:

• hai a che fare con una base di codice esistente? Spesso è proibitivamente costoso retrofit di una suite di test. Farsi un'idea di quanto sia presente il debito tecnico ereditato
• alcune piattaforme e framework sono intrinsecamente ostili al test. Esperienza recente che mi viene in mente: SharePoint, ad esempio, è molto difficile (ma non impossibile) per TDD. Per cose come questa, potresti dover ricorrere a un prodotto isolatore commerciale come TypeMock può aiutarti.
• alcuni approcci di implementazione si prestano meglio a TDD di altri. Ad esempio, ASP.Net con code-behind - non così verificabile. ASP.Net MVC - testabile. Silverlight con code-behind - non così testabile. Silverlight con MVVM - testabile.

Alla fine, mentre "l'organizzazione" può fare molto per supportare il passaggio al test-first, il cambiamento chiave che deve avvenire è nelle menti degli sviluppatori. Ho rinunciato all'approccio "devi prima scrivere i tuoi test" e invece cerco momenti concreti.

+1 sul commento di mpenrow sul non dire a mgmt se hanno un problema con esso: p

La tua situazione non cambierà rapidamente e la chiave per farcela è renderla parte della tua disciplina personale, ed essere brava a farlo, prima di provare a spingerla sugli altri. Se puoi essere l'esempio del suo funzionamento, i tuoi manager dovrebbero vedere benefici oggettivi.

Puoi anche fare buoni casi aziendali:

• TDD può essere semplicemente riassunto come "specifica su cui il sistema può verificare automaticamente se stesso". Non sta programmando diversamente, non sta costruendo un prodotto diverso.

• Il test unitario è in realtà solo una forma di test automatico; che sta semplicemente lasciando che il computer faccia da sé ciò che la società sta probabilmente pagando agli ingegneri dello spazio carne per fare manualmente. I test automatizzati vengono eseguiti più rapidamente, in modo più coerente e, se ben scritti, forniscono feedback, descrizioni e indicazioni rapidi, concisi e accurati per la risoluzione del problema

• TDD, quando viene fatto da qualcuno che sa cosa stanno facendo, produce risultati altrettanto velocemente del codice. Ci sarà una curva di apprendimento / formazione (e, se i tuoi ingegneri provengono dalla fascia più bassa del pool di talenti, questo potrebbe uccidere del tutto le tue possibilità di spingere TDD - in questo caso il meglio che puoi fare è continuare a difenderlo e la gestione fanno domanda di loro , piuttosto che TDD)

• Il TDD riguarda moltissimo il compito da svolgere prima di iniziare. È sulla falsariga di "misura due volte, taglia una volta" - la misura aggiuntiva aggiunge una quantità marginale di tempo all'attività, ma evita di buttare via la tua risorsa più preziosa - ore di sviluppo).

... e ricorda; la cosa più importante che puoi fare è dare l'esempio. Se sei duro con il TDD, investi qualche ora in più per diventare meglio. Una volta che sei competente, inizia a farlo sul posto di lavoro (i tuoi manager si lamenterebbero davvero di aver scritto dei test?). Combatti una battaglia alla volta e fai dei passi verso di essa: andare avanti per l'intero shebang probabilmente comporterà un fallimento e la colpa cadrà su di te se spingi forte per questo.

Lo voglio. È il mio modo di sviluppo preferito e lavoro per una grande società finanziaria che è felice per me di lavorare nel modo in cui lo ritengo opportuno fintanto che rispetto le scadenze e produco un codice di qualità. Effettuato correttamente, testare il primo sviluppo non deve richiedere più tempo del test dopo lo sviluppo e non dimentichiamoci degli altri vantaggi del primo sviluppo del test di meno difetti dai test di sistema in seguito.

La chiave per fare TDD è semplicemente farlo come parte della scrittura del codice e, se necessario, non dire a nessuno che lo stai facendo. Non è necessario spiegare tutto quello che stai facendo. Il risultato finale è un codice funzionante.

Se spieghi "Sto scrivendo dei test", allora The Powers That Be può dire "Oh, possiamo eliminarlo!" Ma se non lo dici a nessuno, allora hai ancora i test come residuo del processo di codifica.

La programmazione è più che digitare le dichiarazioni di lavoro in un editor. Se le persone non riescono a gestirlo, allora proteggili da questa verità fino a quando non sono pronti a gestirlo. "Pronto a gestirlo" in questo caso significa che quando hai un progetto completato o due, fatto in tempo con un codice solido e affidabile, e oh sì, guarda, hai anche dei test unitari.

Triste a dirsi, non ho avuto la possibilità di usarlo nel vero senso del test in prima persona, quindi non posso dire "io! Io! Lo faccio!". Suppongo che la domanda sia "quali settori / aziende usano TDD su tutta la linea" piuttosto che "qualcuno può intrufolarsi nella loro vita quotidiana?". Concordo sul fatto che un singolo sviluppatore può fare TDD totalmente senza forzare l'intero gruppo a farlo, ma non penso che questo fosse il punto della domanda.

La mia impressione ascoltando il settore è che è più probabile che tu veda TDD nella maggior parte dei gruppi di sviluppo in un'azienda in situazioni in cui:

• Non esiste una base di codice esistente di grandi dimensioni prima dell'inizio del TDD

• La società non è enorme e quindi non ha molto del pushback "l'abbiamo sempre fatto diversamente".

• La società non ha un enorme riscontro nel processo formalizzato. Questo non vuol dire che non è possibile implementare TDD, ad esempio, in un'azienda certificata CMMI, ma se si dispone di un processo non TDD, ottenere tutti i processi monitorati con CMMI aggiornati può essere un investimento importante.

• I test possono essere sottoposti a script: si tratta di basi di codice più complesse, poiché anche se non è possibile eseguire facilmente lo script del livello più vicino all'utente, è possibile eseguire lo script di alcuni interni. Ma vedo situazioni con opzioni ben sviluppate per l'automazione dei test come i punti più dolci per TDD, dal momento che si basa sul rieseguire e non interrompere un'intera batteria di test in cui è necessario un feedback sui test molto rapidamente. Il mio pensiero è che un'app Web autonoma sia un buon obiettivo TDD, un sistema con una maggiore integrazione o input COTS che non è basato sulla GUI potrebbe essere complicato.

• Sistemi in uno stato non prototipato. Idealmente, la prossima grande versione dopo il prototipo - dove la dimostrazione del concetto è terminata e il progetto è finanziato, ma tutti sanno che il prossimo tentativo deve saltare in termini di qualità.

• Stakeholder che sono investiti nel processo.

Ho provato dove possibile, ma penso che dipenda davvero dall'ambiente aziendale in cui ti trovi. Ho lavorato nel settore dei giochi per molti anni (come artista tra l'altro), e non c'era il concetto di TDD - solo un approccio di QA a forza bruta. Sono passato allo sviluppo web e non ho ancora lavorato in un'agenzia con alcun riconoscimento formale (o conoscenza di ...) test unitari / TDD. Lo stesso vale per la maggior parte dei miei colleghi del settore, che lavorano in una vasta gamma di discipline.

In un'agenzia focalizzata sulle vendite, TDD offre pochissimo ROI a breve termine per il cliente, quindi è difficile vendere ai manager di linea quando si scopre un progetto. Più un progetto diventa grande, più diventa convincente.

Dato che libri come Death March indicano un fenomeno prevalente, ovvero un'industria afflitta da uno sviluppo guidato dalla "crisi" e dalla "pietra miliare" - scommetto che il TDD è probabilmente raro al di fuori di startup ben finanziate o negozi monolitici di imprese. Non è che le persone lì non credano nel valore del TDD, ma è troppo astratto per venderlo ai propri clienti.

Sto cercando di entrare nel TDD da solo. Penso che se segui percorsi che già conosci (il lavoro quotidiano) è piuttosto semplice. Ma non riesco proprio ad avvolgere la mia testa intorno ai test per le parti dell'interfaccia utente o quando devi trovare una nuova soluzione a qualche problema che non hai mai incontrato prima. O usando un framework che non conosci.

Quindi suppongo che tu debba fare una sorta di LearningTest, prove di concetti separate e riscriverle in seguito, ecc. O sbaglio?

E (so che è vecchio ma non ho ancora visto una buona risposta): come si codificano gli algoritmi usando TDD (quando i risultati potrebbero essere troppo complessi da "Asserire" davvero con facilità)?

Posso davvero vedere i lati positivi di TDD e im sulla barca, ma è molto difficile per i principianti quando il codice che scrivi ti porta quasi il doppio del tempo (e hai colleghi che non vedono affatto i professionisti e ti deridono con RAD)

Ho provato alcune volte e ha funzionato alla grande. Sfortunatamente la maggior parte delle volte, se riesco a testare manualmente la mia app, rimando i test unitari fino a quando non mi sento troppo annoiato per implementare qualcos'altro o non c'è un bug che non riesco a risolvere facilmente.

Lo faccio. L'avanzamento delle storie dei nostri utenti è tracciato su una scheda Kanban, che ha un "Hai un test?" colonna a sinistra (a monte) dello sviluppo.

Questo layout in qualche modo insolito rende esplicito un criterio: deve esistere un test di accettazione automatica non riuscito (di solito, alcuni di essi). Deve essere tracciabile in base alle esigenze del cliente. I test di accettazione derivano da condizioni di soddisfazione , che risultano da conversazioni che iniziano con una trama . Facilito seminari regolari in cui analizziamo i requisiti, identifichiamo le lacune e capisco i test di accettazione chiave che assicurano che il valore dell'utente venga consegnato quando passa (la definizione di done ). È un'attività collaborativa che coinvolge programmatori, analisti aziendali e talvolta tester.

Il ciclo di feedback dei test di accettazione è piuttosto lungo: potrebbero essere necessari diversi giorni per completare la storia. Lo sviluppo ha i propri loop di feedback TDD più brevi.

"[... no test-first style ...] Più simile a Agile ...."

Questa è una completa dichiarazione falsa di Agile. La definizione di done è un componente chiave di Agile e uno dei pilastri su cui si basa è il test di accettazione automatizzato (quello che ho descritto sopra è un modo per farlo.) Se la programmazione estrema (XP) viene utilizzata come metodo di implementazione Agile, allora Sono prescritti ATDD / BDD e TDD.

Lo faccio, ma generalmente solo per componenti diversi dall'interfaccia utente, e quando so che non riesco a tenere l'intero algoritmo per un modulo nella mia testa in una sola volta, o quando il modulo è una nuova parte di qualsiasi sistema su cui sto lavorando, quindi non posso fare affidamento sulla maggior parte delle librerie che sto usando per avere il debug altamente.

In sostanza, lo faccio quando la complessità del requisito significa che altrimenti potrei perdersi nel codice.

È un'abitudine difficile da iniziare e richiede un buy-in da parte della direzione, ma quando i test iniziano a superare lo sviluppo, può essere un salvavita!

Volevo fare proprio questa domanda, per vedere quante aziende praticavano effettivamente il TDD.

Negli 11 anni che ho programmato professionalmente solo le ultime due organizzazioni erano persino a conoscenza del TDD (che copre quasi 5 anni di mente, prima che TDD non fosse così popolare come lo è oggi). Prenderò la caccia e risponderò alla tua domanda prima di divagare nel mio campo di vendita per TDD :)

Nell'ultima società per cui ho lavorato (editore accademico online di scienze umanistiche e collezioni scientifiche), sapevamo che dovevamo praticare TDD ma non ci siamo mai arrivati. A nostra difesa avevamo una base di codice di 250k, quindi l'aggiunta di test a una base di codice non verificabile di quelle dimensioni sembrava insormontabile (mi sento colpevole digitarlo ora!). Anche il migliore di noi commette errori .

Chiunque abbia fatto anche una piccola quantità di TDD sa quanto possano essere dolorosi i test di retrofitting sul codice non testabile del campo bruno ... Le cause principali sono dipendenze implicite (non è possibile estrarre tutte le leve per affermare i risultati dal codice - non si può prendere in giro scenari) e violazione del principio della singola responsabilità (i test sono complicati, inventati, richiedono troppe impostazioni e sono difficili da capire ).

Abbiamo temporaneamente aumentato il nostro team di controllo qualità (da una, forse due persone a una mezza dozzina o più) per testare la piattaforma prima di qualsiasi rilascio. È stato un tempo enormemente costoso dal punto di vista economico e finanziario, alcune pubblicazioni avrebbero richiesto tre mesi per completare i "test". Anche allora sapevamo di essere spediti con problemi, non erano semplicemente "bloccanti" o "critici", solo "prioritari".

Se hai un'esperienza commerciale di anni, apprezzerai che ogni azienda afferma attività critiche e quindi inventa un livello di priorità più elevato sopra quello, e molto probabilmente anche uno sopra quello, specialmente quando qualcuno dall'alto sta spingendo una funzionalità / correzione di bug. Io divago ...

Sono felice di riferire che sto praticando TDD nella mia attuale azienda (telecomunicazioni, web e casa di sviluppo di app mobili), insieme a Jenkins CI per fornire altri rapporti di analisi statica (la copertura del codice è la più utile dopo aver affermato i passaggi della suite di test) . I progetti su cui ho utilizzato TDD sono un sistema di pagamento e un sistema di grid computing.

Il passo delle vendite ...

Spesso può essere una lotta in salita che giustifica test automatici per i membri del team non tecnici. Scrivere test aggiunge più lavoro al processo di sviluppo ma ... il tempo che investi nei test ora, risparmierai negli sforzi di manutenzione in seguito. Stai davvero solo prendendo in prestito tempo . Più a lungo il prodotto è in uso, maggiore sarà il tuo risparmio e ti aiuterà a evitare la grande riscrittura .

Test prima significa che stai prima codificando il tuo intento, quindi confermando che il tuo codice soddisfa tale intento. Ciò fornisce attenzione e distilla il tuo codice per fare solo ciò che è destinato e non di più (leggi senza gonfiare). È una specifica eseguibile e documentazione allo stesso tempo (se il tuo test è ben scritto, e i test dovrebbero essere leggibili / puliti come il tuo codice di sistema, se non di più!).

I non programmatori (spesso) non avranno questa intuizione e quindi TDD non ha molto valore per loro, e viene visto come scorciatoia usa e getta per una data di rilascio precedente.

La programmazione è il nostro dominio e, nella mia mente, ciò rende nostra responsabilità , come professionisti, consigliare le migliori pratiche come TDD. Non per i project manager decidere se è stato fatto per ridurre i tempi di sviluppo, è fuori dalla loro giurisdizione . Allo stesso modo non ti dicono quale framework, soluzione di memorizzazione nella cache o algoritmo di ricerca utilizzare, non dovrebbero dirti se dovresti utilizzare test automatici.

A mio avviso, l'industria dello sviluppo del software (nel complesso) è attualmente rotta, il fatto che avere test per il tuo software NON sia la norma.

Immagina questo in altri settori: medico, aeronautico, automobilistico, cosmetico, peluche, bevande alcoliche ecc. Ho chiesto alla mia fidanzata di nominare un settore in cui non testano il prodotto e lei non poteva!

Forse non è giusto affermare che non si verificano test perché lo fa ... ma nelle aziende senza test automatizzati, è un processo molto manuale / umano (leggi ingombrante e spesso soggetto a errori).

Un punto che contenderei nella tua domanda ...

Di solito volevano che lo sviluppo iniziasse immediatamente o dopo un breve periodo di progettazione. Più simile a Agile.

Essendo "Agile" non prescrive di procedere senza test, il primo membro elencato su agilemanifesto.org è Kent Beck , il creatore di XP e TDD!

Due libri che consiglio vivamente se sei interessato a TDD, o semplicemente non li hai letti e sei un appassionato programmatore (tutti leggono bene?;)

Software orientato agli oggetti in crescita guidato da test

Codice pulito - Serie Robert C Martin ("Zio Bob")

Questi due libri si completano a vicenda e condensano molto senso in poche pagine.

Grazie per aver posto questa domanda :)

Coloro che implementano i cloni. Non riesco a pensare a un processo migliore quando devi sviluppare qualcosa, che funziona esattamente come un programma esistente.

Ovviamente questo è un caso abbastanza insolito, ma gli sviluppatori di SQLite usano ampiamente i test. (Suppongo che il loro processo di sviluppo sia test-first, anche se non ne sono sicuro.)

• 73.000 righe di codice
• 91.378.600 righe di codice di prova

Vedi http://www.sqlite.org/testing.html