Dovresti esercitare TDD su applicazioni prototipo?

La risposta "corretta" è sì. Il TDD dovrebbe essere considerato "migliore pratica" ovunque siano disponibili gli strumenti per TDD nella lingua o nel quadro. Anche se non sono disponibili in un modulo a cui potresti essere abituato con Java o .NET, puoi creare un semplice programma che consiste nel chiamare ciascuno dei metodi di test unitari uno alla volta, rilevando eccezioni generate (che indicano un test fallimento).

Il motivo per cui queste piccole e poco costose app di prototipazione in-house, costruite come proof-of-concept o per scopi di formazione / demo / uso personale, diventano applicazioni di produzione sempre . A titolo di esempio, a un certo punto ho avuto il dovere di creare dischi flash avviabili per i nostri tecnici di campo, contenenti strumenti di sistema e immagini del sistema operativo. Dopo averlo fatto manualmente la prima volta per un batch di 50, ho creato una semplice app, ThumbPrinter (essendo intelligente), che automatizzava gran parte dello script, in esecuzione e batch-tracking, e tutto quello che dovevo fare era dirgli come molte chiavette USB che volevo creare, dove erano i dati da inserire e quali lettere di unità sarebbero state usate durante il batch, e quindi gestire il collegamento e la disconnessione delle unità flash mentre procedevano.

Quella app è ora utilizzata da altri nel mio dipartimento e sono costantemente chiamata a "sistemare" cose che non sono mai state un problema quando ho usato il programma da solo, perché a differenza di un ambiente di produzione, I sapeva come lo userei e non ho mai pensato di usarlo in un modo diverso, e ho anche saputo le cause di alcuni problemi tecnici e come evitarli perché era più facile che far funzionare il codice destra. Se avessi saputo che l'app sarebbe stata utilizzata da chiunque altro, probabilmente mi sarei preoccupato di crearla, fino a includere TDDing.

Ora, detto questo, TDD non è necessariamente il fine - tutto - tutto del corretto sviluppo del software. Siamo andati avanti per più di tre decenni prima che venisse proposto, e le persone scrivono ancora codice corretto senza test unitari. Quindi, dipende solo da te; dovrai scoprire quanto sia facile o meno scrivere ed eseguire i test unitari per un'app per iOS, e se il costo di tempo e fatica valga i vantaggi di TDD (prevenzione della regressione, aderenza allo YAGNI, definizione di "fatto" e prova automatica di correttezza).

Kent Beck direbbe di no , ma sulla base di altre cose che ha scritto direi che il caveat  c'è che devi gettare via quel codice. Se non sei la persona che decide cosa fare con il tuo codice, allora dovresti probabilmente scrivere i test sempre.

L'ambito di un prototipo deve toccare alcune caratteristiche chiave che sono implementate in modo corretto. Visto che dimostrerai il prototipo, avere queste funzioni ben testate mi sembra una buona idea.

Ma la preoccupazione principale è se credi che TDD acceleri effettivamente il tuo sviluppo. È mia opinione che avere una frequenza del ciclo di sviluppo elevato guidata da TDD acceleri ogni progetto, indipendentemente dalle dimensioni o dal campo di applicazione. Forse i progetti con un ambito limitato ne trarranno effettivamente di più, dal momento che è più facile scrivere test per loro.

Se usi TDD, allora sì, dovresti usarlo anche per i prototipi. Ci sono un paio di motivi per questo:

Prima di tutto, testare piccoli bit del codice rende più facile (come sempre) ottenere il tutto giusto. Quando stai imparando la lingua, è più probabile che tu commetta errori pazzeschi e aiuta a lavorare con pezzi di codice più piccoli.

Secondo, i prototipi hanno un modo di trasformarsi in app di produzione come non crederesti. Sarà molto più facile farlo se hai già un corpo di codice di prova.

Gli svantaggi sono che non devi solo capire come scrivere un'app per iOS, devi anche capire come scrivere il codice di test per un'app per iOS, che è due problemi invece di uno solo. Ma ricorda che avere tutti questi test sarà un vantaggio lungo la linea quando ti verrà chiesto di trasformare la cosa in un vero affare sul doppio rapido.