First, I've updated the CFEasyMock download zip to include CF7 again. Unfortunately where I work, the decision to upgrade to CF8 has been held off. Mostly by management, isn't it always?

So much of the work I've actually been able to devote to the package has occured on the CF7 version. Luckily, the primary difference between CF7 and CF8 versions of CFEasyMock lie outside of CFEasyMock itself, in the reflect package. The changes to CF7 were easy to integrate back up to the CF8 version.

Versions prior to 1.2 used a component called ExpectedMethodCall to hold the called method (as a reflect.Method reference) and the argument parameters for that call. Functions of ExpectedMethod call would do the matching to see if the expected and actual calls matched. Since this code is obviously the same for all method calls, it was moved into MockFactory, eliminating the need to create extra components just to perform matching calculations. The changes are completely internal and no unit test code needs to be altered.

The reflect package which CFEasyMock relies on to actually create the proxy has been updated to support the CF8 feature of onMissingMethod.

Nothing in the easymock package has changed. However, I will be updating the online zip and the SVN repository with the CF8 version of the Proxy component.

You will probably see a new project come up in a few days that will contain the reflect package itself. This is the package that does all the heavy lifting to create the proxy components and there are some cool ideas I'd like to implement, and these things aren't directly tied to the easymock package.

It will also allow me to version them seperately.

The primary benefit of moving to CF8 and onMissingMethod is speed. The CF7 version of reflect has to write a dummy component with the correct function call, create that file as a component instance, and then inject the function into the proxy. This can take considerable time if you have many mock objects.

Below are some times from unit tests for the ExpectedMethodCall, one of the biggest test cases in the package:

You would think that given the context of the CFEasyMock package I would have a slurry of unit tests covering all aspects of the project from a very TDD perspective.

Alas, that is not the case. There were scattered tests that didn't cover much, other than basic creation of mocks and simple happy path tests.

Well, that has changed, or at least has mostly changed. I've gotten about 40% coverage now, and the unit tests use the CFEasyMock package.

I've found that the greatest benefit of CFEasyMock so far, has been the near elimination of having to do stepwise debugging to find out what a particular method is doing. You know the drill, code in output so you can see where things are happening. Run the method, dump values, see where things are occuring. Not so much anymore. I just use the strict mock and declare expected behavior.

I've added a tweak to the MockFactory and MockInvocationHandler that allows you to switch a mock into debug mode, collecting all method calls/return values as they go through, regardless of mode or expectation. The generated stack trace can be accessed by the stackTrace() function in the MockInvocationHandler itself.

I've also located and fixed the following issues:

1. expects() was not triggering correctly due to the ResultMapper.add() not handling the first added request correctly.
2. times() was overwriting the previous Result as well as the Range, instead of just modifying the previous Range.
3. Component arguments were not compared at the name (aka type) level, which was allowing two of the same method call with different components to pass.

Ryan Wood and I have been working through a few issues. We've uncovered and fixed a bug with the expect() method. There's a new zip with the latest version on the project site, v1.0.002

Ryan has also proposed a solution for allowing CFEasyMock to work with injected functions. I'll be working on getting that completely integrated this weekend.

Thank you Ryan!

ColdFusion gives developers a great deal of flexibility when creating functions. Not all arguments have to be known at runtime by declaring them with a tag. Any additional arguments passed get a number key relative to their position (if they aren't passed in by name or via an argumentcollection).

So for function foo...

called by

Would yield an argument struct of: bar = 10, 2 = 20, 3 = 30, 4 = 50

If you call foo like the following:

you would get an argument struct of: bar = 10, var1 = 20, var2 = 30, bar2 = 40

At first I thought this was a great concept. Less typing, not constrained to a particular implementation, etc. Then I got to thinking. This could really turn into a slippery slope.

Functions that don't have a clear set of arguments can easily end up not having a clear definition of purpose. (Not to mention difficult to debug!) They could start to take on more and more behavior and then lose any resemblance of reusability.

Functions that perform one specific behavior will have a known set of inputs. Those input values may vary, but the inputs themselve are always known.

There are some instances where unnamed arguments does make things a lot easier. There's even an example of that within CFEasyMock itself, in the MockFactory.replay() method (and reset() and verify()). It is simply easier to pass in a series of components rather than make an array out of them first. (Which would be the most prudent way to do it.) However, there is still the chance that someone passes in the wrong object, but that wouldn't be caught until runtime anyway.

It's a double edged sword. There are definite benefits, but it should be used sparingly with good reason, as opposed to a general coding practice.