Welcome to another week of wonderful releases.  We start of with our two awesome logging and mocking frameworks LogBox and MockBox.  They have both just graduated to version 1.1 and can be downloaded today as standalone frameworks or via the 3.0.0 M4 bundle, ahh yes, another blog post after this.

So what's new with LogBox 1.1, well here are the tickets:

890	add all appenders to a logbox category by default even from coldbox apps	Fixed
891	category definitions should allow the * for appenders when definining them, instead of listing them	Fixed
907	Async Appenders need way to distinguish between threading and not	Fixed
910	LogBox standalone is now refactored to work under the logbox namespace	Fixed
941	new properties for EmailAppender: useTLS and useSSL	Fixed

The most important considerations are that we now have a utility that distinguishes when you are within an executed cfthread in any CFML engine.  LogBox uses this now for all of its asynchronous operations.  We also have refactored the download so LogBox can be installed alongside any ColdBox version or any other framework.  If you want to use LogBox in your ColdBox 3.0.0 applications, you already have it installed, so don't worry. 

Category definitions can now use '*' to define that you want ALL appenders for a specific logging category.  You can also omit them and LogBox will add all of them too.  However, be precise and use '*' if you want all appenders.

The last ticket was contributed to us and it is a great addition to the Email Appender, so now you can set the flags for SSL and TLS a-la-carte.  So enjoy LogBox 1.1!

Now to our mocking and stubbing library MockBox! So what's new with MockBox 1.1:

911	Standalone version should be refactored into its own namespace	Fixed
940	new method querySim() to help simulate queries	Fixed

We have also refactored the standalone download so it can be used alongside any ColdBox version or framework.  We have also added a nice UDF to simulate queries called querySim().  This way you can easily simulate and mock queries from your tests by doing things like:

