Bardzo częstą strukturą katalogów nawet prostego modułu Pythona wydaje się być rozdzielenie testów jednostkowych na ich własny testkatalog:

new_project/
    antigravity/
        antigravity.py
    test/
        test_antigravity.py
    setup.py
    etc.

na przykład zobacz howto projektu Python .

Moje pytanie brzmi: Jaki jest typowy sposób przeprowadzania testów? Podejrzewam, że jest to oczywiste dla wszystkich oprócz mnie, ale nie można po prostu uruchomić python test_antigravity.pyz katalogu testowego, ponieważ import antigravityzawiedzie, ponieważ moduł nie znajduje się na ścieżce.

Wiem, że mógłbym modyfikować PYTHONPATH i inne sztuczki związane ze ścieżką wyszukiwania, ale nie mogę uwierzyć, że to najprostszy sposób - to dobrze, jeśli jesteś programistą, ale nie realistycznie oczekujesz, że użytkownicy będą używać, jeśli chcą tylko sprawdzić testy przechodzący.

Inną alternatywą jest po prostu skopiowanie pliku testowego do innego katalogu, ale wydaje się nieco głupi i nie ma sensu umieszczania go w osobnym katalogu na początek.

Więc jeśli właśnie pobrałeś źródło do mojego nowego projektu, jak byś przeprowadził testy jednostkowe? Wolę odpowiedź, która pozwoli mi powiedzieć użytkownikom: „Aby uruchomić testy jednostkowe, wykonaj X”.

Moim zdaniem najlepszym rozwiązaniem jest skorzystanie z unittest interfejsu wiersza poleceń, który doda katalog do katalogu, sys.pathwięc nie musisz (zrobione w TestLoaderklasie).

Na przykład dla takiej struktury katalogów:

new_project
├── antigravity.py
└── test_antigravity.py

Możesz po prostu uruchomić:

$ cd new_project
$ python -m unittest test_antigravity

W przypadku struktury katalogów takiej jak Twoja:

new_project
├── antigravity
│   ├── __init__.py         # make it a package
│   └── antigravity.py
└── test
    ├── __init__.py         # also make test a package
    └── test_antigravity.py

A w modułach testowych w testpakiecie możesz antigravityjak zwykle zaimportować pakiet i jego moduły:

# import the package
import antigravity

# import the antigravity module
from antigravity import antigravity

# or an object inside the antigravity module
from antigravity.antigravity import my_object

Uruchamianie jednego modułu testowego:

Aby uruchomić pojedynczy moduł testowy, w tym przypadku test_antigravity.py:

$ cd new_project
$ python -m unittest test.test_antigravity

Po prostu odwołaj się do modułu testowego w taki sam sposób, jak go importujesz.

Uruchamianie pojedynczego przypadku testowego lub metody testowej:

Możesz także uruchomić jedną TestCaselub jedną metodę testową:

$ python -m unittest test.test_antigravity.GravityTestCase
$ python -m unittest test.test_antigravity.GravityTestCase.test_method

Uruchamianie wszystkich testów:

Możesz także użyć funkcji wykrywania testów, która wykryje i uruchomi wszystkie testy, muszą to być moduły lub pakiety o nazwie test*.py(można je zmienić za pomocą -p, --patternflagi):

$ cd new_project
$ python -m unittest discover
$ # Also works without discover for Python 3
$ # as suggested by @Burrito in the comments
$ python -m unittest

Spowoduje to uruchomienie wszystkich test*.pymodułów w testpakiecie.

Najprostszym rozwiązaniem dla użytkowników jest zapewnienie skryptu wykonywalnego ( runtests.pylub niektórych takich), który uruchamia niezbędne środowisko testowe, w tym, w razie potrzeby, sys.pathtymczasowo dodaje katalog główny projektu . Nie wymaga to od użytkowników ustawiania zmiennych środowiskowych, coś takiego działa dobrze w skrypcie bootstrap:

import sys, os

sys.path.insert(0, os.path.dirname(__file__))

Następnie instrukcje dla użytkowników mogą być tak proste, jak „ python runtests.py”.

