Ha senso installare i miei test di unità Python nei pacchetti del sito?

Question

Sto sviluppando il mio primo pacchetto di distribuzione Python. La mia curva di apprendimento su La confezione Python sembra essersi stabilizzata un po ', ma sto ancora lottando con alcune domande aperte. Uno è se dovrei far sì che i miei test unitari siano installati insieme al mio codice.

Capisco it's important to include tests in a source distribution. Quello che mi chiedo è se dovrei effettivamente configurarli per l'installazione?

ho visto almeno un pacchetto popolare che sembra fare apposta (PyHamcrest), e almeno un altro che sembra farlo per caso (behave).

Quindi il mio (multi-parte) domanda è questa:

• Ha mai senso per installare il mio test di unità pacchetto a fianco il mio codice pacchetto ?

• Se sì, qual è il caso d'uso? Chi li userebbe e per cosa? Cioè, chi li userebbe che non sarebbe perfettamente felice di scaricare la distribuzione di origine e di eseguire invece python setup.py test?

• E come utilizzerebbero i test dell'unità installati? come import test; test.run() o qualcosa del genere così?

Answer 1

Dopo aver esaminato questo problema, e fino a quando qualcuno più esperto ha un minuto per soppesare il contrario, la mia comprensione è che la risposta semplice è: "No, non è possibile installare i test unitari, inclusi solo nella distribuzione dell'origine ".

Nella manciata di casi che ho trovato cui sono stati installati i test, il tutto si è rivelato essere accidentali ed è più facile di quanto si potrebbe pensare a fare l'errore senza accorgersene.

Ecco come avviene:

1. Il parametro packages=find_packages() viene utilizzato in modo setup.py pacchetti possono essere trovati senza dover elencarli esplicitamente.
2. La cartella test viene trasformata in un pacchetto (aggiungendo __init__.py) in modo che i test possano fare riferimento ai moduli testati utilizzando la denominazione relativa (ad esempio from .. import pkg.mod).
3. setuptools installa test come pacchetto separato, insieme agli altri nel progetto. Nota: questo significa che è possibile eseguire in import test l'interprete Python e funziona, quasi certamente non quello che si intendeva, soprattutto perché un sacco di altre persone usare quel nome per la loro directory test :)

La correzione è quello di utilizzare il impostazione: packages=find_packages(exclude=['test']) per impedire l'installazione della directory di test.

Answer 2

Tuttavia, non sono un esperto, vorrei condividere la mia opinione.

Vorrei sempre mettere i test a fianco del codice se mi aspetto che qualcosa possa fallire a seconda delle ragioni esterne. Che si tratti di bit-order, strani fusi orari, codifica dei caratteri, interi a 24 bit o qualsiasi altra cosa bizzarra che puoi incontrare e testare.

