test_controllers fail in TG 1.0.1
Chris Miles
the controller tests do not pass out of the box.
----
$ tg-admin quickstart --sqlalchemy --identity temp3
$ cd temp3
$ nosetests -v
temp3.tests.test_controllers.test_method ... Registering Service
temp3: development._http._tcp port 8080 path=/
ok
temp3.tests.test_controllers.test_indextitle ... FAIL
temp3.tests.test_controllers.test_logintitle ... FAIL
======================================================================
FAIL: /Users/chris/src/Python/TurboGears/temp3/temp3:
temp3.tests.test_controllers.test_indextitle
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/nose-0.9.2-py2.4.egg/nose/case.py", line 52,
in runTest
self.testFunc()
File "/Users/chris/src/Python/TurboGears/temp3/temp3/temp3/tests/
test_controllers.py", line 26, in test_indextitle
assert "<TITLE>Welcome to TurboGears</TITLE>" in
cherrypy.response.body[0]
AssertionError
======================================================================
FAIL: /Users/chris/src/Python/TurboGears/temp3/temp3:
temp3.tests.test_controllers.test_logintitle
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/nose-0.9.2-py2.4.egg/nose/case.py", line 52,
in runTest
self.testFunc()
File "/Users/chris/src/Python/TurboGears/temp3/temp3/temp3/tests/
test_controllers.py", line 32, in test_logintitle
assert "<TITLE>Login</TITLE>" in cherrypy.response.body[0]
AssertionError
----------------------------------------------------------------------
Ran 3 tests in 1.090s
FAILED (failures=2)
----
At first glance it looked like a case mis-match with the "<TITLE>"
assertion, but even changing these to be case-insensitive matches
doesn't help.
Examining the response body within the test shows it is receiving a
500 error, containing the following exception:
----
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/
_cphttptools.py", line 103, in _run
applyFilters('before_main')
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/filters/
__init__.py", line 151, in applyFilters
method()
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/TurboGears-1.0.1-py2.4.egg/turbogears/visit/
api.py", line 157, in before_main
plugin.record_request( visit )
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/TurboGears-1.0.1-py2.4.egg/turbogears/identity/
visitor.py", line 173, in record_request
set_current_identity( identity )
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/TurboGears-1.0.1-py2.4.egg/turbogears/identity/
__init__.py", line 105, in set_current_identity
cherrypy.request.user_name = identity.user_name
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/TurboGears-1.0.1-py2.4.egg/turbogears/identity/
saprovider.py", line 50, in _get_user_name
if not self.user:
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/TurboGears-1.0.1-py2.4.egg/turbogears/identity/
saprovider.py", line 41, in _get_user
visit = session.query(visit_class).get_by(visit_key =
self.visit_key)
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/orm/query.py", line
93, in get_by
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/orm/query.py", line
252, in select_whereclause
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/orm/query.py", line
378, in _select_statement
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/orm/query.py", line
308, in execute
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/orm/session.py",
line 133, in execute
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/engine/base.py",
line 258, in execute
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/engine/base.py",
line 282, in execute_clauseelement
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/engine/base.py",
line 298, in execute_compiled
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/engine/base.py",
line 294, in proxy
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/engine/base.py",
line 332, in _execute_raw
File "build/bdist.macosx-10.3-fat/egg/sqlalchemy/engine/base.py",
line 351, in _execute
SQLError: (OperationalError) no such table: visit_identity 'SELECT
visit_identity.visit_key AS visit_identity_visit_key,
visit_identity.user_id AS visit_identity_user_id \nFROM visit_identity
\nWHERE visit_identity.visit_key = ? ORDER BY visit_identity.oid \n
LIMIT 1 OFFSET 0' ['e0954d1a422360159196191cfd21ecc0ebe9956e']
----
It looks like visit_identity table wasn't created. But the mechanics
of testutil and how to startup TurboGears properly are beyond me, so
any tips appreciated.
Cheers,
Chris
Florent Aide
[...]
> It looks like visit_identity table wasn't created. But the mechanics
> of testutil and how to startup TurboGears properly are beyond me, so
> any tips appreciated.
please try:
tg-admin sql create
it should create the tables defined in your model. (in your case
identity is present in the model)
regards,
Florent.
Chris Miles
On Feb 6, 10:33 pm, "Florent Aide" <florent.a...@gmail.com> wrote:
> > It looks like visit_identity table wasn't created. But the mechanics
> > of testutil and how to startup TurboGears properly are beyond me, so
> > any tips appreciated.
>
> please try:
>
> tg-admin sql create
>
> it should create the tables defined in your model. (in your case
> identity is present in the model)
Thanks Florent, but it didn't help the tests. And I wouldn't have
expected it to as the tests should be working on a temporary DB held
in memory right? Shouldn't testutil be creating the tables as it runs
the tests ?
btw, test.cfg contains the default line:
sqlalchemy.dburi = "sqlite:///:memory:"
Cheers,
Chris
Florent Aide
> sqlalchemy.dburi = "sqlite:///:memory:"
Yes.
There are a few tickets about failing tests in the trac. and one is
about identity and sqlalchemy:
http://trac.turbogears.org/ticket/1101
maybe this is the same as yours ?
regards,
Florent.
Chris Miles
On Feb 6, 10:48 pm, "Florent Aide" <florent.a...@gmail.com> wrote:
> There are a few tickets about failing tests in the trac. and one is
> about identity and sqlalchemy:
>
> http://trac.turbogears.org/ticket/1101
>
> maybe this is the same as yours ?
Actually that ticket is for broken model tests when using SQLAlchemy.
I already tackled that and came up with a workaround, thanks to this
thread, http://groups.google.com/group/turbogears/browse_thread/thread/
a6bebf6c4bd37cdb
So now I've moved on to trying to test the controllers...
Cheers,
Chris
Christopher Arndt
SQLAlchemy.
> I already tackled that and came up with a workaround, thanks to this
> thread, http://groups.google.com/group/turbogears/browse_thread/thread/
> a6bebf6c4bd37cdb
Just out of curiosity: in that thread, you were still having problems in your
last post. What was the solution in the end? The error you were having was
indicating that the configuration was not loaded properly...
Chris
Chris Miles
On Feb 6, 11:39 pm, Christopher Arndt <chris.ar...@web.de> wrote:
> Chris Miles schrieb:
> > Actually that ticket is for broken model tests when using
> SQLAlchemy.
>
> > I already tackled that and came up with a workaround, thanks to this
> > a6bebf6c4bd37cdb
>
> Just out of curiosity: in that thread, you were still having problems in your
> last post. What was the solution in the end? The error you were having was
> indicating that the configuration was not loaded properly...
I didn't actually participate in that thread, but I came across the
same problem. Your examples you paste'd are what I used to solve it.
Although, I'm still not sure that the model tests are working properly
yet. I am still investigating if the fault is mine or not.
I've had no luck getting the skeleton controller tests to work. Even
if I quickstart a project using default SQLObject instead.
Is it simply the case that the model and controller tests do not
support SQLAlchemy in TG 1.0.1? (or the tests are not supported at
all?) I was hoping to quickly test my new model tonight and move onto
creating the site itself, but have spent the whole night instead
trying to debug a broken test framework.
Cheers,
Chris
Christoph Zwerschke
> Is it simply the case that the model and controller tests do not
> support SQLAlchemy in TG 1.0.1? (or the tests are not supported at
> all?) I was hoping to quickly test my new model tonight and move onto
> creating the site itself, but have spent the whole night instead
> trying to debug a broken test framework.
There are two unrelated problems with the test.
One is that if you are using Kid >= 0.9.4, then tags are output as
lowercase so the tests will fail (even without SQLAlchemy). This has
been already patched in TG 1.0.1 for the actualy TurboGears tests, but
the controller tests for quickstarted projects have been forgotten. I
have just added this as ticket #1289.
The other problem is as far as I see that for SQLAlchemy, the identity
model tables are not created automatically. Note that SQLAlchemy is not
officially supported for 1.0.1 so you should not be amazed that things
can break here.
-- Christoph
gasolin
> ======================================================================
> FAIL: /Users/chris/src/Python/TurboGears/temp3/temp3:
> temp3.tests.test_controllers.test_indextitle
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/nose-0.9.2-py2.4.egg/nose/case.py", line 52,
> in runTest
> self.testFunc()
> File "/Users/chris/src/Python/TurboGears/temp3/temp3/temp3/tests/
> test_controllers.py", line 26, in test_indextitle
> assert "<TITLE>Welcome to TurboGears</TITLE>" in
> cherrypy.response.body[0]
> AssertionError
>
This is because since kid 0.9.4 they change the default generated tags
to lower case.
try assert "<title>Welcome to TurboGears</title>" instead.
Christoph Zwerschke
>> File "/Users/chris/src/Python/TurboGears/temp3/temp3/temp3/tests/
>> test_controllers.py", line 26, in test_indextitle
>> assert "<TITLE>Welcome to TurboGears</TITLE>" in
>> cherrypy.response.body[0]
>> AssertionError
>
> This is because since kid 0.9.4 they change the default generated tags
> to lower case.
>
> try assert "<title>Welcome to TurboGears</title>" instead.
As Chris M. already wrote, this does not help here since it is indeed a
problem with SQLAlchemy. The test fails because with SQLAlchemy, the
necessary visit/identity tables are not created automatically, as it is
the case with SQLObject. I have submitted patches #1289 and #1290 for
fixing both of these problems.
-- Chris Z.
gasolin
> As Chris M. already wrote, this does not help here since it is indeed a
> problem with SQLAlchemy. The test fails because with SQLAlchemy, the
> necessary visit/identity tables are not created automatically, as it is
> the case with SQLObject. I have submitted patches #1289 and #1290 for
> fixing both of these problems.
>
#1289 and #1290 are fixed in 1.0.x and trunk, thanks!
gasolin
Can someone help us to confirm that does http://trac.turbogears.org/
ticket/1255
relate to this issue?
--
Fred
Chris Miles
On Feb 7, 2:33 am, Christoph Zwerschke <c...@online.de> wrote:
> The other problem is as far as I see that for SQLAlchemy, the identity
> model tables are not created automatically. Note that SQLAlchemy is not
> officially supported for 1.0.1 so you should not be amazed that things
> can break here.
Ok, I wasn't sure if SQLAlchemy was officially supported or not in
1.0.1 (although I suspected not) so that is good to know. I'll be
happier (relatively) to accept more breakages when using SA and help
fix them if I can.
Thanks for fixing the bugs I mentioned in the 1.0.x branch. I am
going to check that out and try it instead of 1.0.1.
Cheers
CM
Chris Miles
On Feb 7, 7:13 am, "gasolin" <gaso...@gmail.com> wrote:
> Can someone help us to confirm that does http://trac.turbogears.org/
> ticket/1255
> relate to this issue?
#1255 doesn't look like it is related to this issue that I mentioned
above.
These ones do, however: #1289 and #1290
Cheers,
CM
Chris Miles
On Feb 7, 12:09 pm, "Chris Miles" <miles.ch...@gmail.com> wrote:
> These ones do, however: #1289 and #1290
Tried again with a checkout of 1.0.x branch (r2559) which incorporated
the above fixes.
Two of the controller tests now pass, but one still fails. The failed
response contains a 500 error with the following exception:
----
<pre id="traceback">traceback (most recent call last):
file "/library/frameworks/python.framework/versions/2.4/lib/
python2.4/site-packages/cherrypy-2.2.1-py2.4.egg/cherrypy/
_cphttptools.py", line 103, in _run
applyfilters('before_main')
file "/library/frameworks/python.framework/versions/2.4/lib/
python2.4/site-packages/cherrypy-2.2.1-py2.4.egg/cherrypy/filters/
__init__.py", line 151, in applyfilters
method()
file "/library/frameworks/python.framework/versions/2.4/lib/
python2.4/site-packages/turbogears-1.0.2dev_r2559-py2.4.egg/turbogears/
visit/api.py", line 147, in before_main
visit= _manager.new_visit_with_key( visit_key )
attributeerror: 'nonetype' object has no attribute
'new_visit_with_key'
</pre>
----
The problem now, as I see it, is that as a test completes it calls
teardown_func() to stop TurboGears. i.e.:
----
test_indextitle = with_setup(teardown=teardown_func)(test_indextitle)
----
This clears the visit manager which is not re-initialised for the next
test.
I can make all controller tests pass by removing the
"teardown=teardown_func" option from the with_setup() calls. However,
I don't know if removing the teardown_func has any other negative
effects on tests.
If this fix is acceptable, I can create a ticket containing a patch
for this to apply to the 1.0 branch, if it would help.
Cheers,
CM
gasolin
> The problem now, as I see it, is that as a test completes it calls
> teardown_func() to stop TurboGears. i.e.:
> ----
> test_indextitle = with_setup(teardown=teardown_func)(test_indextitle)
> ----
>
> This clears the visit manager which is not re-initialised for the next
> test.
>
> I can make all controller tests pass by removing the
> "teardown=teardown_func" option from the with_setup() calls. However,
> I don't know if removing the teardown_func has any other negative
> effects on tests.
>
> If this fix is acceptable, I can create a ticket containing a patch
> for this to apply to the 1.0 branch, if it would help.
>
Yeah, you should create a ticket so other developers (who are more
familiar with this issue) could see it :)
Christoph Zwerschke
> Two of the controller tests now pass, but one still fails. The failed
> response contains a 500 error with the following exception:
On my machine both tests pass. But this can be a timing issue.
> The problem now, as I see it, is that as a test completes it calls
> teardown_func() to stop TurboGears. i.e.:
> ...
> I can make all controller tests pass by removing the
> "teardown=teardown_func" option from the with_setup() calls. However,
> I don't know if removing the teardown_func has any other negative
> effects on tests.
> ...
> If this fix is acceptable, I can create a ticket containing a patch
> for this to apply to the 1.0 branch, if it would help.
The reason for the teardown function is explained here:
http://trac.turbogears.org/ticket/1217
But I believe http://trac.turbogears.org/ticket/1236
has already solved this problem more fundamentally so that the
workaround with the teardown function is not necessary any more.
So yes, please file a ticket for removing this.
-- Christoph