.. highlightlang:: python åºæ¬çãªãã¿ã¼ã³ã¨ä¾ ==================== .. Basic patterns and examples ========================================================== .. Pass different values to a test function, depending on command line options ---------------------------------------------------------------------------- ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ã§ãã¹ãé¢æ°ã«éãå¤ã渡ã -------------------------------------------------- .. regendoc:wipe .. Suppose we want to write a test that depends on a command line option. Here is a basic pattern how to achieve this:: ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ã§å¶å¾¡ãããã¹ããæ¸ãããã¨ä»®å®ãã¾ãããããå®ç¾ããåºæ¬çãªæ¹æ³ã¯æ¬¡ã®éãã§ã:: # test_sample.py ã®å 容 def test_answer(cmdopt): if cmdopt == "type1": print ("first") elif cmdopt == "type2": print ("second") assert 0 # ä½ã表示ãããããè¦ããã .. For this to work we need to add a command line option and provide the ``cmdopt`` through a :ref:`function argument <funcarg>` factory:: ãã®ããã«ã¯ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ã追å ããå¿ è¦ãããã¾ãã :ref:`é¢æ°ã®å¼æ° <funcarg>` ãã¡ã¯ããªã¼ã使ã£ã¦ ``cmdopt`` ãæä¾ãã¾ã:: # conftest.py ã®å 容 def pytest_addoption(parser): parser.addoption("--cmdopt", action="store", default="type1", help="my option: type1 or type2") def pytest_funcarg__cmdopt(request): return request.config.option.cmdopt .. Let's run this without supplying our new command line option:: å ã»ã©ä½æããã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãæå®ããã«å®è¡ãã¦ã¿ã¾ããã:: $ py.test -q test_sample.py collecting ... collected 1 items F ================================= FAILURES ================================= _______________________________ test_answer ________________________________ cmdopt = 'type1' def test_answer(cmdopt): if cmdopt == "type1": print ("first") elif cmdopt == "type2": print ("second") > assert 0 # ä½ã表示ãããããè¦ããã E assert 0 test_sample.py:6: AssertionError ----------------------------- Captured stdout ------------------------------ first 1 failed in 0.01 seconds .. And now with supplying a command line option:: 次ã¯ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãæå®ãã¦å®è¡ãã¾ã:: $ py.test -q --cmdopt=type2 collecting ... collected 1 items F ================================= FAILURES ================================= _______________________________ test_answer ________________________________ cmdopt = 'type2' def test_answer(cmdopt): if cmdopt == "type1": print ("first") elif cmdopt == "type2": print ("second") > assert 0 # ä½ã表示ãããããè¦ããã E assert 0 test_sample.py:6: AssertionError ----------------------------- Captured stdout ------------------------------ second 1 failed in 0.01 seconds .. Ok, this completes the basic pattern. However, one often rather wants to process command line options outside of the test and rather pass in different or more complex objects. See the next example or refer to :ref:`mysetup` for more information on real-life examples. ã¯ããåºæ¬çãªä½¿ãæ¹ãåããã¾ããããã以å¤ã«ãããã¹ãã®å¤é¨ã§ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãå¦çãã¦ãå¥ãªãã¸ã§ã¯ããè¤éãªãªãã¸ã§ã¯ãã渡ããããã¨ãããããã¾ãã次ã®ä¾ããããã¯ç¾å®ã®ä¸çã§ã®ä¾ã¯ :ref:`mysetup` ãåç §ãã¦ãã ããã .. Dynamically adding command line options -------------------------------------------------------------- ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãåçã«è¿½å ------------------------------------ .. regendoc:wipe .. Through :confval:`addopts` you can statically add command line options for your project. You can also dynamically modify the command line arguments before they get processed:: :confval:`addopts` ã使ã£ã¦ãããã¸ã§ã¯ãã«ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãéçã«è¿½å ã§ãã¾ããéçã«è¿½å ããã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãå¦çãããåã«ããã®ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãåçã«å¤æ´ãããã¨ãã§ãã¾ã:: # conftest.py ã®å 容 import sys def pytest_cmdline_preparse(args): if 'xdist' in sys.modules: # pytest-xdist ãã©ã°ã¤ã³ import multiprocessing num = max(multiprocessing.cpu_count() / 2, 1) args[:] = ["-n", str(num)] + args .. If you have the :ref:`xdist plugin <xdist>` installed you will now always perform test runs using a number of subprocesses close to your CPU. Running in an empty directory with the above conftest.py:: :ref:`xdist ãã©ã°ã¤ã³ <xdist>` ãã¤ã³ã¹ãã¼ã«æ¸ã¿ãªããæ¯å CPU æ°ã«è¿ããµãããã»ã¹ã使ã£ã¦ãã¹ããå®è¡ã§ãã¾ãã空ã®ãã£ã¬ã¯ããªã§ä¸è¨ã® conftest.py ãå®è¡ãã¾ã:: $ py.test =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 gw0 I / gw1 I / gw2 I / gw3 I gw0 [0] / gw1 [0] / gw2 [0] / gw3 [0] scheduling tests via LoadScheduling ============================= in 0.52 seconds ============================= .. _`excontrolskip`: ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ã§ãã¹ãã®ã¹ããããå¶å¾¡ ------------------------------------------------ .. Control skipping of tests according to command line option -------------------------------------------------------------- .. regendoc:wipe .. Here is a ``conftest.py`` file adding a ``--runslow`` command line option to control skipping of ``slow`` marked tests:: ``slow`` ã¨ãã¼ã¯ããããã¹ãã®ã¹ããããå¶å¾¡ããã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ ``--runslow`` ã追å ãã ``conftest.py`` ãããã¾ã:: # conftest.py ã®å 容 import pytest def pytest_addoption(parser): parser.addoption("--runslow", action="store_true", help="run slow tests") def pytest_runtest_setup(item): if 'slow' in item.keywords and not item.config.getvalue("runslow"): pytest.skip("need --runslow option to run") .. We can now write a test module like this:: ãã¹ãã¢ã¸ã¥ã¼ã«ã¯æ¬¡ã®ããã«æ¸ãã¾ã:: # test_module.py ã®å 容 import pytest slow = pytest.mark.slow def test_func_fast(): pass @slow def test_func_slow(): pass .. and when running it will see a skipped "slow" test:: å®è¡ããã¨ã"slow" ãã¹ããã¹ãããããã¾ã:: $ py.test -rs # "-rs" 㯠's' ã®è©³ç´°ãã¬ãã¼ããã¾ã =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 collecting ... collected 2 items test_module.py .s ========================= short test summary info ========================== SKIP [1] /tmp/doc-exec-225/conftest.py:9: need --runslow option to run =================== 1 passed, 1 skipped in 0.01 seconds ==================== .. Or run it including the ``slow`` marked test:: ããã㯠``slow`` ã¨ãã¼ã¯ããããã¹ããå®è¡ãã¾ã:: $ py.test --runslow =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 collecting ... collected 2 items test_module.py .. ========================= 2 passed in 0.01 seconds ========================= .. Writing well integrated assertion helpers -------------------------------------------------- çµ±åçãªã¢ãµã¼ã·ã§ã³ãã«ãã¼ã®ä½æ ---------------------------------- .. regendoc:wipe .. If you have a test helper function called from a test you can use the ``pytest.fail`` marker to fail a test with a certain message. The test support function will not show up in the traceback if you set the ``__tracebackhide__`` option somewhere in the helper function. Example:: ãã¹ãããå¼ã°ãããã¹ããã«ãã¼é¢æ°ããããªããç¹å®ã¡ãã»ã¼ã¸ä»ãã§ãã¹ãã失æããã ``pytest.fail`` ãã¼ã«ã¼ã使ãã¾ãã ``__tracebackhide__`` ãªãã·ã§ã³ããã«ãã¼é¢æ°å ã«ã»ããããã¨ããã®ãã¹ããã«ãã¼é¢æ°ã¯ãã¬ã¼ã¹ããã¯ã表示ããªããªãã¾ãããµã³ãã«ãç´¹ä»ãã¾ã:: # test_checkconfig.py ã®å 容 import pytest def checkconfig(x): __tracebackhide__ = True if not hasattr(x, "config"): pytest.fail("not configured: %s" %(x,)) def test_something(): checkconfig(42) .. The ``__tracebackhide__`` setting influences py.test showing of tracebacks: the ``checkconfig`` function will not be shown unless the ``--fulltrace`` command line option is specified. Let's run our little function:: ``__tracebackhide__`` è¨å®ã¯ãpy.test ã®ãã¬ã¼ã¹ããã¯è¡¨ç¤ºã«å½±é¿ãä¸ãã¾ãã ``checkconfig`` é¢æ°ã¯ã ``--fulltrace`` ã³ãã³ãã©ã¤ã³ãªãã·ã§ã³ãæå®ããªãéãããã¬ã¼ã¹ããã¯ã表示ãã¾ããããã®å°ããªé¢æ°ãå®è¡ãã¦ã¿ã¾ããã:: $ py.test -q test_checkconfig.py collecting ... collected 1 items F ================================= FAILURES ================================= ______________________________ test_something ______________________________ def test_something(): > checkconfig(42) E Failed: not configured: 42 test_checkconfig.py:8: Failed 1 failed in 0.01 seconds .. Detect if running from within a py.test run -------------------------------------------------------------- py.test ã§å®è¡ãã¦ãããã¨ãæ¤åº -------------------------------- .. regendoc:wipe .. Usually it is a bad idea to make application code behave differently if called from a test. But if you absolutely must find out if your application code is running from a test you can do something like this:: é常ã¯ããã¹ãããå¼ã°ããå ´åã«ã¢ããªã±ã¼ã·ã§ã³ã³ã¼ãã®æ¯ãèããåããã®ã¯æªãèãã§ããããããã¢ããªã±ã¼ã·ã§ã³ã³ã¼ãããã¹ãããå®è¡ããã¦ããå ´åã«ã確å®ã«è§£æããªããã°ãªããªããã¨ããããªãã次ã®ãããªãã¨ãã§ãã¾ã:: # conftest.py ã®å 容 def pytest_configure(config): import sys sys._called_from_test = True def pytest_unconfigure(config): del sys._called_from_test .. and then check for the ``sys._called_from_test`` flag:: ã¢ããªã±ã¼ã·ã§ã³å 㧠``sys._called_from_test`` ã¨ãããã©ã°ããã§ãã¯ãã¾ã:: if hasattr(sys, '_called_from_test'): # ãã¹ãå ããå®è¡æã«å¼ã°ãã else: # "æ®é" ã®ã¨ãã«å¼ã°ãã .. accordingly in your application. It's also a good idea to use your own application module rather than ``sys`` for handling flag. ãã©ã°ãå¦çããããã« ``sys`` ãããç¬èªã®ã¢ããªã±ã¼ã·ã§ã³ã¢ã¸ã¥ã¼ã«ã使ãã®ãè¯ãèãã§ãã .. Adding info to test report header -------------------------------------------------------------- ãã¹ãã¬ãã¼ããããã¼ã«æ å ±ã追å ---------------------------------- .. regendoc:wipe .. It's easy to present extra information in a py.test run:: py.test ã®å®è¡æã«è¿½å ã®æ å ±ã表示ããã®ã¯ç°¡åã§ã:: # conftest.py ã®å 容 def pytest_report_header(config): return "project deps: mylib-1.1" .. which will add the string to the test header accordingly:: ãã®é¢æ°ã¯ãã¹ããããã¼ã«æååã追å ãã¾ã:: $ py.test =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 project deps: mylib-1.1 collecting ... collected 0 items ============================= in 0.00 seconds ============================= .. regendoc:wipe .. You can also return a list of strings which will be considered as several lines of information. You can of course also make the amount of reporting information on e.g. the value of ``config.option.verbose`` so that you present more information appropriately:: è¤æ°è¡ã«æ¸¡ãæ å ±ãæ±ããªãæååã®ãªã¹ããè¿ãã¾ããå½ç¶ã¬ãã¼ãã®æ å ±éãå¶å¾¡ã§ãã¾ããä¾ãã°ãå¿ è¦ãªã¨ãã«æ å ±ã表示ããããã« ``config.option.verbose`` ã®å¤ã§åãåãã¾ã:: # conftest.py ã®å 容 def pytest_report_header(config): if config.option.verbose > 0: return ["info1: did you know that ...", "did you?"] .. which will add info only when run with "--v":: "--v" ãæå®ãã¦å®è¡ããã¨ãã®ã¿è¿½å ã®æ å ±ã表示ããã¾ã:: $ py.test -v =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 -- /home/hpk/venv/0/bin/python info1: did you know that ... did you? collecting ... collected 0 items ============================= in 0.00 seconds ============================= .. and nothing when run plainly:: ä½ãæå®ããã«å®è¡ããã¨ä½ã表示ãã¾ãã:: $ py.test =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 collecting ... collected 0 items ============================= in 0.00 seconds ============================= .. profiling test duration -------------------------- ãã¹ãå®è¡ã®ãããã¡ã¤ãªã³ã° ---------------------------- .. regendoc:wipe .. versionadded: 2.2 .. If you have a slow running large test suite you might want to find out which tests are the slowest. Let's make an artifical test suite:: 巨大ãªãã¹ãã¹ã¤ã¼ãã®å®è¡ã«æéããããå ´åãã©ã®ãã¹ããæãé ããã調ã¹ããã¨ããããã¾ããæ¬ä¼¼ãã¹ãã¹ã¤ã¼ãã§è©¦ãã¦ã¿ã¾ããã:: # test_some_are_slow.py ã®å 容 import time def test_funcfast(): pass def test_funcslow1(): time.sleep(0.1) def test_funcslow2(): time.sleep(0.2) .. Now we can profile which test functions execute the slowest:: 次ã«ããã«ãã¦ãã©ã®ãã¹ãé¢æ°ãæãé ããããããã¡ã¤ã«ã§ãã¾ã:: $ py.test --durations=3 =========================== test session starts ============================ platform linux2 -- Python 2.7.1 -- pytest-2.2.4 collecting ... collected 3 items test_some_are_slow.py ... ========================= slowest 3 test durations ========================= 0.20s call test_some_are_slow.py::test_funcslow2 0.10s call test_some_are_slow.py::test_funcslow1 0.00s setup test_some_are_slow.py::test_funcslow2 ========================= 3 passed in 0.31 seconds =========================