Hmm... This might be the problem then, the doctest results that do not get loaded are returned as "Content-Type application/xml" whereas the other tests are "Content-Type text/html; charset=utf-8". Since the returned html isn't a well formed xml, I am getting this error. Do you have an idea why the content type might be set incorrectly?
On Jun 30, 11:37 pm, mdipierro <[email protected]> wrote: > The test controller generates "<h2>....</h2> and that is a piece of > html received via ajax, not xml. It should be valid. > > On 30 Giu, 15:25, Kerem Eryýlmaz <[email protected]> wrote: > > > I ran the admin application's test page for my controller > > (i.e.http://127.0.0.1:8000/admin/default/test/std/etc.py) through firebug, > > and it looks like it is an issue with the xml produced by web2py. The > > parser fails and the page is never updated (i.e. keeps flashing > > "please wait") but the response is received. > > > Error reads: > > > XML Parsing Error: junk after document element Location: moz- > > nullprincipal:{2bf026d5-ea46-4b0a-9bdd-21128033bf26} Line Number 1, > > Column 47: > > > <h2>Testing controller "etc.py" ... done.</h2><br/> > > ----------------------------------------------^ > > > Here is the problem, ./gluon/compileapp.py, lines 55-56: > > > html = '<h2>Testing controller "%s.py" ... done.</h2><br/>\n' \ > > % request.controller > > > I think starting with <h2> as the root element is the cause. > > > So really, no one else? > > > On Jun 30, 9:26 pm, Kerem Eryýlmaz <[email protected]> wrote: > > > > Hi all, > > > I wonder if anyone encountered similar problems with doctests. I have > > > a couple of controllers (default.py and etc.py), and a single function > > > (__addTLI__) in etc.py that has a doctest. When I try to run the tests > > > through the admin app, default.py passes fine (since it has no tests), > > > but etc.py just hangs. I have confirmed that there is a line in my > > > code that determines whether etc.py will hang or return successfully, > > > however I do not see how it is possible that the specific piece of > > > code determines anything (basically it produces an xml file through > > > some db interaction). I tried the same testing code in a function, > > > opened it up on a browser and it ran fine, error-free. I also > > > checkedhttp://127.0.0.1:8000/std/etc/_TESTforrawtest data, but it also > > > surprisingly revealed that __addTLI__ had actually passed. > > > > Is it possible for a test to hang even though all subtests pass? > > > > BTW, I use version 1.79.2 > > > > Cheers, > > > Kerem. > >