Oczywiście, jeśli naprawdę potrzebna jest ścieżka os.path.dirname(__file__), to wcale nie musisz jej dodawać sys.path; Python zawsze umieszcza katalog aktualnie uruchomionego skryptu na początku sys.path, więc w zależności od struktury katalogów, wystarczy zlokalizować go runtests.pywe właściwym miejscu.

Ponadto, najbardziej niezawodny moduł w Pythonie 2.7+ (który jest backportowany jako unittest2 dla Python 2.6 i wcześniejszych) ma teraz wbudowane wykrywanie testowe , więc nos nie jest już potrzebny, jeśli chcesz automatycznego wykrywania testu: instrukcje użytkownika mogą być tak proste, jak python -m unittest discover.

Generalnie tworzę skrypt „uruchom testy” w katalogu projektu (ten, który jest wspólny zarówno dla katalogu źródłowego, jak i test), który ładuje mój pakiet „Wszystkie testy”. Jest to zwykle kod typu „kocioł”, więc mogę go ponownie wykorzystać od projektu do projektu.

run_tests.py:

import unittest
import test.all_tests
testSuite = test.all_tests.create_test_suite()
text_runner = unittest.TextTestRunner().run(testSuite)

test / all_tests.py (z Jak uruchomić wszystkie testy jednostkowe Pythona w katalogu? )

import glob
import unittest

def create_test_suite():
    test_file_strings = glob.glob('test/test_*.py')
    module_strings = ['test.'+str[5:len(str)-3] for str in test_file_strings]
    suites = [unittest.defaultTestLoader.loadTestsFromName(name) \
              for name in module_strings]
    testSuite = unittest.TestSuite(suites)
    return testSuite

Dzięki tej konfiguracji możesz rzeczywiście tylko include antigravityw swoich modułach testowych. Minusem jest to, że potrzebujesz więcej kodu pomocniczego do wykonania konkretnego testu ... Po prostu uruchamiam je za każdym razem.

Z artykułu, do którego linkowałeś:

Utwórz plik test_modulename.py i umieść w nim swoje najtrudniejsze testy. Ponieważ moduły testowe znajdują się w innym katalogu niż kod, może być konieczne dodanie katalogu nadrzędnego modułu do PYTHONPATH w celu ich uruchomienia:

$ cd /path/to/googlemaps

$ export PYTHONPATH=$PYTHONPATH:/path/to/googlemaps/googlemaps

$ python test/test_googlemaps.py

Wreszcie istnieje jeszcze jedna popularna platforma do testowania jednostkowego dla Pythona (to takie ważne!), Nos. Nos pomaga uprościć i rozszerzyć wbudowaną najbardziej nietkniętą platformę (może na przykład automatycznie znaleźć kod testowy i skonfigurować PYTHONPATH dla Ciebie), ale nie jest zawarty w standardowej dystrybucji Pythona.

Być może powinieneś spojrzeć na nos, jak to sugeruje?

Miałem ten sam problem z osobnym folderem testów jednostkowych. Spośród wymienionych propozycji mogę dodać ścieżkę źródłową absolutną do sys.path.

Zaletą następującego rozwiązania jest to, że można uruchomić plik test/test_yourmodule.pybez uprzedniej zmiany w katalog testowy:

import sys, os
testdir = os.path.dirname(__file__)
srcdir = '../antigravity'
sys.path.insert(0, os.path.abspath(os.path.join(testdir, srcdir)))

import antigravity
import unittest

jeśli uruchomisz „python setup.py develop”, pakiet znajdzie się na ścieżce. Ale możesz tego nie chcieć, ponieważ możesz zainfekować systemową instalację Pythona, dlatego istnieją narzędzia takie jak virtualenv i buildout .

Rozwiązanie / przykład dla Unittest modułu Python

Biorąc pod uwagę następującą strukturę projektu:

ProjectName
 ├── project_name
 |    ├── models
 |    |    └── thing_1.py
 |    └── __main__.py
 └── test
      ├── models
      |    └── test_thing_1.py
      └── __main__.py

