È possibile, è solo più noioso e lento (eccetto per i test molto semplici / piccoli, dove il sovraccarico di impostazione e apprendimento e l'uso dello strumento potrebbe essere più alto di farlo tutto a mano - questo non succede spesso eccetto per sistemi banali o quasi banali). Uno sviluppatore intelligente alla fine costruirà i propri strumenti, anche se si tratta solo di un insieme di script shell / batch.
Impossibile? No. Probabilmente doloroso e difficile? Sì.
Puoi utilizzare lo strumento per eseguire i tuoi test e ottenere un feedback visivo istantaneo (rosso / verde) sui tuoi progressi attuali. Se non utilizzi un test runner probabilmente finirai per scrivere script grezzi che eseguono i tuoi test per te e ti danno una sorta di feedback sui tuoi progressi attuali. Qual e il punto? Usa uno strumento (ce ne sono di ottimi gratuiti disponibili e sono facili da imparare).
Bene, sì e no.
Uno dei punti dello sviluppo basato su test è che un sacco di test vengono eseguiti costantemente durante lo sviluppo della funzionalità. Chi e come viene eseguito il test ha un'importanza secondaria.
Tuttavia, qualcuno che deve eseguire il test manualmente ogni volta che cambia qualcosa, diventerà presto noioso, e qualsiasi programmatore degno di questo nome lo automatizzerà, eventualmente creando uno strumento tutto suo (se non più che una serie di script ).
Quindi non devi acquistare o installare uno strumento che faciliti il TDD, ma in pratica significa che dovrai crearne uno da solo.
Sono sicuro che sia possibile, ma perché vorresti farlo? La maggior parte dei framework di testing sono gratuiti e se hai VS2010 puoi utilizzare MSTest.
Assolutamente, lo "strumento" ti dà solo una bella libreria con cui lavorare e una bella interfaccia utente per visualizzare e organizzare i tuoi test, ma una semplice piccola classe potrebbe fare il lavoro o fornire il feedback, e potresti semplicemente scrivere i risultati alla console
Non credo sia impossibile, ma sicuramente non sarebbe molto divertente. Il nostro strumento di scelta è nUnit e l'add-on di Visual Studio TestDriven.NET. Sono entrambi così facili da configurare.
In TDD esprimi i requisiti come test e poi scrivi il codice che supera il test. Gli strumenti sono semplicemente un framework che esegue il codice e controlla il risultato. I principali, basati sulla famiglia xUnit, sono gratuiti e open-source, e molto leggeri.
Non oserei nemmeno dire che sarebbe molto più difficile. Basta scrivere una semplice App Console con le tue classi di test. I tuoi test dovrebbero essere comunque relativamente semplici. L'unica cosa che potrebbe essere un po 'noiosa da implementare da sola è la riflessione necessaria per accedere a campi e metodi privati. Oltre a questo, puoi facilmente scrivere i tuoi metodi di asserzione in un batter d'occhio.
Ciò coprirebbe i test automatizzati, il che rende la metodologia di TDD molto più veloce. l'automazione non è richiesta per TDD, ma va notato che TDD è molto più che semplicemente avere test. Test automatici o qualsiasi altro strumento non lo renderanno mai TDD. TDD ha più a che fare con l'ordine in cui lavori (Red, Green, Refactor). Direi che indipendentemente da come stai facendo qualcosa, se stai scrivendo dei test che iniziano fallendo, allora fai qualcos'altro che li faccia passare (oltre a cambiare i test), quindi ripeti, stanno facendo TDD
i test automatici risparmiano tempo e forniscono una valutazione oggettiva di completezza e correttezza (fino a un certo punto, ovviamente)
manuale "fai-da-te-una-domanda" Test "non solo non risparmia tempo, ma perdere tempo ed essere quasi inutile
Spero di aver frainteso questa domanda, perché sembra incredibilmente ... sbagliata.
Quanto è facile fare TDD senza un framework di test dipende dalla piattaforma. Nella maggior parte dei linguaggi di scripting è incredibilmente facile. Nei linguaggi compilati può essere più difficile, ma non sempre. Nella maggior parte dei casi probabilmente finirai per scrivere il tuo "strumento di prova".
Dire che non si può fare è sciocco dato che possiamo essere certi che TDD sia venuto prima degli strumenti TDD. Gli strumenti facilitano la scrittura dei test. In quanto tale, la costruzione di uno strumento è un processo di raffinazione piuttosto che di creazione originale.
L'esecuzione automatica dei test richiede una sorta di programma che almeno esegue il loop e esegue un comando (es. make build) . Quindi in questo senso forse hai bisogno di uno "strumento". Tuttavia, questo sarebbe utilizzare "strumento" in un senso così ampio da renderlo quasi privo di significato.
Si può dire che sarà più costoso svilupparlo se si sceglie di non utilizzare uno strumento poiché sono creati con l'esplicito scopo di rendere il processo più facile e veloce.