mockQuery = querySim("col1, col2
val1 | val2
valrow2 | valRow2
valRow3 | valRow3");

That's it, just use the first line of the call to put your columns comma delimited and then a break and you rows separated by breaks and columns separated by '|'.  A very cool way to simulate queries. 

And finally, it has some minor fixes and tweaks, nothing extraordinary apart from the library itself!

So enjoy these two new standalone releases which can also be found in our upcoming ColdBox 3.0.0 Milestone 4 release!

MockBox has now reached a 1.0 release and can be downloaded now!  For those of you who don't know, MockBox is a companion framework to the ColdBox Platform that will give you advanced mocking/stubbing capabilities; hence a Mocking Framework. Not only does it integrate into the ColdBox unit testing framework powered by MXUnit, but it can also be used as a standalone mocking/stubbing framework for ANY type of stubing/mocking you would like to do outside of ColdBox applications, in any ColdFusion application. 

I want to thank Brian Kotek for his inspiration, and the MXUnit "locos", Marc Esher and Billy Shelton.  These guys are excellent and their contributions to the ColdFusion Community are amazing!

"A mock object is an object that takes the place of a 'real' object in such a way that makes testing easier and more meaningful, or in some cases, possible at all". by Scott Bain (Emergent Design - The Evolutionary Nature of Professional Software Development) http://www.netobjectives.com/emergent-design-evolutionary-nature-professional-software-development


MockBox Features
MockBox dynamically transforms target objects into mock/stub form at runtime. The API for the mocking factory is very easy to use and provides you a very simplistic approach to mocking.  We also use $() method notations to distinguish easily when you are using mocking capabilities on your code. So what can the mock factory do for me?

• Create mock objects for you and keep their methods intact (Does not wipe methods, so you can do method spys, or mock helper methods)
• Create mock objects and wipe out their method signatures
  
• Create stub objects for objects that don't even exist yet. So you can build to interfaces and later build dependencies.
• Decorate instantiated objects with mocking capabilities (So you can mock targeted methods and properties; spys)
• Mock internal object properties, basically do property injections in any internal scope
  
• State-Machine Results. Have a method recycle the results as it is called consecutively. So if you have a method returning two results and you call the method 4 times, the results will be recycled: 1,2,1,2
• Method call counter, so you can keep track of how many times a method has been called
• Method arguments call logging, so you can keep track of method calls and their arguments as they are called.  This is a great way to find out what was the payload when calling a mocked method
• Ability to mock results depending on the argument signatures sent to a mocked method with capabilities to even provide state-machine results
  
• Ability to mock private/package methods
• Ability to mock exceptions from methods or make a method throw a controlled exception
• Ability to change the return type of methods or preserve their signature at runtime, extra cool when using stubs that still have no defined signature
• Ability to call a debugger method ($debug()) on mocked objects to retrieve extra debugging information about its mocking capabilities and its mocked calls
  

So get to it, download it now, read the guide and enjoy your testing via MXUnit.

MockBox RC1 is now released!  This release adds some simple syntax fixes and cleanup of the core code.  We are also preparing its core for more mocking and stubbing capabilities for final release.

Also remember that MockBox is a separate framework based on the ColdBox platform.  You can install it and use it separately just like LogBox and ColdBox Platform.  So if you love mocking and stubbing objects on your unit tests, then MockBox is for you.  What would a ColdBox release be without documentation, so head on over to the MockBox Docs!

One of the nice things about ColdBox's model integration features are the ability to inject objects by using annotations via the cfproperty tag.  This gives a cleaner API to objects that don't really need to expose setters just for dependency injection purposes.  Why? well, in MY opinion, objects should be shy and only expose what they need to expose to the outside world.  By leveraging annotations, I can cleanly define the dependencies of my object and what is even better, it can even be self-documenting because they are cfproperties.  Not only that, since ColdFusion is a dynamic language and NOT JAVA, we can leverage much more than traditional setter/constructor dependency injection. In our next release, 3.0.0, we will expose our model integration features as a new dependency injection (IoC) framework which we are tentatively naming BlenderBox.  More about BlenderBox in other posts. So now that we introduced that ColdBox can blend your object's with other objects via annotations, how do we test them?  We have no setters or constructor arguments to inject them.  Well, but we do have mxunit and MockBox, which make our lives simpler and HAPPY!! So let's look at a simple service I am currently developing: <cfcomponent name="BetaTransferService" output="false" extends="beta2007.beta94.model.baseobjects.BaseService" hint="The main beta transferring service">

<!--- Dependencies -->
<cfproperty name="betadao" type="model" scope="instance">
<cfproperty name="configBean" type="model" scope="instance">

ALL OTHER METHODS HERE

<!--- onDIComplete -->
<cffunction name="onDIComplete" access="public" returntype="void" output="false" hint="Called after wiring is done">
<cfscript>
/* Setup Configurations */
var config = instance.configBean;

setProgramID(config.getKey('programID'));
setDefaultPublicRole(config.getKey('DefaultPublicRole'));

/* Get the program record */
instance.programRecord = instance.betadao.getProgramRecord(getProgramID());
</cfscript>
</cffunction> As you can see, I have a method called onDIComplete() which is called by BlenderBox after all dependency injection is finalized. Basically, my component has been created, injected and now it will be configured. I get some settings from my configuration bean, call my dao for a program record and finalize. Simple stuff, so let's test this puppy. First of all, I will create my setup method with my target cfc and dependencies. function setup(){
/* Create Mocks */
mockDAO = getMockBox().createMock(className="beta2007.beta94.model.betaweb.BetaDAO",clearMethods=true,callLogging=true);
mockConfig = getMockBox().createMock(className="coldbox.system.beans.configBean",clearMethods=true);
/* Mock Individual Settings */
mockConfig.$("getKey").$args("programID").$results("pid123");
mockConfig.$("getKey").$args("DefaultPublicRole").$results("BetaUser");

/* Create Target Service,decorate it with Mocking Capabilities, and init it
All in one single line via MockBox
*/
beta = getMockBox().createMock(className="beta2007.beta94.model.betaweb.BetaTransferService",callLogging=true).init();
/* Inject Mocks */
beta.$property("betaDao","instance",mockDao);
beta.$property("configBean","instance",mockConfig);
} What I do first is create my mock dao and mock config object. I then proceed to mock the 'getKey' method in my config object with several key target arguments and what they should return. Then I create my target object to test wich I also want decorated with mocking capabilities (just in case I need method spies) and init it. I then proceed to inject it with the mock objects into their appropriate variables in the correct scope /* Inject Mocks */
beta.$property("betaDao","instance",mockDao);
beta.$property("configBean","instance",mockConfig); So by leveraging MockBox's $property() method, I can inject properties into my target object. This is how I inject my dependencies. So let's proceed now to see my onDiComplete test. function testonDiComplete(){
/* Fake Program Record via ColdBox querySim() */
pRecord = querySim("program_id,name,release_phase_id,active,published
       #createUUID()#|Beta Program|#createUUID()#|1|1");
/* Mock Dao Call */
mockDAO.$("getProgramRecord",pRecord);   
/* Run onDI Complete */
beta.onDIComplete();
/* My Asserts */
assertEquals(precord, beta.getProgramRecord(),"program record");
assertEquals(beta.getProgramID(),'pid123');
assertEquals(beta.getDefaultPublicRole(),'BetaUser');
} So in my DI complete test, I first mock a query by using the ColdBox's querysim() method, I then mock the call to my dao's getProgramRecord, with this query I just mocked. I then call the onDiComplete() for execution and finalize with some assertions to make sure everything ran smoothly. So there you go, with a few lines of MockBox and testing, you can now be on your way to smoother and pain free testing. So go forth and Mock the Box!!

I am proud to announce another addition to our ColdBox Platform: MockBox.  MockBox is a companion package to the ColdBox Platform that will give you advanced mocking/stubing capabilities; hence a Mocking Framework. Not only does it integrate into the ColdBox unit testing framework powered by MXUnit, but it can also be used as a standalone mocking/stubing framework for ANY type of stubing/mocking you would like to do outside of ColdBox application, in any ColdFusion application.  First of all, I want to thank Brian Kotek for his inspiration, and the MXUnit "locos", Marc Esher and Billy Shelton.  These guys are excellent and their contributions to the ColdFusion Community have changed the way I develop.  I had the privilege of talking to them at CF.Objective this year and discussing mocking and testing, so thank you so much guys for all the ideas and for the hard work, you guys truly rock!!

MockBox version 1.0 Beta is now on SVN and can be downloaded by downloading the ColdBox Nightly Build found in our download area.  Also, in tradition of always bringing you the best documentation and samples, we have our guide ready for consumption.  The documentation goes over every feature of MockBox, samples and how to use it.  So before I go over some of the features of MockBox, let me give a brief introduction of what a Mock is.

"A mock object is an object that takes the place of a 'real' object in such a way that makes testing easier and more meaningful, or in some cases, possible at all". by Scott Bain (Emergent Design - The Evolutionary Nature of Professional Software Development) http://www.netobjectives.com/emergent-design-evolutionary-nature-professional-software-development

That is a great definition by Scott Bain, direct and to the point.  So what are the features of MockBox:

The approach that we take with the MockBox is a dynamic and minimalistic approach. Why dynamic? Well, because we dynamically transform target objects into a mock form at runtime. The API for the mocking factory is very easy to use and provides to you a very simplistic approach to mocking. So what can the mock factory do for me?

• Create mock objects for you and keep their methods intact (Does not wipe methods, so you can do method spys, or mock helper methods).
• Create mock objects and wipe out their methods (Wipes out the entire set of methods).
• Create stub objects for objects that don't even exist yet. So you can build to interfaces and later build dependencies.
• Decorate instantiated objects with mocking capabilities (So you can mock targeted methods and properties; spys)
• Mock internal object properties (In any scope)
• Have a method return 1 or more expected results.
• State-Machine Results. Have a method recycle the results as it is called consecutively. So if you have a method returning two results and you call the method 4 times, the results will be recycled: 1,2,1,2
• Method call counter, so you can keep track of how many times a method has been called.
• Method arguments call logging, so you can keep track of method calls and their arguments as they are called.
• Ability to mock private/package methods
• Ability to mock exceptions from methods or make a method throw a controlled exception.
• Ability to change the return type of methods or preserve their signature.
• Ability to make methods return results according to argument signatures

So there you go, this is MockBox in a nutshell.  So get to it, download it now, read the guide and enjoy your testing via MXUnit.