On Jul 7, 5:29 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> You're not initializing the application completely and you're
> wondering why it isn't working? Don't you see the contradiction
> there?
I'm questioning why its initializing for every test, and not 1x then
run all the tests in it.
> Unit tests always do that: setUp creates a full test environment,
> which is discarded after each test. Generally that's considered a
> good thing even if it's slow. Python apps have been testing this way
> since long before Pylons was created.
I don't have an issue with that ability of unit tests - but with the
way they're integrated into Pylons.
> If you have to read 50 tables
> worth of data, it's more a case that you have an unusual application
> structure than that Python's testing is screwed up. You may have to
> test this application by pre-reading the data at module level and
> putting it in place. (And if it's place is in pylons.g, maybe have
> some lightweight g-initialization routine that copies the variables
> from their test module locations. There's a module_setup function
> that may persist between tests, although I'm not sure.
It's a fairly normal application structure and design concept for web
projects-- preload all database constants on initialization. I'm not
saying that Python screwed up - I just said that I'm not into the way
testing was integrated into Pylons.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
