Stefan Sullivan <stefan.sulli...@smule.com> added the comment:
This seems like it directly contradicts the documentation for the discover method: "If a package (a directory containing a file named __init__.py) is found, the package will be checked for a load_tests function. If this exists then it will be called package.load_tests(loader, tests, pattern)." I believe this _is_ a functional bug. I have a use case where I have provided a root script with contents along the lines of for d in includes: test_dir = os.path.join(search_dir, d) if test_dir not in excludes: test_suite.addTests(test_loader.discover(test_dir, '*.py', search_dir)) and a load_tests function in one of those directory's __init__.py. However, since test discovery does not pass on the pattern, I cannot possibly discover what the pattern should have been. Furthermore, if I instead invoke test discovery on the command line using: python -m unittest discover -s /path/to/code -t /path/to/code -p *.py I again will see a load_tests invoked with pattern=None. What is the situation where load_tests will be invoked with a non-None pattern? Is there a workaround for how I'm supposed to get this pattern? Is there a convention or design pattern where I'm supposed to return everything and let the caller filter out the extra tests? As far as I can tell, the load_tests protocol is only relevant to packages (not modules) by virtue of its placement in the __init__.py file. However, the only way to load tests from a package is via discover, because there is no loadTestsFromPackage method (like there is for loadTestsFromModule). Have I misunderstood the load_tests protocol? Is there some special way to get a pattern? I feel that if the user really wanted to use their own pattern, being passed a string won't hurt anything, but converse is not true (at least for my use case) ---------- nosy: +Stefan Sullivan _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue11218> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com