When I started using Pylons I liked those "special" globals. There are various engineering objections to having them, but its hard to argue against their great utility. Coming from Ruby on Rails background, I absolutely loved that I didn't need to reverse-engineer the framework to find out where my configuration goes (or carry it around via parameters everywhere). Lets not forget that in the end we all need to get things done and "engineering elegance" shouldn't be in the way. Attaching configuration to app/request/response stands in the way. I don't have app/request/response in my tests. Why would I?
Besides, I find those things (request/response) to be a secondary concern. I like to start every project as a simple console/ncurses app with full test coverage. Request/response and other UI is just a last minute snap-on, so I don't like bending my test code over to carry around UI-specific objects. "pylons.config" is vastly superior. Just my $0.02 -- ev On Sun, May 30, 2010 at 8:43 PM, Hans Lellelid <[email protected]> wrote: > On May 30, 5:40 pm, Wyatt Baldwin <[email protected]> wrote: > > On May 30, 2:31 pm, Eugueny Kontsevoy <[email protected]> wrote: > > > > > They work, but we needed to have our existing 0.9.7 Pylons applications > to > > > work and they don't access config objects via TestResponse. In fact 90% > of > > > our tests are units, i.e. they don't issue request/response, they just > do > > > "from pylons import config" and test business logic in isolation from > > > request/response machinery. > > > > Going a little off-topic here, but in my view, business logic > > generally shouldn't rely on Web app configuration. > > That's both unhelpful to the discussion and nonsensical. In practice > "business logic" can easily depend on configurable parameters. E.g. > I'd like a test to ensure my account gets locked out after X failed > login attempts. X is configurable. > > I've griped about this before, but I think the biggest (only?) problem > that comes up repeatedly for us w/ Pylons is the inaccessibility of > these "special" globals from tests (without using response/request > objects). Stacked object proxies. I dream of a day (or a fork) when > these are either a thing of the past, or disabled by default. (Mike > has given me some pointers in the past, but I still maintain that > writing tests shouldn't be so hard. -- and one shouldn't be forced to > use the WebTest framework, which IMO is inadequate for services > applications.) > > Hans > > -- > 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]<pylons-discuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- 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.
