No, non ha senso sviluppare un parser. È possibile ottenere le informazioni equivalenti dalle classi nel modulo runner.py.
considerare di estendere entrambe le classi TextTestRunner e TextTestResult con la vostra logica personalizzata (python 2.7). L'output che hai elencato è prodotto da TextTestResult.
In alternativa si può estendere solo TextTestResult e modificare l'attributo class TextTestRunner.resultclass impostandolo al nuovo nome della classe di estensione.
I dati che è possibile estrarre da TextTestResult e inserirli in un elenco di dizionari sono maggiori o equivalenti ai dati che il parser è in grado di estrarre.
La struttura unittest consente tali trucchi grazie al suo design flessibile. Spero che questo sia stato utile.
[EDIT ]
avrei trovato pubblicare i risultati finora (ad esempio come codice open source su GitHub) potenzialmente molto utile per le persone che trovano la tua domanda!
Detto questo, dubito che sarebbe facile migliorare il parser effettivo oltre l'analisi di regexp di base.
Se si desidera continuare l'approccio di analisi del testo, potrebbe essere necessario enumerare e descrivere "tutti i tipi di formato di test dell'unità Python" che si desidera coprire/supportare. Se sei fortunato a inserire una descrizione di questo tipo sotto forma di una grammatica senza contesto, allora potresti essere in grado di sviluppare un parser per questo, che coprirebbe "quei" casi come una forma di linguaggio.
Prendete la mia parola di cautela: se l'analisi del testo non è coperta da semplice regexp'ing e vi è la possibilità che si stia tentando di analizzare un linguaggio irregolare (sensibile al contesto) - molto probabilmente lo trovere estremamente difficile realizzare.
fonte
2011-01-22 01:24:49
Sì, ne vale la pena –
È un lavoro per un test * runner * come 'nose' o' py.test' per fornire un output parseable come il formato XUnit XML. – jfs