Thanks for the responses. Jason, you pointed me in the right direction...testing the view callables directly rather than after the rendering stage.
Cheers! On Fri, Aug 24, 2012 at 7:41 PM, Jason <[email protected]> wrote: > > > On Friday, August 24, 2012 6:09:48 AM UTC-4, lostdorje wrote: >> >> Hello all, >> >> A lot of the pyramid docs will have view callable examples similar to >> this to the toy code I've provided below. (I'm using traversal which means >> I am given a context object, but using url dispatch is similar). >> >> class UserView(BaseLayout): >> @view_config(context='model.user.User', renderer='template/user.pt >> ', permission='view') >> def user(self): >> return dict(user=self.context) >> >> @view_config(name='edit', >> context='model.user.User', renderer='template/edit_user.pt', >> permission='edit') >> def edit_user_post(self): >> if self.user_form.form.validate(): >> self.user_form.form.bind(self.context) >> >> return HTTPFound(self.request.resource_url(self.context)) >> >> return HTTPNotFound() >> >> I had a lot of code that was almost trivial thanks to use of traversal >> and form_encode libraries. Because of this, even though I cringed a bit I >> never wrote a 'manager' layer of code for a lot of domain entities that >> would take care of more complex validations beyond just form validation. >> >> The big problem here I've found is that code like the above is very >> untestable. I have to test the rendered view to make sure the user object >> changed correctly when edited (eg: first name changed). But, while I think >> important, testing a rendered view for strings etc, is very fragile and >> breaks every time the designer comes in and changes the template code. >> >> >> > You could do unittesting and instead of testing the rendered result of > your view-callables, test your view-callables as functions. Pyramid has > some utilities for helping setup dummy requests and unittesting > http://pyramid.readthedocs.org/en/1.3-branch/narr/testing.html. Then you > can call your view-callables directly and test the resulting dict or > HTTPException. > > When my view callable changes something in the database I will check that > in the unittest by doing a query on the database to ensure it changed (so I > am not relying on looking for a changed value in a rendered template). To > get this setup I build the database in the setup and I roll it back in the > tearDown so none of the changes are kept. > > -- > Jason > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/pylons-discuss/-/6LELTp64Yy8J. > > 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. > -- 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.
