In Python, qual è la corretta struttura di test per i pacchetti contenenti pacchetti? [chiuso]

Question

In Python, qual è la corretta struttura di test per i pacchetti contenenti pacchetti? [chiuso]

#1 da (0 voti)

1

Quale è la struttura del pacchetto di test preferita per i pacchetti che contengono pacchetti secondari:

Test in sottofacchetti?

a/
  __init__.py
  b.py
  c/
    __init__.py
    cc.py
    test/
      __init__.py
      test_cc.py
  d.py
  test/
    __init__.py
    test_b.py
    test_d.py

Questa struttura suggerisce che ogni sotto pacchetto è un'unità coesiva che può essere testata (e possibilmente successivamente rilasciata) da sola.

Sottopacchetti nei test?

a/
  __init__.py
  b.py
  c/
    __init__.py
    cc.py
  d.py
  test/
    __init__.py
    test_b.py
    test_c/
      __init__.py
      test_cc.py
    test_d.py

Questa struttura fa un lavoro migliore per mantenere i test in un posto, ma rende un po 'più difficile eseguire i test per un particolare sotto-pacchetto.

Qualcos'altro?

python project-structure file-structure

posta Jace Browning 09.09.2013 - 20:27

fonte

1 risposta

Leggi altre domande sui tag python project-structure file-structure

Passa alla relazione Parent Children in C # Come convalidare (e raggruppare) gli elenchi degli utenti nel Marketplace

score 0 · Answer 1

_{Probabilmente sto fraintendendo la domanda. Tuttavia, qui è un andare. Per favore, guidami alla precisa domanda di interesse tramite i commenti.}

Perché non inserire il test nei moduli stessi?

def main():
    pass

if __name__ == "__main__":
    main()

È idiomatico.
Fornisce due diversi usi per ogni modulo - da includere e utilizzare da altro codice, o da chiamare direttamente, nel qual caso vengono eseguiti test.
È abbastanza utile durante lo sviluppo. Quando si lavora su un modulo, in genere si vuole vedere prima come le modifiche locali stanno influenzando il modulo, non che siano passati 12731 dei 13000 test.
I test possono generalmente essere personalizzati in modo che ci sia un test che invochi funzionalità locali, che deridono tutti i bambini, e un test diverso per importare i sottomoduli solitamente usati e fare alcuni test che sono più vicini all'uso reale del modulo . Questo è molto utile quando un sottomodulo è rotto, ma è necessario lavorare sul modulo più in alto nella gerarchia.