Terry J. Reedy added the comment:
Ezio, thank you for the response.
1. I care more about where the directory of tests is than what it is called.
'idle_test' or 'idletest' or whatever would be fine. Lets make that the last
bikeshed item ;-).
2. I looked as #10572. It was originally about moving unittest tests from
unittest/xx to test/yy, and then broadened to other packages. Michael F. gave
two reasons for the move.
2A. Easier to grep without recursing into the test directory. Barry already
refuted this, pointing out that grep/find have options to not recurse. The Idle
equivalent, Find in Files, has a little checkbox
[] Recurse down subdirectories.
I think Michael had this point backwards. The advantage of having tests with
the code is to make grepping both at once possible. I am sure I will want to do
this while developing the tests. So add this to my list of reasons to put the
directory under idlelib.
2B. Would honor the Windows Install without Tests option. This is strictly a
matter of saving space by disabling function. I agree that this is appropriate
for nearly all packages, but I already explained why I want to evade that
option: tkinter and idle are exceptional in that they are the only two packages
that people regularly have problems running. So I think people should have
those tests available, even if none of the others.
2 (again). Other people opined that package maintainers should have some say in
the matter and that there might be exceptions.
3. Many modules have more or useless 'sanity-check' tests run with the 'if
__name__' mechanism. I think *all* of these should be replaced with
unittest.main(xxx, verbosity=2, exit=False) to run the full test module. If the
code module test has anything valuable that is not in the test module, it
should be moved there; the rest should be deleted.
I plan to eventually do this with all such 'tests' in idlelib/*.py. However,
this needs to be done one by one. Some current tests have program errors; my
'file' to 'open' patch last week was the first fix. Some put up a blank window,
with no indication of what a person is expected to do to perform the test. Some
put up a window that will not close by normal means. All except the two in
idletasks.diff require human intervention, which is not acceptible for
buildbots. Question: is there a way for a test to detect being run by a
buildbot?
4. I already used @template.txt to alter CallTips.py and start test_calltips.py
and I want to use it for all the other 60 (or whatever) test files. I will
(re)read the test-writing section and possibly suggest a patch. But
Idle-specific info and code does not belong there.
(5.) unittest.SkipTest is what I was looking for. I do not believe that
support.import_module() will allow skipping if, or unless, the test is running
on a specific platform. I need to look at #16935.
Is Idle CPython only? If so, that should be a condition of test/test_idle.py
running. Ah, testing the imports of tkinter and idlelib already takes care of
that.
(6.) My concern and possible confusion about raising exceptions came from
Jayakrishnan's patch
+ def test_DirBrowserTreeItem(self):
+ # Issue16226 - make sure that getting a sublist works
+ d = PathBrowser.DirBrowserTreeItem('')
+ d.GetSubList()
in relation to the doc saying "Note that in order to test something, we use one
of the assert*() methods provided by the TestCase base class." There is no such
method. The doc follows with "If the test fails, an exception will be raised,
and unittest will identify the test case as a failure. Any other exceptions
will be treated as errors." The 'test above is to raise, or not, an 'other
exception' and I took 'treated as errors' to mean that raising an 'other
exception' is an error. It certainly makes test failure counted as an error
rather than an error and indistinguishable from test code errors. I guess when
the test is fleshed out, there should and will be some assert about the result
of d.getsublist(). So I could delete the try-except.
(7.) A human-intervention resource. I will leave that for later.
My next step after this one is moving tests from CallTips.py to the new
test_calltips.py (3. above).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15392>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