Chi non sarebbe felice di scaricare la fonte ed eseguire test? Forse alcuni debian utenti che i pacchetti sono stati rimossi da fonti (so che stai parlando di python ma lasciatemi essere un po 'generico) e la tua libreria può occasionalmente fallire a causa di alcune strane cose nel sistema.

Se i tuoi test assicurano solo sanità interna, salterò a collegarli, poiché con le fonti esterne non valgono molto, dal momento che non cambierai mai le parti interne della libreria.

Personalmente, ho sentito parlare di una cosa non funzionante perché è stata spostata su una macchina IBM con un diverso ordine di bit. Non ricordo se dipendesse da operazioni a bit o avesse qualcosa di pre-calcolato e memorizzato nella cache staticamente. Ma a volte è saggio verificare se carichi ciò che pensi di aver salvato.

MODIFICA: Forse sarà meglio riformulare. Installerei i test quando ritieni che ci possano essere avvertenze sulla portabilità. Penso che sia sempre utile controllare le cose quando si distribuiscono cose su un sistema diverso.

Answer 3

A mio parere, la risposta corretta è NO ma troverete alcune distribuzioni che installano i test. I test non dovrebbero essere installati ma dovrebbero essere inclusi nella distribuzione di origine. Secondo me, in un mondo ideale, testare i pacchetti installati dovrebbe essere un'attività eseguita dal gestore pacchetti (pip) e la directory site-packages non dovrebbe essere inquinata da sorgenti di test.

Ho recentemente studiato questo argomento e ho raccolto informazioni da varie fonti e ho trovato diversi modi per strutturare la gerarchia di directory/pacchetti di una distribuzione che contiene sia le fonti che i test di libreria. La maggior parte di queste strutture sembra essere obsoleta e sono state inventate come tentativi di aggirare i set di funzionalità incomplete dei vecchi sistemi di distribuzione al momento. Sfortunatamente molte fonti online (blogposts/documentazione precedenti) stanno ancora pubblicizzando i metodi obsoleti, quindi è molto facile trovare un how-to/tutorial con ricerca online obsoleto.

Supponiamo che tu abbia una libreria denominata "my_lib" e desideri strutturare i sorgenti della tua distribuzione. Mostrerò due modi popolari e apparentemente superati per strutturare la tua distribuzione e un terzo modo che ho trovato per essere il più versatile. Il terzo metodo potrebbe anche essere obsoleto, ma quello è il migliore che conosco al momento di pubblicare questa risposta. ;-)

Metodo # 1

distribuzioni che (intenzionalmente o meno) installano i test di solito usano questo metodo.

gerarchia

+- my_lib 
| +- __init__.py 
| +- source1.py 
| +- source2.py 
| +- tests 
|  +- __init__.py 
|  +- test_1.py 
|  +- test_2.py 
+- setup.py 

Metodo # 2

I test non sono installati ma dovrebbero essere inclusi nella distribuzione di origine attraverso il file MANIFEST.in.

gerarchia

+- my_lib 
| +- __init__.py 
| +- source1.py 
| +- source2.py 
+- tests 
| +- __init__.py 
| +- test_1.py 
| +- test_2.py 
+- setup.py 

Metodo # 3 (preferisco questo.)

Questo è più o meno simile al metodo # 2 con un po 'di torsione (la src dir).

gerarchia

+- src 
| +- my_lib 
|  +- __init__.py 
|  +- source1.py 
|  +- source2.py 
+- tests 
| +- __init__.py 
| +- test_1.py 
| +- test_2.py 
+- setup.py 

setup() chiamata in setup.py

from setuptools import setup, find_packages 

setup(
    ... 
    packages=find_packages('src'), 
    package_dir={'': 'src'}, 
    ... 
) 

MANIFEST.in

recursive-include tests *.py 

test non essere installati ma saranno inclusi nella distribuzione di origine tramite il nostro MANIFEST.in.

Nel caso del metodo # 3 si ha una directory src che di solito contiene solo un singolo pacchetto che è la radice della libreria. Mettere il pacchetto my_lib in un src directory (directory e non un pacchetto in modo che non è necessario un src/__init__.py) ha i seguenti vantaggi:

• Quando si esegue setup.py la directory che contiene setup.py è implicitamente aggiunto al percorso pitone . Ciò significa che nel tuo setup.py puoi importare accidentalmente e in modo improprio dalla tua libreria se il pacchetto è nella stessa directory di setup.py. Inserendo il pacchetto my_lib in src possiamo evitare questo problema.

• da poter usare facilmente le vostre fonti di prova distribuita per testare sia le sorgenti delle librerie distribuite e anche la libreria installata:

  • Quando si esegue il test con setup.py test la package_dir={'': 'src'} una parte del tuo setup() garanzie di chiamata che i test saranno consultare il pacchetto della libreria my_lib che si mantiene in src/my_lib.
  • È anche possibile eseguire test senza setup.py. Nel caso più semplice puoi farlo con il comando python -m unittest. In questo caso la directory src non farà parte del percorso python, quindi è possibile utilizzare questo metodo per testare la versione installata della libreria anziché le origini in src.