MXUnit - Release Candidate No.1 Now Available

Friday, February 22, 2008

MXUnit RC1

A long time in the making, los hombres at are proud to announce the first release candidate of their Unit Test Framework and Eclipse Plugin for ColdFusion Developers.

Features include a simple-to-use extensible framework that allows developers to spend more time writing tests and code than getting distracted by frameworks details. The MXUnit Eclipse Plugin further facilitates test creation by integrating running and debugging of tests within the Eclipse IDE.

Key Features:

So… if you've made a New Year's Resolution to start unit testing, now's a perfect time to give MXUnit a test drive. For those of you using an existing framework but have a few minutes to burn checking this one out, we'd love to hear your feedback, too.

Visit for downloads and details.

MXUnit will be giving both a one hour presentation and two-hour hands on workshop at Webmaniacs in Washington, D.C., in May. Also, keep an eye out at ColdFusion Meetup where MXUnit major dude, Marc Esher, will be doing a very informative presentation entitled Ant on the Wire on Thursday, February 28, 2008 at 12:00 PM EST . Then we'll follow that up with a two-part series at ColdFusion Meetup on unit testing with MXUnit.

Licensed under the GNU 3.0 Copyleft License


Mark said...

I'm looking at MXUnit, and it looks very nice! Especially the Eclipse integration.

One question, however, you don't seem to have a AssertSame()?

Is this something that is going to exist at some point, or is an omission from the documentation, or... something else entirely.

Figured I would ask, but keep up the good work - looks like a great product!

bill said...

Good catch, Mark! We've have had numerous discussions about comparing data structures and objects in ColdFusion. The short answer to this question is that there is no straight forward way to accomplish this in CF. In Java, it's as easy as saying (myObj1 == myObj2). What we will do, however, is elevate this to high and come up with a solution. We just might have to load a simple java class, which seems like overkill, but might be the best solution.

I'll post this on the support site and create the issue. You might want to check and for updates.


Mike said...

I've gone around in circles on this issue for a while, but outside the unit testing framework.

I think its important to note that sometimes we want to know if the properties of two distinct objects are the same and other times we want to know if we have two handles on the same object.

Somehow not as important in cf as it is in other languages. For example, in Flash, if you have multiple instances of an object on the screen and you want to change something about the way it looks, it's very important whether you change the instance or the class itself. A change in one shows up in just the one instance, a change in the other changes all the instances at once.

I can't think of a simple example of that sort of effect in cf. It would be a great help to me if someone could come up with a practical example of how they would use this feature where it checks to see if you had two handles on the same object.

Unfortunately, it's relativley easy to implement either approach directly in your components, but there is no way mxunit could know that you put it in place.

For example, if you want to track instances, you can add a property that you put in the implicit constructor that just generates a guid. It gets created each time the object is instantiated. Easy to compare.

For checking property equality, I just roll my property structure into a wddx packet and compare that. It seems to work pretty well.

Mark said...

Actually, this is very easy to implement - check out my blog post:

So all you really need to do is compare the identity hash codes of the two objects. If they are the same, you know they are the same objects.

This is actually very important for anyone who is implementing a system with a caching strategy, as to test them, you often need to know if the object coming out is a new object, or the same object. i.e. if your caching strategy is working correctly.

Hopefully you can work this in, as it should be pretty simple :oD

bill said...

Hey mark,

For some reason I suspected you were the developer of the JavaLoader components. Very nice work! And I used those to implement a proof-of-concept for assertSame().

With respect to hash codes, I could be mistaken, but I thought in Java a hash is computed based upon the object's value. You mention "identity hash codes", which makes me suspect I'm likely missing something. If you could point me in the right direction for this that would be great.


bill said...

Hey Marc,

I found it. I think something got stripped off the url you provided. So, it looks like it works using Java.lang.System.identityHashCode(...);

Of course, we'll have write a slew of tests. And I'm sure we'll find _other_ uses for JavaLoader ( ;-)

As an added bonus, this also helps with array identity comparison, which is problematic in CF 7 and 8 as arrays are apparently passed as values to CFCs and not as references. So, they were being identified as the same array which was not the case.

Thanks for improving MXUnit! We owe you a cold one.


Marc Esher said...

"we'll have write a slew of tests". "have to..."???

I'm ashamed.

Johnny TDD just couldn't wait to crank out the code, could you?

That sound you hear right now is kent beck crying. and all your professors, who put so much time into your breeding, only to see their hopes and dreams dashed.

Woe.... woe unto this world.

OK, enough of that.

Mark M, great stuff. thanks!

Bill.... I'll forget all about this transgression for the low, low price of a box of cohibas.

Mike said...

I would have helped, but I have to get back to World of Warcraft.

bill said...

Mark (et al),

A new version of Assert containing assertSame(...) and assertNotSame(...) are in repo and will be part of the next release.

Thanks again, Mark!


bill said...

FYI, RC1 version 0.9.85-rc1 is available for download and includes assertSame(obj,obj) and assertNotSame(obj,obj).

A special thanks to Mark Mandel for describing a most elegant solution to this!