Menu
▾
▴
asunit-users
|
From: beRt b. <beR...@al...> - 2005-01-07 13:28:08
|
> So we could use a recursive for-in check to validate this method > correctly if test is made on object datatype. I don't fully agree. 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. 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... Kind regards, Bert Bruynooghe. |
|
From: Luke B. <lb...@gm...> - 2005-01-08 08:20:43
|
> 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 |
|
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 > |
|
From: viaContact <via...@v-...> - 2005-01-10 11:54:31
|
> This sound good for me also : > 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... > What do the other think ? Cheers. |
|
From: Luke B. <lb...@gm...> - 2005-01-11 01:21:26
|
OK - I don't really feel too strongly either way. I just released the latest build of AsUnit (2.5) over the weekend with the requested change to call the "equals" method. If you don't want to enforce Comparable, or if you want to make the call to equals() optional, we might have to make some minor changes... There might be some problems in Flex and ultimately MTASC compatibility if we start calling optional methods... (not sure though) I definitely don't think it's too much to ask for someone to implement an Interface if they want to use a more advanced portion of the framework. Let me know what you folks want to do for the next release. Thanks, Luke Bayes www.asunit.com |
|
From: beRt b. <beR...@al...> - 2005-01-11 12:37:24
|
Hi,
meanwhile I wrote my own implementation without the interface ... It
uses the equals() of the object if there is any, and otherwise uses ==
instead of ===, because you don't want strict equality here on Numbers,
Strings, ...
It also provides some message if you don't specify one.
Here it is:
public static function assertEquals(msg:Object, assertion1:Object,
assertion2:Object):Void {
if(arguments.length == 2) {
assertion2 = assertion1;
assertion1 = msg;
msg = assertion1 + " vs. " + assertion2;
}
var result:Boolean;
if ("function"== typeof(assertion1.equals)){
result = assertion1.equals(assertion2);
}else{
result = (assertion1 == assertion2);
}
addTestResult(String(msg), "assertEquals", result);
}
Luke Bayes wrote:
> OK -
>
> I don't really feel too strongly either way. I just released the
> latest build of AsUnit (2.5) over the weekend with the requested
> change to call the "equals" method.
>
> If you don't want to enforce Comparable, or if you want to make the
> call to equals() optional, we might have to make some minor changes...
>
> There might be some problems in Flex and ultimately MTASC
> compatibility if we start calling optional methods... (not sure
> though)
>
> I definitely don't think it's too much to ask for someone to implement
> an Interface if they want to use a more advanced portion of the
> framework.
>
> Let me know what you folks want to do for the next release.
>
>
> 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
>
|
|
From: beRt b. <beR...@al...> - 2005-01-13 07:50:45
|
I had a look on the assertEquals you implemented, and I have some
objections:
1. my existing code doesn't compile anymore
2. I expect assertEquals(new String ("test"), new String("test")) to
succeed, while I expect assertSame( new String ("test"), new
String("test")) to fail. Right now, I can't even use the assertEquals on
Strings...
Kind regards,
Bert.
Luke Bayes wrote:
> OK -
>
> I don't really feel too strongly either way. I just released the
> latest build of AsUnit (2.5) over the weekend with the requested
> change to call the "equals" method.
>
> If you don't want to enforce Comparable, or if you want to make the
> call to equals() optional, we might have to make some minor changes...
>
> There might be some problems in Flex and ultimately MTASC
> compatibility if we start calling optional methods... (not sure
> though)
>
> I definitely don't think it's too much to ask for someone to implement
> an Interface if they want to use a more advanced portion of the
> framework.
>
> Let me know what you folks want to do for the next release.
>
>
> 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
>
|
Thanks for helping keep SourceForge clean.
X