On Jul 7, 6:58 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> That's my point. Unit tests should not be testing things that use
> 'g'. Low-level routines should not use 'g'. Only at the higher
> integration layer (e.g., controllers) should 'g' get involved.
Let me rephrase this:
having this code in my Pylons app causes me lots of errors and
failures
class Form_Register(_Schema_Base):
email = formencode.validators.Email(not_empty=True)
us_state=
formencode.validators.OneOf( g.us_states.keys(),hideList=True)
I'm not testing g or accessing it during the test. I'm just having
the misfortune of referencing g in a module.
On Jul 7, 6:58 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> However, the reason the environment is normally recreated for every
> test is to prevent changes made by one test from leaking into another
> test, which invalidates the test.
I understand that, and to Wichert's point, I'm trying to do both unit
testing and integration testing. So I apologize for the mistake in
words.
> Putting database lookup values into 'g' was an idea I had not thought
> of. When I've come across that situation, I put a function in the
> model that returned or updated a cache dict (module global). It is
> assumed this function will be valid only if init_model() has been
> called. Of course it will fail with a predictable "no database engine
> available" error if this is not the case. Now, this structure is safe
> if the data does not vary across application instances coexisisting in
> the same process, and is ideal if it's read-only. If the data does
> vary across application instances, you'll have to put it on 'g'
> because that's what 'g' is for -- as a safe place to put
> application-instance-specific data.
That could work - but at the expense of needless code.
I need these constants when:
- displaying a form
- validating a form
- validating API or other values
- printing information to the end user
doing a model call every time would work - but at the expense of
repetitive queries. for all intents , this data are static and a
dict.
i think the best solution right now is to stick this all in some
package namespace, then use middleware or something to populate G
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
