Repository navigation
list duplicate test names with patchcheck #60283
Description
Activity
See also bpo-16056 for the current list of duplicate test names in
the std lib.The attached patch improves patchcheck.py to list duplicate test
names when running 'make patchcheck'. This patch to the default
branch can also be applied asis to the 2.7 branch.An example of patchcheck output with the patch applied:
==================
$ make patchcheck ./python ./Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... 1 file Fixing whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Duplicate test names ... 1 test: TestErrorHandling.test_get_only in file Lib/test/test_heapq.py Docs modified ... NO Misc/ACKS updated ... NO Misc/NEWS updated ... NO configure regenerated ... not needed pyconfig.h.in regenerated ... not needed
Did you run the test suite?
==================
- addedtype-featureA feature request or enhancementA feature request or enhancementstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Sep 28, 2012 Nice feature to do without adding a dependency on a lint tool!
I would like to see this written in a way that would let one run it globally or on a single file independent of a patch (e.g. an independent script from which patchcheck could import certain functions). Or is that what you explicitly didn't want Éric? :)
This would let one do a report or global check as was done for bpo-16056. It would also make it a bit easier to check manually that the script is checking for duplicates correctly.
Also, some suggestions:
+def testmethod_names(code, name=[]):
It might be clearer to use the name=None form.
+ test_files = [fn for fn in python_files if
+ fn.startswith(os.path.join('Lib', 'test'))]Are you getting the test files in test/ subdirectories of subpackages? I think checking that the file name starts with "test_" might be sufficient to get all test files.
+ if name[-1].startswith('test_'):
I believe 'test' is the prefix that unittest uses. I'm pretty sure we have some tests that don't start with 'test_'.
I would like to see this written in a way that would let one
run it globally or on a single file independent of a patch+1
It can be added to Tools/scripts and imported by patchcheck.I'm pretty sure we have some tests that don't start with 'test_'.
IIRC those are just test helpers that are not executed directly.
OTOH I don't see why looking for test_*, every py file might contain duplicate names so they should all be checked.Here are a couple examples of test method names that don't begin with "test_":
def testLoadTk(self): def testLoadTkFailure(self):
http://hg.python.org/cpython/file/f1094697d7dc/Lib/tkinter/test/test_tkinter/test_loadtk.py#l9
sqlite3 tests use CheckThing style (urgh).
Reacted by Erlend E. AaslandHere are a couple examples of test method names that don't begin with "test_":
I thought you were talking about test files. I still don't see why looking for test_* methods, every class might contain duplicate method names, so they should all be checked.
I thought you were talking about test files.
Oh, I see why you said that then. To find the test files themselves, this logic was used in the patch:
+ fn.startswith(os.path.join('Lib', 'test'))]
Regarding your question for the general case, I'm not sure if there is ever a use case for duplicate method names. Is there?
Note that using the module code object to find duplicates does not
allow for selecting among the different code types: function, nested
function, method or class.Duplicates are extensively used within the std lib:
Running find_duplicate_test_names.py, the initial script from issue
16056, on the whole std lib instead of just Lib/test, after updating
the script to list all the duplicates (except <lambda>, <genexp>,
...) with:if not name[-1].startswith('<'): yield '.'.join(name)
prints 347 (on a total of 1368 std lib .py files) duplicate
functions, methods or classes.To eliminate module level functions (but not nested functions), the
script is run now with the following change:if len(name) > 2 and not name[-1].startswith('<'): yield '.'.join(name)
and lists 188 duplicate nested functions, methods or classes. In
this list there are 131 duplicates in .py files located in the
subdirectory of a "test" directory.Using the python class browser (pyclbr.py) in conjunction with the
search for duplicates in the module code object would allow to
restrict the listing of duplicates to functions and methods or even
just to methods (depending on the feature requirements), without
listing the duplicate classes and duplicate nested functions. With
an associated performance cost.It doesn't necessary have to be limited to methods, anything duplicate might turn out to be a bug. If the script doesn't mix scopes there shouldn't be too many false positives, and if they are it shouldn't be a big deal if they are reported on the changed file by
make patchcheck.I'm not sure if there is ever a use case for duplicate
method names. Is there?Nothing that can't be done in a more elegant way afaict.
It might make sense for variables though, where you have e.g.:
foo = do_something(x) foo = do_something_more(foo)
I'm not sure if there is ever a use case for duplicate method
names. Is there?property getter, setter, and deleter methods do have the same name.
Here are a couple examples of test method names that don't begin
with "test_":def testLoadTk(self): def testLoadTkFailure(self):Also Lib/test/test_smtplib.py test method names start with 'test'
instead of 'test_' although the 'Regression tests package for Python'
documentation states: "The test methods in the test module should
start with test_".27 remaining items
Superseded by python/core-workflow#505
Isn’t that repo for tooling and meta issues?
IMO this should stay in the CPython tracker for visibility.
Isn’t that repo for tooling and meta issues?
Yes, and CI issues. Most relevant comments in this thread are about running these checks in CI. So it belongs in the core-workflow repo.
Oh, in my opinion the tool / config should be available for devs to run locally first, then also run from CI!
That’s why I see this as a normal CPython ticket.Ok, I reopen the ticket.
- added a commit that references this issue
on Sep 12, 2023
duplicate_meth_defs.pytool as a pre-commit check on Travis (GH-12886) #12950Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs