Maurits van Rees-3 wrote:
>
> Hi,
>
> In a product I have some testbrowser tests and all events that I
> expect are fired correctly.
>
> I also have some non testbrowser tests. Here I find myself firing
> some events manually in order to let my event handlers run.
>
> For instance, I have created a utility function for adding a Booking.
> I manually fire the ObjectModifiedEvent for the Booking and the
> container that it is added to. The first event is needed to update a
> total on the container. The second event is needed to update a
> total on the parent of the container.
>
>
> def createBooking(container, id=id, hours=0, minutes=0):
> """Create a Booking and fire the ObjectModifiedEvent.
>
> The event is fired automatically for you when you press Save in
> the edit form, but in testing we apparently need to take care of
> it ourselves.
> """
> container.invokeFactory('Booking', id=id)
> booking = container[id]
> booking.update(hours=hours, minutes=minutes)
> # In these kinds of tests we need to fire some events ourselves...
> # To do: use testbrowser tests instead.
> notify(ObjectModifiedEvent(booking))
> notify(ObjectModifiedEvent(container))
>
>
> I think that when I move to testbrowser tests (so really testing the
> adding and editing of Bookings through the browser) these manual
> notifications are not needed anymore.
>
> I noticed in other tests that 'update(hours=x)' is already a bit
> better than 'setHours(x)' so I moved to that in all my tests.
>
> But am I maybe doing something wrong here? Are there other ways I can
> update some fields of an Archetype object that *do* make sure these
> events are fired? Or is there some other more convenient way to trick
> the testing environment into firing all proper events?
>
> To say it a bit differently: I am looking for a way to say to Zope: "I
> am done editing this object now, so please start doing everything that
> you normally do when someone clicks the 'Save' button on an edit
> form."
>
Events are typically (but not always) fired from the UI layer that invokes
an operation. You should grep OFS and Archetypes (and possibly CMF and
Plone) for "notify()" and you'll understand better where events are being
fired from - or put a pdb in a test handler and look at a backtrace. There
is nothing magical about events, they fire when you call the code that calls
notify(), and that code blocks until all event handlers are complete.
I'd suggest that you should think about the granularity of your tests. If
you're writing a test for an event handler, then it's up to you to fire the
event and populate it with the minimum possible information to make sure the
handler can be adequately tested. Often, this would involve dummies. If
you're testing other functionailty, then you shouldn't care (normally)
whether the event is being fired. Obviously, if you're making testbrowser
tests for functional/integratino/systems testing then you want to be as
close to "real" user interaction as possible and test the end result of an
operation that happens to involve events, without really needing to care
whether the end result (e.g. a rendered result page) was created via event
handlers or some other mechanism.
Martin
--
View this message in context:
http://www.nabble.com/Non-testbrowser-tests-and-events-tf3527411.html#a9843140
Sent from the Plone Product Developers mailing list archive at Nabble.com.
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
