writing unit tests that cover pylons and pyramid

[Jonathan Vanasco]

my tests keep failing on pylons packages. actually, i can't even run
the tests.

i've traced the error to this being in my packages:

from pylons import c

works fine in production, but not in testing

looking at pylons/__init__.py, i see this line:

tmpl_context = c = StackedObjectProxy(name="tmpl_context or C")

i tried renaming the import and object from "c" to "tmpl_context" and
everything went fine

anyone have a suggestion on how to proceed?

1- leave as tmpl_context in the package
2- figure out why c doesn't seem to exist in the test environment

[Michael Merickel]

You might want to ensure both systems are running the same version of Pylons. I believe "c" is deprecated in 0.10 and removed entirely in 1.0 in favor of "tmpl_context".

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

[Jonathan Vanasco]

It's the same system & virtualenv. it's just that 'using' the package
seems to work fine, but testing it fails.

c is exported in pylons , but that double assignment line seems to not
define it via an import. i guess there's some pylons bootstrap code
that needs to be run.

in any event, based on your suggestion i've got the tests working like
this now:

try:
from pylons import c
except ImportError:
from pylons import tmpl_context as c

[Jonathan Vanasco]

actually, screw that. unit testing for a series of helper wrappers is
too difficult in pylons. pyramid and 'core' usage gets covered.
pylons doesn't. now i'm going to brunch!

[Mike Orr]

On Sat, Feb 11, 2012 at 11:54 AM, Jonathan Vanasco
<jona...@findmeon.com> wrote:
> actually, screw that. unit testing for a series of helper wrappers is
> too difficult in pylons.

Yes, I've come to that conclusion too. It's one of the main reasons
Pylons 2 switched to Pyramid. It's why I've long been saying that
magic globals are evil. They don't work in unit tests until the
environment has been set up sufficiently. Basically, they're
guaranteed only when your test class has been set up as a
"controller", which mimics a live request environment. The problems
usually occur when you try to use the globals in your setup code or at
module level -- most commonly 'config'. There are various hacks to
get the globals to work at that point, but the best answer is to use
Pyramid where testing is more straightforward and reliable.

--
Mike Orr <slugg...@gmail.com>