Możesz uruchomić swój projekt z katalogu głównego za pomocą python project_name, który wywołuje ProjectName/project_name/__main__.py.

Aby uruchomić testy python test, działając skutecznie ProjectName/test/__main__.py, musisz wykonać następujące czynności:

1) Zamień test/modelskatalog w pakiet, dodając __init__.pyplik. Dzięki temu przypadki testowe w podkatalogu są dostępne z testkatalogu nadrzędnego .

# ProjectName/test/models/__init__.py

from .test_thing_1 import Thing1TestCase        

2) Zmodyfikuj ścieżkę systemową, test/__main__.pyaby uwzględnić project_namekatalog.

# ProjectName/test/__main__.py

import sys
import unittest

sys.path.append('../project_name')

loader = unittest.TestLoader()
testSuite = loader.discover('test')
testRunner = unittest.TextTestRunner(verbosity=2)
testRunner.run(testSuite)

Teraz możesz pomyślnie importować elementy z project_nametestów.

# ProjectName/test/models/test_thing_1.py    

import unittest
from project_name.models import Thing1  # this doesn't work without 'sys.path.append' per step 2 above

class Thing1TestCase(unittest.TestCase):

    def test_thing_1_init(self):
        thing_id = 'ABC'
        thing1 = Thing1(thing_id)
        self.assertEqual(thing_id, thing.id)

Użyj, setup.py developaby katalog roboczy stał się częścią zainstalowanego środowiska Python, a następnie uruchom testy.

Jeśli używasz kodu VS, a testy znajdują się na tym samym poziomie co projekt, to uruchomienie i debugowanie kodu nie działa od razu po wyjęciu z pudełka. Co możesz zrobić, to zmienić plik launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python",
            "type": "python",
            "request": "launch",
            "stopOnEntry": false,
            "pythonPath": "${config:python.pythonPath}",
            "program": "${file}",
            "cwd": "${workspaceRoot}",
            "env": {},
            "envFile": "${workspaceRoot}/.env",
            "debugOptions": [
                "WaitOnAbnormalExit",
                "WaitOnNormalExit",
                "RedirectOutput"
            ]
        }    
    ]
}

Kluczową linią jest tutaj envFile

"envFile": "${workspaceRoot}/.env",

W katalogu głównym projektu dodaj plik .env

Wewnątrz pliku .env dodaj ścieżkę do katalogu głównego projektu. Spowoduje to tymczasowe dodanie

PYTHONPATH = C: \ YOUR \ PYTHON \ PROJECT \ ROOT_DIRECTORY

ścieżkę do swojego projektu, a będziesz mógł korzystać z testów jednostkowych debugowania z VS Code

Zauważyłem, że jeśli uruchomisz najdelikatniejszy interfejs wiersza poleceń z katalogu „src”, to importowanie działa poprawnie bez modyfikacji.

python -m unittest discover -s ../test

Jeśli chcesz umieścić to w pliku wsadowym w katalogu projektu, możesz to zrobić:

setlocal & cd src & python -m unittest discover -s ../test

Długo miałem ten sam problem. Ostatnio wybrałem następującą strukturę katalogów:

project_path
├── Makefile
├── src
│   ├── script_1.py
│   ├── script_2.py
│   └── script_3.py
└── tests
    ├── __init__.py
    ├── test_script_1.py
    ├── test_script_2.py
    └── test_script_3.py

a w __init__.pyskrypcie folderu testowego piszę:

import os
import sys
PROJECT_PATH = os.getcwd()
SOURCE_PATH = os.path.join(
    PROJECT_PATH,"src"
)
sys.path.append(SOURCE_PATH)

Bardzo ważny dla współdzielenia projektu jest Makefile, ponieważ wymusza prawidłowe uruchamianie skryptów. Oto polecenie, które umieściłem w Makefile:

run_tests:
    python -m unittest discover .

