Dato: voglio praticare un corretto sviluppo del software in stile test-first e continuo nello spazio comune Lisp.
Problema: come ogni iterazione red-green-refactor del processo dovrebbe apparire come? Come posso distribuire? Come faccio a test dopo la distribuzione?
TDD di Example e libri di GOOS sono stati scritti assumendo l'uso delle lingue, il cui codice sorgente è compilato in binari nativi del sistema operativo, e quei binari sono veloci da avviare e nel complesso sono destinati ad iniziare , lavoro e muori. È molto costoso avviare il Common Lisp core, caricare tutti i sistemi del programma su di esso, quindi chiamare la funzione del punto di ingresso solo per verificare l'asserzione su una singola unità di logica. O non capisco qualcosa.
Inoltre, è molto allettante usare la funzionalità REPL in qualche modo, ma si presume che parli sempre dello stesso core, in cui cambio costantemente i binding del simbolo. È molto facile contaminare il core con alcune definizioni di garbage da esecuzioni di test non riuscite e quindi iniziare a testare lo stato errato dell'applicazione, che si noterà solo al successivo ricaricamento completo del core.
In che modo REPL può aiutarmi nella fase di refactoring? Ad esempio, ho una connessione REPL a un core caricato e tutti i test passano. Il refactoring che devo fare è un pacchetto rinomina . Quanto sono fregato (cioè, è necessario ricaricare un core e riavviare REPL)?
Esiste una pratica consolidata?
Sto parlando dello sviluppo di software di medie e grandi dimensioni, contati in centinaia di righe di codice. In nessun modo sarà un singolo file, forse nemmeno un singolo sistema ASDF.
UPDATE : ho letto come si presenta il tuo flusso di lavoro Lisp? e la mia domanda forse sembra quella, ma il mio intento non è quello di apprendere lo stile personale di qualcuno, ma una pratica consolidata, promossa dalla comunità. E voglio evitare due problemi che vedo negli approcci presentati nelle risposte a questa domanda:
- Se principalmente progetto i miei prototipi di funzioni in REPL e li eseguo costantemente su alcuni dati di test per verificare la correttezza, allora è essenzialmente lo sviluppo del test-ultimo con test transitori, perché non sono scritti da nessuna parte. Il TDD corretto mi dà le stesse serie sperimentali di codice con il vantaggio dei test cast in pietra: scritto direttamente nel codice sorgente. Penso che questo vantaggio sia cruciale, e il test di copypasting e le definizioni delle funzioni da REPL sembrano essere semplicemente inefficienti.
- Sono abbastanza sicuro che il singolo punto di verità debba essere il codice sorgente, non lo stato di runtime del nucleo Lisp al quale è attualmente collegato il Slime, perché non c'è modo di sincronizzarlo in modo affidabile con il codice sorgente. Quindi, probabilmente il lancio di test nell'attuale connessione REPL ripetutamente senza ricarica completa è un approccio errato. Tuttavia, forse non capisco qualcosa.