Hello Steve,
> > I have used this class for multiple events, but the only
> thing I verify on
> > the mock listener at that moment is the number of events
> received, not the
> > actual data of each event.
>
> Then I'd recommend taking out the stuff you don't use. Unless
> someone else does.
Would it be a good idea to just be able to set the expected event objects on
the MockPropertyChangeListener and have the expected eventCount removed from
the class? The nr of expected events should then have to match the number of
event objects you add to the mock listener as expected.
> > Tell me if my thoughts match yours: the
> MockPropertyChangeListener maintains
> > a list of EventMatch objects, in the order I expect each
> event. When I add
> > an EventMatch object to the mock listener, the EventMatch
> object contains a
> > fully configured PropertyChangeEvent as the expected event. When the
> > propertyChangeEvent on the mock listener is invoked, it
> takes the actual
> > event and pushes it to the EventMatch object, increments
> the eventCount
> > expectation. A subsequent call will push the actual event
> to the next
> > EventMatch object in the list. Verification of the mock
> listener also
> > invokes the verificiation on the EventMatch objects.
> >
> > If this is your idea, can't a similar thing be done with an
> > ExpectationCollection? Initially pushing the expected
> PropertyChangeEvent
> > objects as expected values and then collecting the actual values?
>
> Exactly. The only difference is that I would probably write a
> special EventMatch class, rather than another
> PropertyChangeEvent, that would let me decide how to specify
> that it was equal to an incoming Event.
Isn't there just only way to match an expected PropertyChangeEvent with the
actual one? Or would the EventMatch class be the superclass of e.g.
PropertyChangeEventMatch, ListDataEventMatch, etc... wherein the actual
comparison of the expected event type with its actual value happens?
Ringo
|