Plik Makefile jest ważny nie tylko ze względu na uruchamiane polecenie, ale także ze względu na to, skąd go uruchamia . Jeśli wykonasz cd w testach i zrobisz python -m unittest discover ., to nie zadziała, ponieważ skrypt init w module unit_tests wywołuje os.getcwd (), co wskazywałoby następnie na niepoprawną ścieżkę bezwzględną (która byłaby dołączona do sys.path i byłby brakujący folder źródłowy). Skrypty byłyby uruchamiane, ponieważ funkcja Discover znajduje wszystkie testy, ale nie działałyby poprawnie. Tak więc plik Makefile ma na celu uniknięcie konieczności pamiętania tego problemu.

Bardzo podoba mi się to podejście, ponieważ nie muszę dotykać folderu src, testów jednostkowych ani zmiennych środowiskowych i wszystko działa płynnie.

Daj mi znać, jeśli wam się spodoba.

Mam nadzieję, że to pomaga

Oto struktura mojego projektu:

ProjectFolder:
 - project:
     - __init__.py
     - item.py
 - tests:
     - test_item.py

Uważam, że lepiej jest zaimportować w metodzie setUp ():

import unittest
import sys    

class ItemTest(unittest.TestCase):

    def setUp(self):
        sys.path.insert(0, "../project")
        from project import item
        # further setup using this import

    def test_item_props(self):
        # do my assertions

if __name__ == "__main__":
    unittest.main()

Jaki jest typowy sposób przeprowadzania testów

Używam Python 3.6.2

cd new_project

pytest test/test_antigravity.py

Aby zainstalować pytest :sudo pip install pytest

Nie ustawiłem żadnej zmiennej ścieżki i mój import nie kończy się niepowodzeniem z tą samą „projektową” strukturą projektu.

Skomentowałem te rzeczy: if __name__ == '__main__'tak:

test_antigravity.py

import antigravity

class TestAntigravity(unittest.TestCase):

    def test_something(self):

        # ... test stuff here


# if __name__ == '__main__':
# 
#     if __package__ is None:
# 
#         import something
#         sys.path.append(path.dirname(path.dirname(path.abspath(__file__))))
#         from .. import antigravity
# 
#     else:
# 
#         from .. import antigravity
# 
#     unittest.main()

Możliwe jest użycie otoki, która uruchamia wybrane lub wszystkie testy.

Na przykład:

./run_tests antigravity/*.py

lub aby uruchomić wszystkie testy rekursywnie, użyj globbing ( tests/**/*.py) (enable by shopt -s globstar).

Opakowanie może zasadniczo służyć argparsedo analizowania argumentów takich jak:

parser = argparse.ArgumentParser()
parser.add_argument('files', nargs='*')

Następnie załaduj wszystkie testy:

for filename in args.files:
    exec(open(filename).read())

następnie dodaj je do swojego zestawu testów (używając inspect):

alltests = unittest.TestSuite()
for name, obj in inspect.getmembers(sys.modules[__name__]):
    if inspect.isclass(obj) and name.startswith("FooTest"):
        alltests.addTest(unittest.makeSuite(obj))

i uruchom je:

result = unittest.TextTestRunner(verbosity=2).run(alltests)

Sprawdź ten przykład, aby uzyskać więcej informacji.

Zobacz także: Jak uruchomić wszystkie testy jednostkowe Pythona w katalogu?

Python 3+

Dodawanie do @Pierre

Przy użyciu unittesttakiej struktury katalogów:

new_project
├── antigravity
│   ├── __init__.py         # make it a package
│   └── antigravity.py
└── test
    ├── __init__.py         # also make test a package
    └── test_antigravity.py

Aby uruchomić moduł testowy test_antigravity.py:

$ cd new_project
$ python -m unittest test.test_antigravity

Lub singiel TestCase

$ python -m unittest test.test_antigravity.GravityTestCase

Obowiązkowe nie zapomnij __init__.pynawet jeśli pusty, inaczej nie będzie działać.

Nie możesz importować z katalogu nadrzędnego bez jakiegoś voodoo. Oto jeszcze jeden sposób, który działa przynajmniej z Pythonem 3.6.

Najpierw przygotuj plik test / context.py z następującą zawartością:

import sys
import os
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

Następnie wykonaj następujący import w pliku test / test_antigravity.py:

