2011-10-07 15 views
19

Niestety zauważyłem, że istnieje zbyt wiele sposobów, aby zachować unittest w Pythonie i zazwyczaj nie są dobrze udokumentowane.Optymalna struktura struktury plików modułowych modułów Pythona?

szukam dla "ostateczny" strukturze, można by zrealizować większość z poniższych wymagań:

  • być wykrywalne przez ram testowych, w tym:
    • pytest
    • nosetests
    • tox
  • testy powinny być outside the module files oraz w innym katalogu niż sam moduł (konserwacja), prawdopodobnie w katalogu tests/ na poziomie pakietu.
  • powinno być możliwe po prostu wykonać plik testowy (test musi być w stanie wiedzieć, gdzie jest moduł, który ma na celu przetestowanie)

Proszę podać plik testowy próbki, które wykonuje fałszywy test, określ nazwa pliku i katalog.

+0

Jakie jest Twoje pytanie, naprawdę? Dlaczego po prostu nie skorzystasz z jednego z frameworków i pozwolisz wszystkim robić to, co im się podoba? – pvoosten

Odpowiedz

17

Oto podejście Używam:

Struktura katalogów

# All __init__.py files are empty in this example. 
app 
    package_a 
     __init__.py 
     module_a.py 
    package_b 
     __init__.py 
     module_b.py 
    test 
     __init__.py 
     test_app.py 
    __init__.py 
main.py 

main.py

# This is the application's front-end. 
# 
# The import will succeed if Python can find the `app` package, which 
# will occur if the parent directory of app/ is in sys.path, either 
# because the user is running the script from within that parect directory 
# or because the user has included the parent directory in the PYTHONPATH 
# environment variable. 

from app.package_a.module_a import aaa 
print aaa(123, 456) 

module_a.py

# We can import a sibling module like this. 
from app.package_b.module_b import bbb 
def aaa(s, t): 
    return '{0} {1}'.format(s, bbb(t)) 

# We can also run module_a.py directly, using Python's -m option, which 
# allows you to run a module like a script. 
# 
# python -m app.package_a.module_a 
if __name__ == '__main__': 
    print aaa(111, 222) 
    print bbb(333) 

module_b.py

def bbb(s): 
    return s + 1 

test_app.py

import unittest 

# From the point of view of testing code, our working modules 
# are siblings. Imports work accordingly, as seen in module_a. 
from app.package_a.module_a import aaa 
from app.package_a.module_a import bbb 

class TestApp(unittest.TestCase): 

    def test_aaa(self): 
     self.assertEqual(aaa(77, 88), '77 89') 

    def test_bbb(self): 
     self.assertEqual(bbb(99), 100) 

# Simiarly, we can run our test modules directly as scripts using the -m option, 
# or using nose. 
# 
# python -m app.test.test_app 
# nosetests app/test/test_app.py 

if __name__ == '__main__': 
    unittest.main() 
+0

Dzięki, dla przykładu, ale jestem pewien, że jeśli uruchomisz test_app.py, to będzie narzekać, że nie będzie w stanie znaleźć "aplikacji". Pomyśl, że test musi przejść, zanim pakiet zostanie wdrożony, do ścieżki dołączonej do Pythona. – sorin

+0

@sorin To prawda, ale możesz bardzo zbliżyć się do dwóch przykładów podanych na końcu mojej odpowiedzi. – FMc

+0

Chodziło o to, aby wywołać struktury testowe bez żadnych parametrów. – sorin

Powiązane problemy