On Mon, Jul 7, 2008 at 3:29 PM, Wichert Akkerman <[EMAIL PROTECTED]> wrote: > > Previously Mike Orr wrote: >> >> On Mon, Jul 7, 2008 at 2:10 PM, Jonathan Vanasco <[EMAIL PROTECTED]> wrote: >> > >> > >> > On Jul 7, 4:53 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote: >> >> True. I'm just saying if you can code to avoid 'g' and 'c' in your >> >> lib routines, so much the better. I have never found a use for 'g', >> >> except in one case to put a structure of static data that's parsed on >> >> app startup (or read from a cache pickle). >> > >> > That is *exactly* what I use g for -- stashing 'static' data ( the >> > names and ids of 'options' that the database fkeys on . example: >> > >> > query= "select * from _gender" >> > for row in rows: >> > g.gender.id[ row.id ]= row.name >> > g.gender.name[ row.name ]= row.id >> > >> > i also have some other misc. config data -- like amazon s3 urls, etc >> > - which are initialized on startup based out of config values. >> > >> > i'm a little less-than-enthusiastic by the built in testing with >> > Pylons. not having g,c,session is annoying. >> >> You're not initializing the application completely and you're >> wondering why it isn't working? Don't you see the contradiction >> there? >> >> > i've also noticed that >> > for every test it does a full app initialization - which means ( in my >> > case ) querying the database for 50 tables worth of data. >> >> Unit tests always do that: setUp creates a full test environment, >> which is discarded after each test. > > Can we please make sure our test terminology is correct? A unit test > will never do that since it tests as little code as possible in an > isolated environment, preferably using mock objects. > > Integration tests however do setup the whole application.
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. That way the low-level routines are decoupled from the rest of Pylons, so they can be used and tested separately. That's the same reason I added model.init_model() to the SQLAlchemy template, so that the model could be used without depending on the rest of Pylons. There's some differences of opinion on where request/response/g/c/session/cache should properly be used, but by limiting them to the controller and template as I usually do, it eliminates unnecessary dependencies between the low-level routines and the full Pylons environment. This makes it easer to test the routine code itself without interference from the environment. Thus "def a(important_value):" instead of "def a(): important_value = g.important_value". Obviously there will be some applications where this doesn't work, where you need something available globally and 'g' is the only reasonable place to put it. In that case those tests will need the full environment loaded. Either that or you completely restructure Pylons to eliminate 'g' and replace it with something else that's more test-friendly. Or maybe there's a way to build a test structure that loads a Pylons environment once and uses it for several tests. 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. 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. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
