%global _empty_manifest_terminate_build 0 Name: python-pyt Version: 1.0.5 Release: 1 Summary: easily run python unit tests License: MIT URL: http://github.com/Jaymon/pyt Source0: https://mirrors.nju.edu.cn/pypi/web/packages/b4/64/0703f67787591bb42fb0af220774d5a2b7ec64241378defe426324e63451/pyt-1.0.5.tar.gz BuildArch: noarch %description Pyt is a lightweight wrapper around `Python’s unittest module `__ that adds some nice features and enhancements over the stock ``unittest`` module. Quickstart ~~~~~~~~~~ Pyt overrides unittest’s built-in pathfinding to be smarter and less verbose, so you can match tests using prefix matching which makes running a test like: $ python -m unittest tests.foo_test.BarTestCase.test_che as simple as: $ pyt foo.Bar.che But it’s even less verbose if you want it to be, pyt can reach into the modules and classes to do its matching, so you don’t even need to specify the module and class if you don’t want to: $ pyt che More examples ^^^^^^^^^^^^^ To run all the ``Happy`` tests: $ pyt Happy To run all the ``newmodule`` tests: $ pyt newmodule To run more than one test: $ pyt test1 test2 ... To run every test ``pyt`` can find: $ pyt And the way I like to run all tests in the current directory: $ pyt -vb Which can also be written: $ pyt --verbose --buffer Flags ~~~~~ To see everything pyt can do $ pyt --help –warnings ^^^^^^^^^ This will convert warnings into errors. $ pyt --warnings –rerun ^^^^^^ If your last testrun had failing tests this will rerun only the tests that failed. $pyt --rerun Things to be aware of ~~~~~~~~~~~~~~~~~~~~~ pyt uses Python’s PEP 8 style conventions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``pyt`` uses `Python’s code styling conventions `__ to decide what is the module and class, so, given input like this: $ pyt foo.bar.Baz.che ``pyt`` will consider ``foo.bar`` to be the module, ``Baz`` to be a class (because it starts with a capital letter), and ``che`` to be a method (since it comes after the class). Likewise, ``pyt`` uses unittest conventions, so a test module should end with ``_test`` (eg, ``foo.bar_test``) or start with test (eg, ``test_foo.py``) and a TestCase class should extend ``unittest.TestCase``, and test methods should start with ``test_`` (eg, ``test_che``). Vague input can cause pyt to run more tests than you expect ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So if you have something like this: project/ __init__.py user.py foo/ __init__.py user.py tests/ __init__.py user_test.py foo/ __init__.py user_test.py And you want to run tests for ``foo.user`` and you run: $ pyt user it will run both ``tests/user_test`` and ``tests.foo.user_test``, the solution is to just be more verbose when you have to be: $ pyt foo.user Environment Variables ^^^^^^^^^^^^^^^^^^^^^ If you are running the tests within pyt, you might notice there is an environment variable ``PYT_TEST_COUNT`` that contains the count of how many tests pyt found to run. %package -n python3-pyt Summary: easily run python unit tests Provides: python-pyt BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-pyt Pyt is a lightweight wrapper around `Python’s unittest module `__ that adds some nice features and enhancements over the stock ``unittest`` module. Quickstart ~~~~~~~~~~ Pyt overrides unittest’s built-in pathfinding to be smarter and less verbose, so you can match tests using prefix matching which makes running a test like: $ python -m unittest tests.foo_test.BarTestCase.test_che as simple as: $ pyt foo.Bar.che But it’s even less verbose if you want it to be, pyt can reach into the modules and classes to do its matching, so you don’t even need to specify the module and class if you don’t want to: $ pyt che More examples ^^^^^^^^^^^^^ To run all the ``Happy`` tests: $ pyt Happy To run all the ``newmodule`` tests: $ pyt newmodule To run more than one test: $ pyt test1 test2 ... To run every test ``pyt`` can find: $ pyt And the way I like to run all tests in the current directory: $ pyt -vb Which can also be written: $ pyt --verbose --buffer Flags ~~~~~ To see everything pyt can do $ pyt --help –warnings ^^^^^^^^^ This will convert warnings into errors. $ pyt --warnings –rerun ^^^^^^ If your last testrun had failing tests this will rerun only the tests that failed. $pyt --rerun Things to be aware of ~~~~~~~~~~~~~~~~~~~~~ pyt uses Python’s PEP 8 style conventions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``pyt`` uses `Python’s code styling conventions `__ to decide what is the module and class, so, given input like this: $ pyt foo.bar.Baz.che ``pyt`` will consider ``foo.bar`` to be the module, ``Baz`` to be a class (because it starts with a capital letter), and ``che`` to be a method (since it comes after the class). Likewise, ``pyt`` uses unittest conventions, so a test module should end with ``_test`` (eg, ``foo.bar_test``) or start with test (eg, ``test_foo.py``) and a TestCase class should extend ``unittest.TestCase``, and test methods should start with ``test_`` (eg, ``test_che``). Vague input can cause pyt to run more tests than you expect ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So if you have something like this: project/ __init__.py user.py foo/ __init__.py user.py tests/ __init__.py user_test.py foo/ __init__.py user_test.py And you want to run tests for ``foo.user`` and you run: $ pyt user it will run both ``tests/user_test`` and ``tests.foo.user_test``, the solution is to just be more verbose when you have to be: $ pyt foo.user Environment Variables ^^^^^^^^^^^^^^^^^^^^^ If you are running the tests within pyt, you might notice there is an environment variable ``PYT_TEST_COUNT`` that contains the count of how many tests pyt found to run. %package help Summary: Development documents and examples for pyt Provides: python3-pyt-doc %description help Pyt is a lightweight wrapper around `Python’s unittest module `__ that adds some nice features and enhancements over the stock ``unittest`` module. Quickstart ~~~~~~~~~~ Pyt overrides unittest’s built-in pathfinding to be smarter and less verbose, so you can match tests using prefix matching which makes running a test like: $ python -m unittest tests.foo_test.BarTestCase.test_che as simple as: $ pyt foo.Bar.che But it’s even less verbose if you want it to be, pyt can reach into the modules and classes to do its matching, so you don’t even need to specify the module and class if you don’t want to: $ pyt che More examples ^^^^^^^^^^^^^ To run all the ``Happy`` tests: $ pyt Happy To run all the ``newmodule`` tests: $ pyt newmodule To run more than one test: $ pyt test1 test2 ... To run every test ``pyt`` can find: $ pyt And the way I like to run all tests in the current directory: $ pyt -vb Which can also be written: $ pyt --verbose --buffer Flags ~~~~~ To see everything pyt can do $ pyt --help –warnings ^^^^^^^^^ This will convert warnings into errors. $ pyt --warnings –rerun ^^^^^^ If your last testrun had failing tests this will rerun only the tests that failed. $pyt --rerun Things to be aware of ~~~~~~~~~~~~~~~~~~~~~ pyt uses Python’s PEP 8 style conventions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``pyt`` uses `Python’s code styling conventions `__ to decide what is the module and class, so, given input like this: $ pyt foo.bar.Baz.che ``pyt`` will consider ``foo.bar`` to be the module, ``Baz`` to be a class (because it starts with a capital letter), and ``che`` to be a method (since it comes after the class). Likewise, ``pyt`` uses unittest conventions, so a test module should end with ``_test`` (eg, ``foo.bar_test``) or start with test (eg, ``test_foo.py``) and a TestCase class should extend ``unittest.TestCase``, and test methods should start with ``test_`` (eg, ``test_che``). Vague input can cause pyt to run more tests than you expect ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So if you have something like this: project/ __init__.py user.py foo/ __init__.py user.py tests/ __init__.py user_test.py foo/ __init__.py user_test.py And you want to run tests for ``foo.user`` and you run: $ pyt user it will run both ``tests/user_test`` and ``tests.foo.user_test``, the solution is to just be more verbose when you have to be: $ pyt foo.user Environment Variables ^^^^^^^^^^^^^^^^^^^^^ If you are running the tests within pyt, you might notice there is an environment variable ``PYT_TEST_COUNT`` that contains the count of how many tests pyt found to run. %prep %autosetup -n pyt-1.0.5 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-pyt -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Fri May 05 2023 Python_Bot - 1.0.5-1 - Package Spec generated