On Mon, Jun 25, 2012 at 7:12 AM, Robert Rothenberg <[email protected]> wrote:
> > > > > Do you really need the context? > > Yes. > Are there times when you may wish to use your DBIC classes outside of Catalyst and still need access control? Even for cron jobs when we run them we need to set the "actor" so that the DBIC model code can determine if that actor is allowed to do that action. All our access controls are relationships in the database. > It's much more complex to set up and change a mock object, and have to > worry > about whether it's set up correctly, than to log in as a particular user > and > do actions that the user would normally do, and test how that affects the > user's access permissions. > I don't see that Test::WWW::Mechanize::Catalyst has a way to run ctx_request() from Catalyst::Test, but looks like a pretty easy hack. I've used another trick with testing where I inject a controller into the app only when running tests where it was much easier to run the tests in an acton. It's pretty rare that I need to test the context directly instead of the behavior of the app. I get run a test as different users and look for the 403 or 200 responses. But, your problem is if you want to then access the database directly from your script you need the context -- or something that satisfies the need of your DBIC code. What about creating a new class with required attributes you need? Then build that object once per request and pass that in to your DBIC code instead of the context object. Then you can use that same class outside of Catalyst, as in your tests. I suspect others will agree that in the long run having that tight bindig between Catalyst and DBIC will be a mistake. -- Bill Moseley [email protected]
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
