On Sun, May 30, 2010 at 6:19 PM, Wyatt Baldwin <[email protected]> wrote: > On May 30, 5: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. > > Well, that's, like, your opinion, man, but I happen to think > differently. The way that it might be helpful is that when you run > unit tests against your business logic,
Different people define "business logic" more widely than others, and I think the individual application also plays a role. Complex applications, or cases where multiple applications share some code or data, are examples. I define business logic as the same as the model, plus whatever extra code is in lib or in shared modules. I generally don't use 'config' or any of the magic globals in these places. That's partly because I've had to port a lot of code from one framework to another over the years, and it's easier if the business logic doesn't have framework-dependent parts. So my model never depends on other parts of Pylons, so that it can be imported standalone for utilities (maintenance scripts or cron jobs). Of course, the top-level script has to initialize the model with an engine. For things like a second database connection for a shared module (e.g., a stats database), or a search index or such, I put under 'app_globals' for the controllers/templates, but I also try to make it not dependent on 'app_globals' for testing. I haven't figured out a way to do comprehensive testing within the Pylons structure. For instance, how to hide tests that should only be run on special occasions, or multiple levels of "unit" tests. I find myself declaring everything in a TestController even if it's a unit test, in order to have convenient access to the config. Sometimes I recast my tests as standalone scripts to hide them from the regular "nosetests". And 'websetup' is not really flexible enough to deal with all the data situations you might want to test against -- while remaining compatible with its primary role of setting up the databases initially. So I'm not really satisfied with the existing test infrastructure, but I haven't found anything better either. (Although 'twill' works great to quickly test a few URLs.) >> 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.) As Ben said, SOPless usage is coming, and I keep bugging him about it. In frameworks in general, there are three general ways to access the request's context. One is via a 'request' argument or 'self' attributes. Quixote 1 had a request argument, while Quixote 2 has global functions (get_request(), get_response(), get_publisher() [the framework object]). CherryPy prefers threadlocal globals, which are a precursor to Pylons' StackedObjectProxies. They are convenient, but they're also magical, and it ties your code to the framework if you use them everywhere (including in lib functions and the model). -- 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.
