Un test ha generato un codice?

Non c'è una risposta diretta a questo. C'è il codice generato, e poi c'è il codice generato. Potremmo parlare di un po 'di codice framework, di inizializzazioni per qualcosa che hai trascinato insieme in un designer, o di una conversione automatica di un'applicazione completa da una lingua / piattaforma a un'altra lingua / piattaforma. In quest'ultimo caso vorrai testare per trovare qualsiasi cambiamento nel comportamento, perché sì, ci sarebbe un comportamento coinvolto.

La generazione del codice ha molte applicazioni. I test possono essere appropriati e necessari o potrebbero essere inutili.

No, non dovresti testare il codice generato. E tu davvero non dovresti testare POJO - non ci sono comportamenti da testare.

Ma dovresti probabilmente testare la generazione del codice per assicurarti che faccia le cose giuste, maneggi i casi d'angolo, gestisca i cattivi dati, ecc. Se lo strumento codegen non è tuo e i tuoi input sono semplici, allora forse alcuni controlli a campione o test manuali sono sufficienti.

E poiché probabilmente stai creando POJO per mappare su un'altra interfaccia, dovresti probabilmente fare test di integrazione (eventualmente manuali) per assicurarti che la tua serializzazione o altra motivazione per avere i POJO sia soddisfatta dalle cose che hai creato.

Forse è un po 'di pedanteria, ma se ti concentri solo sull'output dello strumento potresti fare dei bad test che asseriscono solo che l'output è ciò che ti aspetti , non ciò che necessità .

Il test di ciò che hai fatto è sempre buono, ma dovresti verificare che il tuo input per il generatore abbia senso, non che il risultato della generazione sia corretto. I test unitari generati possono fare solo il primo, quindi non ha senso. Integrazione o migliori test unitari "socievoli" sono una soluzione molto migliore.

La ragione per usare la generazione del codice o un framework è l'astrazione: si vuole evitare di scrivere codice di tipo standard come schemi di database o codice di serializzazione ed esprimere la propria progettazione dell'applicazione su un livello superiore. (Pensa a linguaggi specifici di dominio, in cui non desideri affatto toccare l'effettivo linguaggio di programmazione, ma rimani solo a livello di dominio.)

Il test non dovrebbe interrompere questa astrazione cercando di "guardare dentro" i componenti. Se la tua astrazione è solida e completa, dovrebbe esserci un modo per esprimere l'aspettativa che hai sullo stesso livello. Se no, la tua astrazione potrebbe essere rotta.

Ad esempio, eseguendo una mappatura del database si desidera astrarre dalla persistenza. Quindi, allegare un database in memoria o un database falso ed eseguire tutti i test delle unità contro di esso è perfettamente corretto. Sebbene questa non sia l'interpretazione più comune dei test unitari, (Martin Fowler li chiama test unitari "socievoli" ) il il vantaggio è che il codice generato o il codice di framework viene eseguito ogni volta che esegui il test.

Ovviamente questo può essere fatto anche a livello di test di integrazione, ma per cose come la persistenza questo richiederebbe troppi test ad un livello ancora più alto.

Hai bisogno di testare il POJO?
Probabilmente no.

Devi testare output dal programma Generator?
Assolutamente si!

Che il Programma Generatore produca altro codice per il quale è possibile o meno scegliere di scrivere test è irrilevante. Se qualcuno cambia il Programma Generatore, devi essere sicuro che ciò che esce non rompi nulla.