TDD su un progetto già avviato

1

Attualmente sto implementando il mio linguaggio di programmazione. Fino ad ora ho scritto:

  • Una classe Error per errori (da lanciare) incontrati durante l'elaborazione del codice sorgente di input;

  • Alcune funzioni SyntaxError (ognuna con un tag diverso, passate con un modello, come SyntaxError<malformed_number>() o SyntaxError<unexpected_symbol> ) che aiutano a costruire Error oggetti con diversi messaggi di errore (per ora ho ottenuto solo questo, ma presto avrò FunctionError s, IndexError s e così via);

  • Una classe Token che contiene le informazioni su ciascun token (riga nella stringa in cui si trovava quando è stata rilevata, il tipo che può essere string , number ... cose come quella );

  • Infine, una funzione lexer che prende come imput una stringa di codice sorgente e restituisce un oggetto std::list<Token*> . Internamente, utilizza alcune funzioni di supporto ( buildname , builsymbol , skipcomment ...) per aiutare a mantenere il codice organizzato.

Non ho seguito alcuna particolare tecnica di programmazione per codificarlo, ma ora sento l'impulso di seguire quelli che vanno sotto il nome di Programmazione Test Developement.

Ma ho alcune preoccupazioni:

  • Innanzitutto, cosa devo testare nel codice sopra? Ovviamente la funzione lexer dovrebbe essere testata a fondo, e forse anche le funzioni di aiuto che usa (credo), ma che dire delle altre cose?

  • In secondo luogo, come posso testare le funzioni con un output non banale? Online vedo molti esempi che confrontano numeri semplici o stringhe, ma come si scrive un test per una funzione che restituisce un elenco di puntatori agli oggetti senza dover scrivere troppo per un singolo test case?

posta user6245072 26.09.2016 - 15:48
fonte

1 risposta

3

TDD è meno un test ma una tecnica coding . La domanda che devi porre qui non è

"shall I test this class or not"

ma

"I want to implement a small change in my code base, how can I write a test which is red before the change, and becomes green after the change"

Ad esempio, una piccola modifica potrebbe essere l'introduzione di una nuova "parola riservata" nel tuo linguaggio di programmazione. Scrivi un test per il tuo lexer per restituire un token speciale per questo - ma poiché non hai implementato la funzione, il test fallirà. Quindi implementa la funzionalità: il test diventa verde. Successivamente si rifatta il codice, si esegue nuovamente il test, diventa rosso perché si è commesso un errore. Risolvi quell'errore, il test diventa verde. La prossima funzione: usare la nuova parola riservata in un modo specificamente sbagliato deve restituire un'eccezione SyntaxError - scrivi un nuovo test per questo - ... - Immagino che tu abbia avuto l'idea.

Come vedi, non è molto importante applicare TDD se esiste una base di codice esistente o no - TDD tratta di verificare modifiche in una base di codice, non di provare l'intero codice base in ogni modo.

Naturalmente, se un codice base è stato scritto senza "TDD testability" in mente, può diventare difficile scrivere test per determinate modifiche. Quindi, se vuoi davvero passare a TDD, potrebbe essere più facile farlo presto.

    
risposta data 27.09.2016 - 07:45
fonte

Leggi altre domande sui tag