OK, you install AsUnit, you follow the Quickstart Directions, and you grab Test Driven Development: By Example or some other book or online reference and start converting Java to AS2.
The first thing that’s going to stick in your craw is when you try to use assertEquals(). You’re going to get an error about using the incorrect type or something along those lines. This is because in AsUnit, assertEquals requires two arguments that are Comparable. Note the capital C. Comparable is an interface: com.asunit.utils.Comparable. (You can find all the AsUnit classes in the Classes directory of your Flash Configuration directory.) Comparable specifies two methods: equals() and toString(). I really don’t like the way that assertEquals is implemented. First of all it forces a tight coupling between your testing environment and your project code. If you make a class that you might want to test a member of for equality, you have to make it implement com.asunit.utils.Comparable. Furthermore, you can’t use it to test primitive values at all. So it’s impossible to do something like:
assertEquals(100, myPay.amount);
because 100 is a primitive constant and can’t implement an interface, and even if myPay’s class implemented Comparable, its amount property most likely wouldn’t.
The reason it is implemented this way is so that you can compare higher level objects. Any two objects will report false to obj1 == obj2, even if everything about them is exacty the same. The Comparable interface forces you to write an equals method that compares an instance of your class with another instance and reports true or false. That’s nice, but it breaks too many other tests which should be valid. So I re-wrote assertEquals to the following:
public static function assertEquals(msg:Object, assertion1, assertion2):Void { if(arguments.length == 2) { assertion2 = assertion1; assertion1 = msg; msg = ""; } if(assertion1.equals != undefined) { addTestResult(String(msg), "assertEquals", assertion1.equals(assertion2)); } else if(assertion2.equals != undefined) { addTestResult(String(msg), "assertEquals", assertion2.equals(assertion1)); } else { addTestResult(String(msg), "assertEquals", assertion1 == assertion2); } }
You can find this assertEquals in com/asunit/Assert.as in the Classes directory. Just comment it out and replace it with this. My logic is: if either one of the objects implements an equals function, use it. If neither does, do a straight == comparison. This decouples the testing and project code, and allows testing of virtually any type. If you see any enhancements or improvements that could be made, feel free to post them. This one works great for me, but I’m not saying it couldn’t be better.
An enhancement would be to add a “strict” flag as a parameter. Since 1 == “1”, you may think your test passes, but it could actually be failing because of the compatible but not exact data types. A “strict” flag would use === instead of == to make sure 1 == 1 is true and 1 == “1” isn’t.
Maybe this is already part of AsUnit? The strict flag might need to be added to all of the equality operators.
Nice work, though.
Good article, Keith. I’ve been sticking with AsUnit 2.4 so far because of annoyances like this, but maybe I should lobby for change.
One suggestion: use ===.
Yes, agreed on the ===. That thought fleetingly passed through my mind at some point, but never made it into the code. 😉
AsUnit uses strict equality for all its comparisons already.
Sorry,
The Comparable addition comes from this thread :
http://sourceforge.net/mailarchive/forum.php?thread_id=6302351&forum_id=42743
As you’ll see, the last message comes with the same solution than you.
But for another one, the lead developpers stops their integration with the first option (?!)
BTW, I use excatly the same revision than yours. 🙂
Another thing :
Do you achieve to compile AsUnit with MTASC ?
It needs some fix to work correctly.
I have a version that do the both.
Interested ? Contact me.
Cheers.
Believe it or not, I saw the earlier post after I posted my own solution to the list. Funny how it’s pretty much the exact same solution.
I’m not currently using MTASC. Too many changes between minor versions right now, which break existing projects. At least from 1.04 – 1.05 changed too much. I’ll definitely be getting back into it as it stabilizes out a bit.
Thanks for the post Keith!
This problem should be fixed as per the code that you submitted in the latest version of AsUnit 2.6++!
As far as MTASC goes, our latest version should also compile in MTASC with no errors or warnings…
You can always get the latest release from:
http://www.asunit.com
Thanks for the support.
Luke Bayes