|
From: beRt b. <beR...@al...> - 2005-01-10 10:43:53
|
Hmmmmm, on second thoughts: I don't think this is a good idea. Flash is flexible enough to call equals() on any object without the interface, so why intoduce it? I think the burden of using asUnit should be kept as low as possible... Also about the default behaviour I have doubts on my previous proposal testing all the members on equality: how deep do we go? We can't go endless since we can have circular references... Also: do we have to test if they are the same object? So here's my new proposal: if the object has an equals() function, call it, and otherwise just check if they refer to the same instance as now. That's also the behaviour you see in JUnit, and it's always nice to have an equals() method on your objects... Kind regards, Bert. Luke Bayes wrote: >>What about defining an interface Comparable that >>has a method equals() in it? If you want to define your own definition >>of equals(), you simply implement Comparable. >>assertEquals should then check if the object is an instance of >>Comparable, and if so, call equals(). Else it could take your approach. > > > This sounds better to me too... > > >>Anyway, I would like it a lot if assertEquals() could at least make a >>message using the toString() methods of both objects instead of an empty >>message when the test fails... > > > I also would agree with that. > > Bert, how would you feel about pulling down the latest source from CVS > and sending me these enhancements? > > I'd be glad to walk you through the CVS connection. > > Thanks, > > > Luke Bayes > www.asunit.com > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Asunit-users mailing list > Asu...@li... > https://lists.sourceforge.net/lists/listinfo/asunit-users > |