naso vs pytest: quali sono le differenze (soggettive) che dovrebbero farmi scegliere? [chiuso]

Ho iniziato a lavorare su un progetto Python piuttosto grande (multithread), con un sacco di test (unitari). Il problema più importante è che l'esecuzione dell'applicazione richiede un ambiente preimpostato, che viene implementato da un gestore di contesto. Finora abbiamo utilizzato una versione patchata del runner di unit test che eseguiva i test all'interno di questo gestore, ma ciò non consente di cambiare contesto tra diversi moduli di test.

Sia il naso che il pytest supportano una cosa del genere perché supportano i dispositivi a molte granularità, quindi stiamo cercando di passare a nose o pytest. Entrambe queste librerie supportano anche i test di "etichettatura" ed eseguono solo questi sottoinsiemi con tag, cosa che vorremmo fare anche noi.

Ho esaminato un po 'la documentazione di nose e pytest e, per quanto posso vedere, la parte più grande di quelle librerie supporta essenzialmente la stessa funzionalità, tranne per il fatto che potrebbe essere denominata in modo diverso o richiedere una sintassi leggermente diversa. Inoltre, ho notato alcune piccole differenze nei plugin disponibili (il naso ha il supporto multiprocesso, pytest non sembra per esempio)

Così sembra, il diavolo è nei dettagli, il che significa (spesso almeno) nel gusto personale ed è meglio che andiamo con la libreria che si adatta meglio al nostro gusto personale.

Quindi vorrei chiedere un'argomentazione soggettiva sul perché dovrei andare con il naso o il testaccio per scegliere la combinazione biblioteca / comunità che meglio si adatta alle nostre esigenze.

python pytest nose

— Jakob van Bethlehem
fonte

Ho appena notato che più o meno la stessa domanda è stata posta anche qui - ma è cinque anni fa, quindi penso ancora che riaffermare la domanda abbia senso

— Jakob van Bethlehem

pytestsupporta il supporto multiprocesso tramite il plugin pytest-xdist .

— Bruno Oliveira

Per inciso, i gestori di contesto sono solo semplici oggetti Python e potresti chiamare manager.__enter__()in your TestCase.setUp()e manager.__exit__()in your tearDown().

— rescdsk

Il naso non viene più mantenuto .

— toasted_flakes

Usavo Nose perché era l'impostazione predefinita con Pylons. Non mi è piaciuto affatto. Aveva tentacoli di configurazione in più punti, praticamente tutto sembrava essere fatto con un plugin poco documentato che rendeva tutto ancora più indiretto e confuso, e poiché faceva test unittest per impostazione predefinita, rompeva regolarmente con i traceback Unicode, nascondendo le fonti degli errori.

Sono stato abbastanza soddisfatto di py.test negli ultimi due anni. Essere in grado di scrivere un test assertfuori dagli schemi mi fa odiare molto meno scrivere test e hackerare tutto ciò di cui ho bisogno in cima al core è stato piuttosto facile. Piuttosto che un'interfaccia plug-in fissa, ha solo pile di ganci e un codice sorgente abbastanza comprensibile se è necessario scavare ulteriormente. Ho persino scritto un adattatore per eseguire test Testify sotto py.test e ho avuto più problemi con Testify che con py.test.

Detto questo, ho sentito che il naso ha plugin per i test senza classi e afferma l'introspezione al giorno d'oggi, quindi probabilmente andrai bene con entrambi. Mi sento ancora come se potessi colpire il terreno correndo con py.test, però, e posso capire cosa sta succedendo quando si rompe.

— Eevee
fonte

Alcuni problemi con l'occultamento dei traceback sono stati risolti intorno al naso 0,11, molti anni fa. Dato che il port di Python 3 mi aspetto che eventuali traceback unicode siano meno frequenti (anche se personalmente penso di essermi imbattuto in un problema unicode con il naso solo una volta, che si è verificato combinandolo con una classe base di test case che ha fatto qualche "trucco" che non ha fatto ' t ha davvero senso, quindi non è stata colpa del naso). Sospetto che in verità entrambi gli strumenti abbiano avuto i bordi grezzi nel corso degli anni, quindi forse ti piacerà di più quello che hai usato più di recente ;-)

— Croad Langshan

che dire della parte recente della documentazione. Sono anche confuso se usare nosetests o py.test. entrambi sembrano ugualmente buoni ma, come ho letto, la maggior parte delle persone sta usando i test del naso in questi giorni. Quale potrebbe essere il motivo per cui py.tests ha un set migliore di librerie multiprocessing disponibili?

— proprius

@proprius potrebbe essere solo che i nosetest sono venuti prima. alcuni framework ne aggiunsero il supporto, i progetti che li utilizzavano lo usarono per impostazione predefinita e si diffuse. inoltre, mentre py.test può eseguire test naso e unittest, il suo stile abituale non è organizzato attorno alle classi, quindi il porting su py.test potrebbe sembrare scoraggiante.

— Eevee

Ho iniziato a leggere la parte della documentazione di pytest e mi sono reso conto che per scopi di multiprocessing così come in termini di apprendimento per un neofita, pytest è una scelta migliore.

— proprius