homepage

As #15075 demonstrated, the ET tests are sensitive to execution order because of the way they operate.
Two sets of tests (one for the C module and one for the pure Python module) operate from the same test code, monkey-patching the imported module. This sometimes breaks. A more robust solution is needed that is completely deterministic and does not rely on import artifacts.

It should be noted that the doctests complicate things considerably, and should be rewritten to be unittest, which are easier to manipulate in terms of modules used.

New changeset f9d1d120c19e by Eli Bendersky in branch '3.3':
Issues #15083 and #16992: port find.* method tests to unittest
http://hg.python.org/cpython/rev/f9d1d120c19e
New changeset 18b16104166c by Eli Bendersky in branch 'default':
Issues #15083 and #16992: port find.* method tests to unittest
http://hg.python.org/cpython/rev/18b16104166c 

Here is a patch which converts all etree doctests to unittests.

Serhiy, thanks for working on this! I didn't read the whole patch yet - will tinker with it a bit more when applying. Did you prepare the patch vs. 3.3 or default? The two are still synced and I'd be happy to apply it to both branches.
Now, the real reason I wanted to get rid of doctests is to make the global environment clean in test_xml_etree. The next logical step is to make all test classes in test_xml_etree accept the ET module in some way and store it, using it to get classes & function. I.e. no more global "ET" and "pyET" at all. Would you like to add this to your patch?

This patch is for default branch. It applied to 3.3 too.
> The next logical step is to make all test classes in test_xml_etree accept the ET module in some way and store it, using it to get classes & function. I.e. no more global "ET" and "pyET" at all. Would you like to add this to your patch?
I was going to do this on the next step, but if you prefer I can prepare a single patch. But it seems to me that more simple patches are easier to review.

No problems. You can go ahead and commit this patch to 3.3 and default, then. I will review it post-commit, since I wanted to tweak some things around anyway.

New changeset af570205b978 by Serhiy Storchaka in branch '3.3':
Issue #15083: Convert ElementTree doctests to unittests.
http://hg.python.org/cpython/rev/af570205b978
New changeset 5eefc85b8be8 by Serhiy Storchaka in branch 'default':
Issue #15083: Convert ElementTree doctests to unittests.
http://hg.python.org/cpython/rev/5eefc85b8be8 

Great, thanks.
Now looking forward to the patch getting rid of the module-level globals. One idea is explicitly pass the module into each testing class. The classes should not rely on anything global in this respect.

> The next logical step is to make all test classes in test_xml_etree 
> accept the ET module in some way and store it, using it to get classes 
> & function. I.e. no more global "ET" and "pyET" at all.
The idiom suggested by PEP 399 has the two modules (cmod and pymod) as globals, and then simply sets them as class attributes. Is there any reason why this should be avoided in this case?

On Tue, Feb 26, 2013 at 8:08 PM, Ezio Melotti <report@bugs.python.org>wrote:
>
> Ezio Melotti added the comment:
>
> > The next logical step is to make all test classes in test_xml_etree
> > accept the ET module in some way and store it, using it to get classes
> > & function. I.e. no more global "ET" and "pyET" at all.
>
> The idiom suggested by PEP 399 has the two modules (cmod and pymod) as
> globals, and then simply sets them as class attributes. Is there any
> reason why this should be avoided in this case?
>
I'm just not sure how the globals help except for saving 2-3 lines of code.
I do see how they can cause problems because even when I just want to run
the pure Python code, the C module gets imported. Why should it be? I
really don't want it to, I want to isolate things as much as possible
(after all, testing the pure Python module actually tests a scenario where
there is no C module). Pickle is one concrete place that can cause problems
with this.
We talked about related things in Issue #15083 and AFAIR Eric's and Brett's
proposals move these modules away from the global namespace.

> I'm just not sure how the globals help 
It doesn't, but if it works fine there's probably no reason to complicate (if it's complicated at all) things to change this.
> even when I just want to run the pure Python code, the C module gets
> imported. Why should it be?
Doesn't the test always run both? (assuming the C module is available -- if it's not it won't be imported anyway)
> Pickle is one concrete place that can cause problems with this.
This might be an actual reason to avoid globals, but I don't know the details.

It is hard to backport bugfixes to 2.7 since tests are too different. Due to this I backported some bugfixes without tests and omitted backporting other bugfixes.
PR 906 converts doctests in 2.7 to unittests. This will help backporting bugfixes too much.
Actually I have backported tests from 3.5 and checked that all old tests are present in new tests. Perhaps I found a bug in ElementTree in 2.7. Will open an issue after merging tests.

New changeset 68903b656d4e1011525a46cbd1338c6cbab83d6d by Serhiy Storchaka in branch '2.7':
bpo-15083: Convert ElementTree doctests to unittests. (#906)
https://github.com/python/cpython/commit/68903b656d4e1011525a46cbd1338c6cbab83d6d