2009-03-12 17 views
5

Ho usato nosetests per gli ultimi mesi per eseguire i miei test di unità Python.C'è una gui per nosetests

Fa sicuramente il lavoro ma non è bello per dare una visione visiva di ciò che i test stanno funzionando o rompendo.

Ho utilizzato diversi altri framework di test unità basati su GUI che forniscono un colpo istantaneo visivo dello stato dei test unitari e forniscono funzionalità di drill down per ottenere messaggi di errore dettagliati.

I nosetest scaricano la maggior parte delle informazioni sulla console, lasciando che lo sviluppatore setacci i dettagli.

Qualche consiglio?

risposta

2

Ho usato Trac + Bitten per l'integrazione continua, era una configurazione abbastanza complessa e richiedeva una notevole quantità di tempo per RTFM, impostare e quindi mantenere tutto ma potevo ottenere dei report visivi con test e messaggi di errore non riusciti e grafici per test falliti, problemi di limitazione e copertura del codice nel tempo.

Bitten è un plug-in di integrazione continua per Trac. Ha l'architettura master-slave. Il master morso è integrato e viene eseguito insieme a Trac. Lo slave morso può essere eseguito su qualsiasi sistema che comunichi con il master. Effettua regolarmente il polling del master per le attività di compilazione. Se c'è un'attività in attesa (qualcuno ha recentemente eseguito qualcosa), il master invierà "build recipe" simile a form's build.xml in slave, slave seguirà la ricetta e invierà i risultati. La ricetta può contenere istruzioni come "check out code from that repository", "execute this shell script", "run nosetests in this directory". I rapporti di compilazione e le statistiche vengono quindi visualizzati in Trac.

4

È possibile utilizzare il plug-in rednose per colorare la console. Il feedback visivo è molto meglio con esso.

0

So che questa domanda è stato chiesto 3 anni fa, ma sto attualmente sviluppando una GUI per rendere nosetests un po 'più facile lavorare con un progetto in cui sono coinvolto.

Il nostro progetto utilizza PyQt che ha reso è davvero semplice iniziare con questa GUI in quanto fornisce tutto il necessario per creare interfacce. Non ho lavorato a lungo con Python ma è abbastanza facile da gestire, quindi se sai cosa stai facendo sarà perfetto se avrai tempo.

È possibile convertire i file .ui creati nel Designer PyQt per script python con:

pyuic4 -x interface.ui -o interface.py

E si può ottenere qualche buon tutorial per avere un'idea di PyQt here. Spero che sia di aiuto a qualcuno :)

0

Mi piace aprire un secondo terminale, accanto al mio editor, in cui eseguo solo un ciclo che esegue nuovamente nosetests (o qualsiasi comando di test, ad esempio semplici vecchi unittests) ogni volta che un file i cambiamenti. Quindi puoi mantenere l'attenzione nella finestra dell'editor, mentre vedi l'output di test aggiornato ogni volta che premi "salva" nel tuo editor.

Non sono sicuro di cosa significhi OP con 'drill down', ma personalmente tutto ciò di cui ho bisogno dall'output di test è il traceback di errore, che ovviamente viene visualizzato ogni volta che un test fallisce.

Ciò è particolarmente efficace quando il codice e i test sono ben scritti, in modo che la maggior parte dei test richieda solo millisecondi.Potrei eseguire questi veloci test unitari in un ciclo come descritto sopra mentre eseguo il montaggio o il debug, quindi eseguo manualmente i test più lunghi alla fine, appena prima di eseguire il commit.

è possibile ri test eseguiti manualmente con 'orologio' Bash (ma questo solo loro ogni X secondi viene eseguito. Il che va bene, ma non è abbastanza scattante per mantenere me felice.)

In alternativa ho scritto un rapido pacchetto python 'rerun', che esegue il polling delle modifiche al filesystem e quindi ripete il comando che gli viene dato. Il polling per le modifiche non è l'ideale, ma è stato facile da scrivere, è completamente multipiattaforma, è abbastanza scattante se lo comunichi per interrogare ogni 0,25 secondi, non mi provoca alcun ritardo evidente o carico di sistema anche con progetti di grandi dimensioni (ad esempio Python albero dei sorgenti), e funziona anche in casi complicati (vedi sotto.) https://pypi.python.org/pypi/rerun/

una terza alternativa è quella di utilizzare un più generico 'aspettare cambiamenti filesystem' programma come 'cane da guardia', ma questo sembrava pesi massimi per le mie esigenze, e soluzioni come questa che ascoltano gli eventi del filesystem a volte non funzionano come mi aspettavo (per esempio se Vim salva un file salvando un tmp da qualche altra parte e poi spostandolo in posizione, gli eventi che accadono qualche volta non sono quelli che ti aspetti.) Quindi 'rerun'.