import unittest
try:
    import context
except ModuleNotFoundError:
    import test.context    
import antigravity

Zauważ, że powodem tej klauzuli try-wyjątkiem jest to

• import test.context kończy się niepowodzeniem, gdy jest uruchamiany z „python test_antigravity.py” i
• Kontekst importowania kończy się niepowodzeniem, gdy jest uruchamiany z „python -m unittest” z katalogu new_project.

Dzięki tej sztuczce oboje działają.

Teraz możesz uruchomić wszystkie pliki testowe w katalogu testowym za pomocą:

$ pwd
/projects/new_project
$ python -m unittest

lub uruchom pojedynczy plik testowy z:

$ cd test
$ python test_antigravity

Ok, nie jest to o wiele ładniejsza niż zawartość content.py w ramach test_antigravity.py, ale może trochę. Sugestie są mile widziane.

Jeśli masz wiele katalogów w katalogu testowym, musisz dodać do każdego katalogu __init__.pyplik.

/home/johndoe/snakeoil
└── test
    ├── __init__.py        
    └── frontend
        └── __init__.py
        └── test_foo.py
    └── backend
        └── __init__.py
        └── test_bar.py

Następnie, aby uruchomić każdy test na raz, uruchom:

python -m unittest discover -s /home/johndoe/snakeoil/test -t /home/johndoe/snakeoil

Źródło: python -m unittest -h

  -s START, --start-directory START
                        Directory to start discovery ('.' default)
  -t TOP, --top-level-directory TOP
                        Top level directory of project (defaults to start
                        directory)

Ten skrypt BASH wykona najbardziej testowy katalog Pythona z dowolnego miejsca w systemie plików, bez względu na katalog roboczy, w którym się znajdujesz.

Jest to przydatne, gdy pozostajesz w katalogu roboczym ./srclub ./exampleroboczym i potrzebujesz szybkiego testu jednostkowego:

#!/bin/bash

this_program="$0"
dirname="`dirname $this_program`"
readlink="`readlink -e $dirname`"

python -m unittest discover -s "$readlink"/test -v

Nie ma potrzeby, aby test/__init__.pyplik obciążał pakiet / obciążenie pamięci podczas produkcji.

W ten sposób możesz uruchamiać skrypty testowe z dowolnego miejsca bez konieczności zmieniania zmiennych systemowych z wiersza poleceń.

Dodaje to główny folder projektu do ścieżki pythona, z lokalizacją znalezioną względem samego skryptu, a nie względem bieżącego katalogu roboczego.

import sys, os

sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.realpath(__file__))))

Dodaj to na początku wszystkich skryptów testowych. Spowoduje to dodanie głównego folderu projektu do ścieżki systemowej, dzięki czemu będzie działał każdy importowany z niego moduł. I nie ma znaczenia, skąd uruchamiasz testy.

Możesz oczywiście zmienić plik ścieżka_projektu, aby dopasować położenie głównego folderu projektu.

Jeśli szukasz rozwiązania tylko z wiersza poleceń:

W oparciu o następującą strukturę katalogów (uogólniony z dedykowanym katalogiem źródłowym):

new_project/
    src/
        antigravity.py
    test/
        test_antigravity.py

Windows : (w new_project)

$ set PYTHONPATH=%PYTHONPATH%;%cd%\src
$ python -m unittest discover -s test

Zobacz to pytanie, jeśli chcesz użyć tego we wsadowej pętli for.

Linux : (w new_project)

$ export PYTHONPATH=$PYTHONPATH:$(pwd)/src  [I think - please edit this answer if you are a Linux user and you know this]
$ python -m unittest discover -s test

Dzięki takiemu podejściu można również dodać więcej katalogów do PYTHONPATH, jeśli to konieczne.

Naprawdę powinieneś użyć narzędzia pip.

Służy pip install -e .do instalowania pakietu w trybie programowania. Jest to bardzo dobra praktyka, zalecana przez pytest (patrz dokumentacja dobrych praktyk , gdzie można również znaleźć dwa układy projektów do naśladowania).