It would be nice to test equality of for example MuleEvent between different mule instances (e.g. serialization) but in order to do that practically everything in Mule needs to implement equals()/hashCode(). I started down this road thinking it would be good to have them anyway, but then realized just how much there would be to do and that the only reason for doing it was to this specific unit test and decided to back out.
We should probably only implement equals()/hashCode() on an as needed basis for implementation and not implement them just for unit testing.
Daniel Feist added a comment - 28/Sep/08 05:42 PM This is a big black hole..
It would be nice to test equality of for example MuleEvent between different mule instances (e.g. serialization) but in order to do that practically everything in Mule needs to implement equals()/hashCode(). I started down this road thinking it would be good to have them anyway, but then realized just how much there would be to do and that the only reason for doing it was to this specific unit test and decided to back out.
We should probably only implement equals()/hashCode() on an as needed basis for implementation and not implement them just for unit testing.
Leaving open for thoughts/comments..
Daniel Feist added a comment - 30/Nov/08 07:00 PM This isn't required and even if you try to implement these it become a never ending tree of types that need equals implementing.
It would be nice to test equality of for example MuleEvent between different mule instances (e.g. serialization) but in order to do that practically everything in Mule needs to implement equals()/hashCode(). I started down this road thinking it would be good to have them anyway, but then realized just how much there would be to do and that the only reason for doing it was to this specific unit test and decided to back out.
We should probably only implement equals()/hashCode() on an as needed basis for implementation and not implement them just for unit testing.
Leaving open for thoughts/comments..